Django-cms placeholder translation, rendering with respect to language - django-cms

I would like to know how to manually translate a placeholder in Django-cms.
If I use the tag {% placeholder "test" %}, I can only define the value of test once for all languages. Is it possible to define the same placeholder multiple times for all languages used on the website? Or should I create different placeholders test_en, test_fr, test_es and use an if clause within my template? It is not very elegant.

You haven't given any details on how you build your pages but I'm guessing you have created your own with your custom setup of placeholders. Any regular django-cms pages are translatable by default if you configure multiple languages in your settings.
Note that it is preferable to translate the container that holds the placeholder(s) than each placeholder separately.
If you define your own pages you can make those translation aware using django-hvad (which is also what django-cms uses):
# models.py
from cms.models import PlaceholderField, Placeholder
from django.conf import settings
from django.contrib.auth.models import User
from django.db import models
from django.db.models import Q
from django.utils.translation import ugettext_lazy as _
from hvad.manager import TranslationAwareManager
class LanguageManager(TranslationAwareManager):
def for_language(self, language):
return self.get_queryset().filter(Q(language__isnull=True) | Q(language=language))
class CustomPage(models.Model):
language = models.CharField(_('language'), max_length=5, null=True, blank=True, choices=settings.LANGUAGES,
help_text=_('leave empty to display in all languages'))
placeholder_abstract = PlaceholderField('abstract', related_name='%(class)s_abstracts')
placeholder_content = PlaceholderField('content', related_name='%(class)s_contents')
placeholder_links = PlaceholderField('links', related_name='%(class)s_links')
created_by = models.ForeignKey(User, null=False, blank=False, related_name='+', editable=False)
modified_by = models.ForeignKey(User, null=False, blank=False, related_name='+', editable=False)
created = models.DateTimeField(auto_now_add=True, editable=False)
last_modified = models.DateTimeField(auto_now=True, editable=False)
objects = LanguageManager()
Django Hvad has many more goodies for translating models.

Related

How to limit Django-CMS template_choices based on Page parent

This question could probably be solved with a more broad Q: "How to replace a python 2.7 attribute with a property from outside", but maybe there's a Django-CMS way of accomplishing this, so I ask:
I'm trying to limit the template choices of Django-CMS' (v3.4.x) pages based on their parents, so for this I thought of overriding it's template_choices with a function, but I see that in Django-CMS' Page model it's loaded on creation, like this:
#python_2_unicode_compatible
class Page(...):
...
TEMPLATE_DEFAULT = get_cms_setting('TEMPLATES')[0][0]
template_choices = [(x, _(y)) for x, y in get_cms_setting('TEMPLATES')]
...
Modifying get_cms_settins is out of the question, but I do need to alter TEMPLATE_DEFAULT and template_choices so that they have the proper values I wish for. Since I'm still fairly new to Django and Python, my question is where and how do I do this?
My first attempt was to do something like this on my models.py:
#property
def template_choices(self):
from cms.utils import get_cms_setting
templates = [(x, _(y)) for x, y in get_cms_setting('TEMPLATES')]
if self.parent:
if self.parent.template == 'parent_a.html':
templates = [('child_A.html', _('Child A'))]
elif self.parent.template == 'parent_b.html':
templates = [('child_b.html', _('Child B'))]
else:
templates = [('fullwidth.html', _('Fullwidth'))]
else:
templates = [('home_page.html', _('Homepage')),
('parent_a.html', _('Parent A')),
('parent_b.html', _('Parent B'))]
return templates
#property
def template_default(self):
return self.template_choices[0][0]
Page.template_choices = template_choices
Page.TEMPLATE_DEFAULT = template_default
And this is setting those fields correctly if I try to inspect any instance of Page, however when I try to edit any page and I click on the Page>Templates menu, all templates are up for selection, so it seems the template_choices and TEMPLATE_DEFAULT attributes are being ignored. Inspecting pagemodel.py seems to confirm this, since the get_template and get_template_name methods use get_cms_setting('TEMPLATES') instead of those fields. Also in cms_toolbars.py for the # templates menu section get_cms_setting('TEMPLATES') rather than self.page.template_choices which seems to be the main culprit. So, this question has turned into a bug ticket: https://github.com/divio/django-cms/issues/6520

How to set default css classes for all built-in form widgets in Django

