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.

Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-users mailing list

Reply via email to