RELEASE: django CMS 3.5

[Daniele Procida]

I'm delighted to inform you that we have made the official release of django 
CMS 3.5!



Our weblog article above has most of what you need to know. 

The main thing to know is that this release of django CMS is significantly 
faster than before, especially when it comes to the user editing interface, and 
that this doesn't just make it quantitively faster, but transforms it into a 
qualitatively different, better, experience. It feels like a different tool.

You have to experience it to understand the difference it makes - but in 
practice, operations using the structure board  seem to be about one-third 
faster than previously (from > 22 seconds to < 12 seconds, as you'll see in the 
video in the article).

Our feedback from increasing numbers of large corporate users is that the 
latest version of django CMS is better-positioned than ever to give the CMS 
products traditionally used in that sector a very serious run for their money. 
For those of you who are developers, this represents new opportunities and 
possibilities for new clients.

Thanks to our magnificent team for all their work in this, especially Paulo 
Alvarado and Vadim Sikora here at Divio, who have co-ordinated development of 
backend and frontend components to achieve this. 

Thanks are also due to everyone who has contributed, in small ways or large, 
whether it's code, documentation, tests, bug-reports or feedback.

See the release notes: .

On behalf of all the django CMS team,

Daniele

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/20180201140801.140324090%40mail.gandi.net.
For more options, visit https://groups.google.com/d/optout.

Re: DEP Pre-posal: Re-Designing Django Forms

[Marc Tamlyn]

Hi Robert,

I have a whole heap of ideas about this, some of which are captured in
documentation here: http://django-adapters.readthedocs.io/en/latest/ The
code generally doesn't exist yet, but the project is at https://github.com/
mjtamlyn/django-adapters.

This is a *huge* project to achieve everything you mentioned in your email,
and it has implications across a large number of Django packages (not least
the admin). I don't want to discourage you, but don't underestimate how
much work it would be to get a good replacement for forms for the modern
web.

Your next steps should be to research, spec and potentially write a DEP.

Marc

On 31 January 2018 at 16:24, Collin Anderson  wrote:

> I personally use the (undocumented?) formfield() method, which takes the
> model defaults and lets you override things. I think it's pretty elegant,
> though maybe it could use some less verbose syntax (maybe have a
> forms.ModelDefault(label='Note') that does this for you).
>
> class NoteModalForm(forms.ModelForm):
> comment = Note._meta.get_field('comment').formfield(label='Note')
> is_blocker = Note._meta.get_field('is_blocker').formfield(label='Blocking
> Issue', initial=False)
> picture = Note._meta.get_field('picture').formfield(label='Picture',
> required=True, widget=DragNDropFileButtonInput(button_text='Select file
> to Upload', button_classes='btn btn-bordered uploader'))
>
> class Meta:
> model = Note
> fields = ['comment', 'is_blocker', 'equipment', 'picture']
>
> I should also note, you can change fields without overriding __init__;
> just use base_fields:
> NoteModalForm.base_fields['picture'].required = True
> NoteModalForm.base_fields['is_blocker'].initial = False
>
> As far as client-side validation goes, yes, Django really only does
> client-side validation that's available from plain html. Do you have some
> ideas for how dependent fields should work? I personally think it would be
> hard to find a one-size-fits all solution for more complicated cases, but
> it's probably possible. I think there are some 3rd party libraries that do
> this. I think a first step would be to natively handle dependent-fields
> programmatically in the back-end, so the form "knows" that those fields are
> related. Then maybe django could pass that relationship information to the
> html as data-* attributes.
>
> On Wed, Jan 31, 2018 at 10:31 AM, Robert Roskam 
> wrote:
>
>> Hey All,
>>
>> Something I've regularly run into as a challenge is the implementation of
>> Django forms work well in the simple use cases, but as the use case grows
>> in complexity, Django forms become more difficult to work with.
>>
>> I know that's a super general statement, but here's the simplest complex
>> example I can give you. Lets say you're making an application for a home
>> builder, so that their Project Managers can better coordinate the builds.
>> One of the features is the ability to take notes and pictures on anything
>> that's not yet done and specifically if it relates to a specific piece of
>> equipment (AC, furnace, water pump, etc), they can add that too. Below is a
>> moderately simplistic example:
>>
>> class Note(models.Model):
>> project = models.ForeignKey('project_management.Project',
>> related_name="notes")
>> equipment = models.ForeignKey('equipment.Equipment', null=True,
>> blank=True, related_name="notes")
>> picture = models.FileField(null=True, blank=True)
>> is_blocker = models.BooleanField(default=True)
>> comment = models.TextField()
>> created_by = models.ForeignKey('users.User', verbose_name="Created
>> By")
>> created_date = models.DateTimeField(default=timezone.now,
>> verbose_name="Created Date")
>>
>>
>> class NoteModalForm(forms.ModelForm):
>> class Meta:
>> fields = ('comment', 'is_blocker','equipment', 'picture')
>> model = Note
>> labels = {
>> 'comment': 'Note',
>> 'is_blocker': 'Blocking Issue',
>> 'picture': 'Picture',
>> }
>> widgets = {
>> 'picture': DragNDropFileButtonInput(button_text='Select file
>> to Upload',
>> button_classes='btn
>> btn-bordered uploader'),
>> }
>>
>>
>>
>> General comments first:
>>
>>1. I would say there's no better way to accomplish what is currently
>>on that form given the current Form Meta API. (Willing to be challenged on
>>this point, btw.)
>>2. The repetition of picture 3 times over (fields tuple, labels dict,
>>widgets, dict) seems to be inherently not DRY. If this gets very long, 
>> then
>>it becomes harder to manage.
>>3. The API on the Model Form itself behaves not quite like you'd
>>expect initially. You'd expect redeclaring fields directly on a form for 
>> it
>>to function like a dictionary update, if the value doesn't exist in the
>>incoming dictionary, it keeps what's