Short version: is it possible to define a set of default css classes that Django should use whenever rendering a form ?
Long version:
The context is as follows: I would like to use the css classes defined in the w3.css framework for all my forms (http://www.w3schools.com/w3css/default.asp). I have seen that it is possible to do that in Django at form class definition or at form rendering, but it requires in both cases an explicit declaration of all the form fields. That means that I loose all the benefit of automatic form generation for ModelForms. I would like something as follows instead:
Define somewhere (e.g. in the settings file) a default mapping between form fields / widgets and css classes, e.g. 'textinput': 'my_default_css_class_for_text_inputs'
By default, for all automatic generation and rendering of forms, the default css classes defined in (1) are used, with no or minimal modification of the existing form classes
For specific forms, I can overload the defaults with other values
As far as I've understood, such behaviour is not possible in django. The crispy-forms package seems to go in that direction, but it seems to do much more than just that, and I am not sure that I want all the extra complexity (I'm still a newbie around here). An alternative would be to use javascript to add the classes on the client side. It looks like an ugly bad practice to me.
Could anyone confirm my understanding of this issue and point me towards elegant solutions, if any ?
Thanks !
Jonathan
I've managed to find the answer to my question and I'm posting it here for posterity. For the label class, I had some inspiration from here and here (answer from user2732686). The first link suggests to redefine the label_tag method of the BoundField class at run-time. It's a less verbose solution than the one suggested in the 2nd link, but at the cost of a project-wide hack, which I would not recommend. Here, I follow Django's subclassing mania, as suggested in the 2nd link for the labels.
In the projects settings.py, add:
# Default css classes for widgets and labels
DEFAULT_CSS = {
'error': 'w3-panel w3-red', # displayed in the label
'errorlist': 'w3-padding-8 w3-red', # encloses the error list
'required': 'w3-text-indigo', # used in the label and label + input enclosing box. NB: w3-validate only works if the input precedes the label!
'label': 'w3-label',
'Textarea': 'w3-input w3-border',
'TextInput': 'w3-input w3-border',
'Select': 'w3-select w3-border',
}
NB: apart from the 4 first keys, the keys must match Django's widget names.
In your forms.py (or elsewhere), add:
from django.forms import ModelForm, inlineformset_factory, Form, BoundField
from django.forms.utils import ErrorList
from django.utils.html import format_html, force_text
from django.conf import settings
class CustErrorList(ErrorList):
# custom error list format to use defcss
def __str__(self):
return self.as_div()
def as_div(self):
if not self:
return ''
return format_html('<div class="{}">{}</div>',
settings.DEFAULT_CSS['errorlist'],
' '.join( [ force_text(e) for e in self ] )
)
class CustBoundField(BoundField):
# overload label_tag to include default css classes for labels
def label_tag(self, contents=None, attrs=None, label_suffix=None):
newcssclass = settings.DEFAULT_CSS['label']
if attrs is None:
attrs = {}
elif 'class' in attrs:
newcssclass = ' '.join( [ attrs['class'], newcssclass ] ) # NB: order has no impact here (but it does in the style sheet)
attrs.update( { 'class': newcssclass } )
# return the output of the original method with the modified attrs
return super( CustBoundField, self ).label_tag( contents, attrs, label_suffix )
def custinit(self, subclass, *args, **kwargs):
# overload Form or ModelForm inits, to use default CSS classes for widgets
super( subclass, self ).__init__(*args, **kwargs)
self.error_class = CustErrorList # change the default error class
# Loop on fields and add css classes
# Warning: must loop on fields, not on boundfields, otherwise inline_formsets break
for field in self.fields.values():
thiswidget = field.widget
if thiswidget .is_hidden:
continue
newcssclass = settings.DEFAULT_CSS[ thiswidget.__class__.__name__ ]
thisattrs = thiswidget.attrs
if 'class' in thisattrs:
newcssclass = ' '.join( [ thisattrs['class'], newcssclass ] ) # NB: order has no impact here (but it does in the style sheet)
thisattrs.update( { 'class': newcssclass } )
def custgetitem(self, name):
# Overload of Form getitem to use the custom BoundField with
# css-classed labels. Everything here is just a copy of django's version,
# apart from the call to CustBoundField
try:
field = self.fields[name]
except KeyError:
raise KeyError(
"Key '%s' not found in '%s'. Choices are: %s." % (
name,
self.__class__.__name__,
', '.join(sorted(f for f in self.fields)),
)
)
if name not in self._bound_fields_cache:
self._bound_fields_cache[name] = CustBoundField( self, field, name )
# In the original version, field.get_bound_field is called, but
# this method only calls BoundField. It is much easier to
# subclass BoundField and call it directly here
return self._bound_fields_cache[name]
class DefaultCssModelForm(ModelForm):
# Defines the new reference ModelForm, with default css classes
error_css_class = settings.DEFAULT_CSS['error']
required_css_class = settings.DEFAULT_CSS['required']
def __init__(self, *args, **kwargs):
custinit(self, DefaultCssModelForm, *args, **kwargs)
def __getitem__(self, name):
return custgetitem(self, name)
class DefaultCssForm(Form):
# Defines the new reference Form, with default css classes
error_css_class = settings.DEFAULT_CSS['error']
required_css_class = settings.DEFAULT_CSS['required']
def __init__(self, *args, **kwargs):
custinit(self, DefaultCssForm, *args, **kwargs)
def __getitem__(self, name):
return custgetitem(self, name)
NB: replace <MY_PROJECT> with your project name
Then, you simply subclass DefaultCssModelForm and DefaultCssForm instead of ModelForm and Form when defining your forms. For formsets, use these classes as base classes. To illustrate:
class MyForm(DefaultCssModelForm):
class Meta:
model = MyModel
fields = '__all__'
MyFormSet = inlineformset_factory( ..., ..., form=DefaultCssModelForm, ... )

