[Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!

[David Pratt]

Hi Stephan. First of all, thank you for the change to the wizard.

On the points below, despite the code structure, the resulting groups 
are good for making logical separations. It provides another alternative 
for making these. It also provides a simple means to tuck some fields 
away as well.

Zope code is certainly easier on the eyes :-) and to also to read doc 
tests. This makes it much more easily understood. Demos simply make 
design patterns clear for folks. This is where I feel that this can make 
the difference between recognizing package functionality and actually 
deploying the package in the way it was designed.

Looks like I missed the other buttons so I am happy they are there. Many 
thanks for your effort on this excellent package.

Regards,
David

Stephan Richter wrote:
> On Wednesday 30 May 2007 15:07, David Pratt wrote:
>> class Admin:
>>      fields = (
>>          (None, {'fields': ('question',)}),
>>          ('Date information', {'fields': ('pub_date',)}),
>>      )
> 
> This is soooooooooooo lame! We have this great OO language and they do such 
> simple C-like structures.
> 
> I also disagree with their motivations for totally auto-generated forms. They 
> say that admin interfaces are usually just simple forms. In my opinion this 
> is bad UI design. In fact, I found admin interfaces often the biggest 
> challenge, because people do not think them through, but users then complain 
> if the admin UI is not efficient.
> 
>> class Admin:
>>      fields = (
>>          (None, {'fields': ('question',)}),
>>          ('Date information', {'fields': ('pub_date',), 'classes':
>> 'collapse'}),
>>      )
> 
> This is just flat-out lame. I could never use django and be happy.
> 
>> I very much like the suggestion of defining groups on the field manager.
>> What you are suggesting is intuitive. In the django code, the group can
>> be named, which provides an optional title for the field set for the
>> form. Additionally, a class is passed in so you can use it for with some  
>> js to be initially collapsed when rendered. Similarly, these optional
>> parameters would be useful to pass on.
> 
> Yeah, except that we will do that sensibly using a class. Then we can do as 
> much as we want to with a group.
> 
>> values() seems logical for iterating over groups for the widget manager.
>> I guess some thought on how the group (field set) itself may be
>> integrated into a widget so a bit of js can be used to collapse and
>> expand it would be the otherpart.
> 
> I am not willing to change the widget manager API. This is silly, since very 
> few use cases require groups. I think an extension to the widget manager API 
> would be appropriate. So, I would create this iface:
> 
> class  IGroupsWidgetManager(IWidgetManager):
> 
>   groups = zope.interface.Attribute('Group Mapping')
> 
> Then groups is an ordered mapping from name to group. A group in return is 
> just an extended widget manager:
> 
> class IGroupWidgetManager(IWidgetManager):
>   title = zope.schema.TextLine(u'Ttile of the group used for the legend.')
>   css = zope.schema.TextLine(u'CSS class set of the fieldset.')
>   ...
> 
> Now I am just thinking about the best way to define the groups in the fields 
> manager. Specifically, whether I am going to extend the existing 
> implementations or write new ones. Probably write new ones, since I am pretty 
> happy with the current API.
> 
>> Unrelated to this is another small addition for the demo. This is to
>> show a form with a couple of additional useful form buttons (another
>> nice feature integrated in django forms)
>>
>> Save and add another
>> Save and continue editing
> 
> I did that already. The message demo shows "Apply" and "Apply and View", the 
> former is the same as "Save and continue editing". The "Save and add another" 
> case I demonstrate in the spreadsheet/table demo. I also have a comment in 
> the code what to do different, when wanting to add just one entry.
> 
> Regards,
> Stephan