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.


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':

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.

Zope3-users mailing list

Reply via email to