Django Haystack with elasticsearch returning empty queryset while data exists

I am doing a project in Python, django rest framework. I am using haystack SearchQuerySet. My code is here.
from haystack import indexes
from Medications.models import Salt
class Salt_Index(indexes.SearchIndex, indexes.Indexable):
text = indexes.CharField(document=True, use_template=True)
name = indexes.CharField(model_attr='name',null=True)
slug = indexes.CharField(model_attr='slug',null=True)
if_i_forget = indexes.CharField(model_attr='if_i_forget',null=True)
other_information = indexes.CharField(model_attr='other_information',null=True)
precautions = indexes.CharField(model_attr='precautions',null=True)
special_dietary = indexes.CharField(model_attr='special_dietary',null=True)
brand = indexes.CharField(model_attr='brand',null=True)
why = indexes.CharField(model_attr='why',null=True)
storage_conditions = indexes.CharField(model_attr='storage_conditions',null=True)
side_effects = indexes.CharField(model_attr='side_effects',null=True)
def get_model(self):
return Salt
def index_queryset(self, using=None):
return self.get_model().objects.all()
and my views.py file is -
from django.views.generic import View
from haystack.query import SearchQuerySet
from django.core import serializers
class Medication_Search_View(View):
def get(self,request,format=None):
try:
get_data = SearchQuerySet().all()
print get_data
serialized = ss.serialize("json", [data.object for data in get_data])
return HttpResponse(serialized)
except Exception,e:
print e
my python manage.py rebuild_index is working fine (showing 'Indexing 2959 salts') but in my 'views.py' file , SearchQuerySet() is returning an empty query set...
I am very much worried for this. Please help me friends if you know the reason behind getting empty query set while I have data in my Salt model.
you should check app name it is case sensitive.try to write app name in small letters
My problem is solved now. The problem was that i had wriiten apps name with capital letters and the database tables were made in small letters(myapp_Student). so it was creating problem on database lookup.

How can I use zope.schema to group portal types into categories?

I need to create a Plone configlet that delivers this kind of structure:
types = {
'News articles': ['NewsMediaType', 'News Item'],
'Images': ['Image'],
'Pages': ['Page']
}
I made a prototype to show what I was thinking to have in the form:
So I need to group some portal_types together and let the user assign a name for this group. How can I do that? Any ideas?
edited:
I made a great progress with the problem, but when save the form, validation give me an error
# -*- coding: utf-8 -*-
from plone.theme.interfaces import IDefaultPloneLayer
from z3c.form import interfaces
from zope import schema
from zope.interface import Interface
from plone.registry.field import PersistentField
class IThemeSpecific(IDefaultPloneLayer):
""" """
class PersistentObject(PersistentField, schema.Object):
pass
class IAjaxsearchGroup(Interface):
"""Global akismet settings. This describes records stored in the
configuration registry and obtainable via plone.registry.
"""
group_name = schema.TextLine(title=u"Group Name",
description=u"Name for the group",
required=False,
default=u'',)
group_types = schema.List(title=u"Portal Types",
description=u"Portal Types to search in this group",
value_type =schema.Choice(
title=u"Portal Types",
vocabulary=u"plone.app.vocabularies.ReallyUserFriendlyTypes",
required=False,
),
required=False,)
class IAjaxsearchSettings(Interface):
"""Global akismet settings. This describes records stored in the
configuration registry and obtainable via plone.registry.
"""
group_info = schema.Tuple(title=u"Group Info",
description=u"Informations of the group",
value_type=PersistentObject(IAjaxsearchGroup, required=False),
required=False,)
-
from plone.app.registry.browser import controlpanel
from collective.ajaxsearch.interfaces.interfaces import IAjaxsearchSettings
from collective.ajaxsearch.interfaces.interfaces import IAjaxsearchGroup
from z3c.form.object import registerFactoryAdapter
class AjaxsearchSettingsEditForm(controlpanel.RegistryEditForm):
schema = IAjaxsearchSettings
label = u"Ajaxsearch settings"
description = u""""""
def updateFields(self):
super(AjaxsearchSettingsEditForm, self).updateFields()
def updateWidgets(self):
super(AjaxsearchSettingsEditForm, self).updateWidgets()
class AjaxsearchSettingsControlPanel(controlpanel.ControlPanelFormWrapper):
form = AjaxsearchSettingsEditForm
That's a CRUD (create-read-update-delete) pattern.
The plone.z3cform package has specific support for just such forms. Define a schema for a types group:
class IAJAXTypesGroup(interface):
name = ...
types = ...
then use a CRUD form:
from plone.z3cform.crud import crud
class AJAXGroupsCRUDForm(crud.CrudForm):
update_schema = IAJAXTypesGroup
def get_items(self):
# return a sequence of (id, IAJAXTypesGroup-implementer) tuples
return self.context.getGroups()
def add(self, data):
# return a new IAJAXTypesGroup implementer; a IObjectCreatedEvent is generated
# alternatively, raise zope.schema.ValidationError
id = self.context.createGroup(**data)
return self.context.getGroup(id)
def remove(self, (id, item)):
# Remove this specific entry from your list
self.context.deleteGroup(id)
Groups need to have an id, items are shown in the order that get_items() returns them.
I created the class for factory
class AjaxsearchGroup(object):
"""
group of config
"""
zope.interface.implements(IAjaxsearchGroup)
registerFactoryAdapter(IAjaxsearchGroup, AjaxsearchGroup)
To use the settings
# get groups config
registry = queryUtility(IRegistry)
settings = registry.forInterface(IAjaxsearchSettings, check=False)
for config in settings.group_info:
types[config.group_name] = config.group_types
Thank you a lot!

Specify DateTime format on zope.schema.Date on Plone

I'm working on a form with Formlib that looks like this:
from zope.schema import Choice, Float, Int, Date, TextLine
from Products.Five.formlib.formbase import PageForm
class ISimuladorForm(Interface):
"""
Zope Interface for the financial simulator for sofomanec.
"""
start_date = Date(title=_(u'Start Date'),
description=_(u'Loan start date.'),
required=False)
.
.
.
class SimuladorForm(PageForm):
form_fields = form.FormFields(ISimuladorForm)
The default input format for start_date is "mm/dd/yy", but users need to input the start_date in this format: "dd/mm/yy".
How do I change the default Date format for this Interface/Schema/Form?
You can use the DateI18nWidget instead of the default DateWidget.
It takes a displayStyle attribute that controls the formatting of the value, and it'll use the request locale to format the date. displayStyle must be one of 'full', 'long', 'medium', 'short', or None and refers to the date formats defined in zope.i18n; the default is None, which I think means 'short' but this is unclear from the code.
The exact formatting is taken from the request locale, which in turn is based on the language set for the Plone site by the portal_languages tool. Thus setting the language of the site also determines what date formats the DateI18nWidget will use; these are defined in the zope.i18n package in the locales/data directory, in a set of XML files (look for the <dateFormats> element).
If this isn't satisfactory then you'll have to create a custom browser widget. Your best bet is to subclass the DateWidget yourself and provide a new _toFormValue method to format the dates the way you want.
This might be helpful to add a custom date widget to your formlib form:
http://plone.org/documentation/manual/developer-manual/forms/using-zope.formlib/customizing-the-template-and-the-widgets
I suggest to write your own date widget by deriving from one of the existing
date widget classes:
http://svn.zope.org/zope.formlib/trunk/src/zope/formlib/textwidgets.py?rev=113031&view=markup
A custom conversion of the date format using the
_toFieldValue()
_fromFieldValue()
hooks is pretty easy...look at the existing code.
This is what I did:
from zope.app.form.browser import DateI18nWidget
from zope.i18n.format import DateTimeParseError
from zope.app.form.interfaces import ConversionError
class MyDateI18nWidget(DateI18nWidget):
displayStyle = None
def _toFieldValue(self, input):
if input == self._missing:
return self.context.missing_value
else:
try:
formatter = self.request.locale.dates.getFormatter(
self._category, (self.displayStyle or None))
return formatter.parse(input.lower())
except (DateTimeParseError, ValueError), v:
raise ConversionError(_("Invalid datetime data"),
"%s (%r)" % (v, input))
class SimuladorForm(PageForm):
...
form_fields['start_date'].custom_widget = MyDateI18nWidget

Resources