Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
On Wednesday 06 June 2007 11:11, Hermann Himmelbauer wrote: I'm currently studying your doctests in z3c.form and I have to say, they are really nice to read and understandable! Thanks! Great! I am glad you like it. I'm through with forms.txt and found some minor issues, so I attached a modified version, moreover I outlined codelines which I did not understand, so maybe these could be more verbose. I have applied the changes and added an explanatory note at one of your question places, since they basically both were the same. Moreover I wanted to know if you had a look at my ORM-problem I sent you some days ago - probably you did not find time to write a demo for it, however, I would be glad to know if you think that my case can be handled via z3c.form. The problem you sent has really very little to do with ORM, but a complex object setup. I attempted to address all your needs in the new Address Book demo. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
One form demo might be a simple form that relates the input from one field to another in the form. For example two dropdown lists where second dropdown is based on what choice in first dropdown. The need for something like this is fairly common for apps I believe. Regards David Stephan Richter wrote: On Wednesday 30 May 2007 12:27, David Pratt wrote: Another form related demo might show how to effectively use a data source with a large number of choices in a select list (like choosing a user in a select list from all users on the site) using an ajax widget where you can start typing and it will begin narrowing the choices - much like the way live search works (and without generating all options in the form). Yeah, there are some demos related to AJAX-features that could be done. Roger is already working on AJAX-related demos, including live search and input validation. Regards, Stephan ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
It would be very interesting to see RDBMS interaction. Formlib for example is not trivial to use with RDBMS especially because of a lack of documentation and because everything seems to be written with ZODB objects in mind. It works together with a mapper like SQLAlchemy (and z3c.zalchemy). IMHO, it is not formlib's task to do mappings like that. Not sure what mappings you're talking about. I just want to know how can I get some data from somewhere (it may be a file, RDBMS or other external source) and display it in a form, then edit this data etc. Formlib default forms (EditForm, AddForm) assume that it works with content objects and I just want to call SQLScript to get data for my form and to commit it back to RDBMS. Not so difficult but there are no docs and no demos for this with formlib. Thats why I'd like to know how to do such things with z3c.form. -- Maciej Wisniowski ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
It works together with a mapper like SQLAlchemy (and z3c.zalchemy). IMHO, it is not formlib's task to do mappings like that. Not sure what mappings you're talking about. I just want to know how can I get some data from somewhere (it may be a file, RDBMS or other external source) and display it in a form, then edit this data etc. Formlib default forms (EditForm, AddForm) assume that it works with content objects and I just want to call SQLScript to get data for my form and to commit it back to RDBMS. Not so difficult but there are no docs and no demos for this with formlib. Thats why I'd like to know how to do such things with z3c.form. you should redefine getContent method on your form, inside getContent you can get data from anywhere and return it in dict. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
On Thursday 31 May 2007 02:25, Nikolay Kim wrote: Not sure what mappings you're talking about. I just want to know how can I get some data from somewhere (it may be a file, RDBMS or other external source) and display it in a form, then edit this data etc. Formlib default forms (EditForm, AddForm) assume that it works with content objects and I just want to call SQLScript to get data for my form and to commit it back to RDBMS. Not so difficult but there are no docs and no demos for this with formlib. Thats why I'd like to know how to do such things with z3c.form. you should redefine getContent method on your form, inside getContent you can get data from anywhere and return it in dict. Yes, this is correct. You can also have other data structures. All you have to do is to develop and register a new data manager. By default there are two data managers registered: one for instances and one for dicts. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
Am Donnerstag, 31. Mai 2007 08:09 schrieb Maciej Wisniowski:
It would be very interesting to see RDBMS interaction. Formlib for
example is not trivial to use with RDBMS especially because of a lack
of documentation and because everything seems to be written with ZODB
objects in mind.
It works together with a mapper like SQLAlchemy (and z3c.zalchemy).
IMHO, it is not formlib's task to do mappings like that.
Not sure what mappings you're talking about. I just want to
know how can I get some data from somewhere (it may be a
file, RDBMS or other external source) and display it in a form,
then edit this data etc. Formlib default forms (EditForm, AddForm)
assume that it works with content objects and I just want to call
SQLScript to get data for my form and to commit it back to RDBMS.
Not so difficult but there are no docs and no demos for this with
formlib. Thats why I'd like to know how to do such things
with z3c.form.
I also still struggle with this issue. In my case, I have the following
scenarios:
- Some ORM-object attributes directly map to fields, but these attributes may
be in referenced ORM-objects
- Sometimes I want to map the first referenced ORM-object (which is
represented as the first list entry) to a field.
However, any field which is displayed is somewhere already described as an
interface schema field for an ORM object, which I of course want to reuse.
Moreover I want to write minimal HTML-code as possible, but auto-generating
fields does not work for me.
I currently try to solve these issues with a self-made Form class, which
descends from form.Form. In case you are interested, here is my docstring
which somehow explains the basic idea:
snip -
A generic form class for rendering forms based on object data
The class has the following key attributes:
- widget_template_files: A sequence of widget template files that can be
used
in widgets to display a form field in a specific way
- schema_fields:
- template: Same as the template attribute in form.Form, this specifies
the template
that should be used for rendering the page
- schema_fields: a sequence of schema fields that can be copied from
interfaces via
the function cloneField, e.g. cloneField(IFoo['bar']).
When schema fields are created via the cloneField function, additional
attributes can
be set on the fields. The programmer has to make sure, that the names of
the schema
fields are distinct, hence in case schema fields have the same name, the
__name__ attribute
has to be set to a distinct name.
Default values for fields can be automatically fetched and updated. How
the mapping between
the form fields and the data object is implemented, can either implicitly
or explicitly
defined.
1) Explicit declaration:
- If the schema field has the attribute obj_attr, the specified
attribute is used
for reading/updating data. If the attribute does not exist, an error is
raised
- If the schema field has the attribute obj_getter or/and obj_setter,
the data
object is queried for a matching method, which are used for
getting/setting values.
2) Implicit declaration:
- If data object has methods beginning with set_ and/or get_ and match
the
__name__ attribute of the schema field, these methods are
automatically used
for getting/setting values.
The precedence is as follows:
1) explicit getter/setter
2) implicit getter/setter
3) obj_attr
-- snip ---
An example would look like this (cloneField does basically only a
copy.deepcopy of the interface):
--- snip ---
schema_fields = (
cloneField(IFp['name1'], obj_attr = 'fp.name1'),
cloneField(IFp['name2'], obj_attr = 'fp.name2'),
cloneField(IFp['titel'], obj_attr = 'fp.titel'))
template = ViewPageTemplateFile('fpform.pt')
widget_template_files = ('widget_div.pt', 'widget_span.pt')
- snip -
widget_div.pt has the common Zope3-HTML form code like this:
- snip -
tal:block tal:define=widget python: options.get('widget', None)
div class=label
label for=field.name title=The widget's hint
tal:attributes=for widget; title widget/hint
tal:content=widget/labelLabel/label
/div
div tal:condition=widget/error
tal:content=structure widget/errorError/div
div class=field
input tal:replace=structure widget /
/div
/tal:block
- snip -
And fpform.pt is then very tidy:
snip
div tal:replace=structure view/widgets/name1/template_widget_div /
div tal:replace=structure view/widgets/name2/template_widget_div /
div tal:replace=structure view/widgets/titel/template_widget_div /
snip -
My
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
On Thursday 31 May 2007 03:48, Hermann Himmelbauer wrote: Anyway, in my case a decent ORM-integration with Zope3 forms is still a key issue to me. If you provide me with a simple hello world-like example of the ORM stuff you are using, then I will give it a try to write a demo for z3c.form. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
Am Donnerstag, 31. Mai 2007 10:16 schrieb Stephan Richter: On Thursday 31 May 2007 03:48, Hermann Himmelbauer wrote: Anyway, in my case a decent ORM-integration with Zope3 forms is still a key issue to me. If you provide me with a simple hello world-like example of the ORM stuff you are using, then I will give it a try to write a demo for z3c.form. Thanks a lot, I attached a simple data structure to this mail and a description how the form should look like. This example covers all aspects I am currently struggling with and which I somehow solved with my class (however, I could still not solve the multi-widget/list issue with the phone numbers in the example). Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 orm_example.py Description: application/python ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
I also still struggle with this issue. In my case, I have the following scenarios: I currently try to solve these issues with a self-made Form class, which descends from form.Form. In case you are interested, here is my docstring which somehow explains the basic idea: Thanks for the code. I'm using old (?) way with SQLScripts not with ORM's so may case is a bit different. I've also created my own library that extends formlib: 'dbformlib' (available at google code) for such things. I'm not sure why do you have to clone fields, possibly because of ORM specifics? Idea of widget_template_files is very interesting. I need to see docs and code for z3c.form now :) -- Maciej Wisniowski ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
On Friday 25 May 2007 02:55, Darryl Cousins wrote: Congratulations Stephan and Roger. Thanks. I've only read through 3 of the 5 'must read' doctest files. I remember my first reading of formlib/form.txt and being overwhelmed. This has been the opposite experience. Great! That's good to hear! I always hope that me doctests read like a book while still ensuring full test coverage. The demos are impressive, to say the least. Thanks. BTW, I am still looking for 1-2 demos to write but I am out of ideas. Do have anything related to forms that you would like to see demoed? There is much by way of example in the writing of your doctests. Thanks for this effort. You are welcome. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
Thanks. BTW, I am still looking for 1-2 demos to write but I am out of ideas. Do have anything related to forms that you would like to see demoed? It would be very interesting to see RDBMS interaction. Formlib for example is not trivial to use with RDBMS especially because of a lack of documentation and because everything seems to be written with ZODB objects in mind. -- Maciej Wisniowski ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
Another form related demo might show how to effectively use a data source with a large number of choices in a select list (like choosing a user in a select list from all users on the site) using an ajax widget where you can start typing and it will begin narrowing the choices - much like the way live search works (and without generating all options in the form). Regards David David Pratt wrote: Hi Stephan and Roger. This is a great package. Thank you for this work. As far as other demos, I'd like to see a couple of things: 1) An iteration of the wizard that will not allow show submit button or allow submit until the end of all steps. 2) A demo to show how fields can be grouped. Something like Django forms with grouping would be really nice. Regards, David Stephan Richter wrote: On Friday 25 May 2007 02:55, Darryl Cousins wrote: Congratulations Stephan and Roger. Thanks. I've only read through 3 of the 5 'must read' doctest files. I remember my first reading of formlib/form.txt and being overwhelmed. This has been the opposite experience. Great! That's good to hear! I always hope that me doctests read like a book while still ensuring full test coverage. The demos are impressive, to say the least. Thanks. BTW, I am still looking for 1-2 demos to write but I am out of ideas. Do have anything related to forms that you would like to see demoed? There is much by way of example in the writing of your doctests. Thanks for this effort. You are welcome. Regards, Stephan ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
On Wednesday 30 May 2007 11:06, David Pratt wrote: 1) An iteration of the wizard that will not allow show submit button or allow submit until the end of all steps. I have implemented this feature. The Finish button will now only show up when all required fields are filled out. You can update your z3c.formdemo checkout or download version 1.1.0. 2) A demo to show how fields can be grouped. Something like Django forms with grouping would be really nice. My two standard answers for this are usually: 1. Use sub-forms. That's what they are for. 2. Grouping fields does not make much sense, since in projects you want to lay out widgets/fields manually anyways. However, the first answer does not seem to fit your use case well and the second is a bummer for beginners. So, how would *you* like to see grouping of fields working? There are several options here. For one, one could claim that interfaces already group fields, so I could use them to define groups: fields = field.Fields(interfaces.IPerson) fields.groups[IPerson].title = u'Person' Another option would be to define groups on the fields manager: fields = field.Fields(interfaces.IPerson, group='person') fields.groups['person'].title = u'Person' We could also reuse the prefex: fields = field.Fields(interfaces.IPerson, prefix='person') fields.groups['person'].title = u'Person' Some other approaches could include making multiple field.Fields instances or have different field.Field implementations, similar to buttons. The next question would then be how to iterate through the groups in the widget manager. Would this be okay? widgets.groups['person'].values() [...] Anyways, let me know hoe it could be done and I think about it some more. A django example would be nice too. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
Hi Stephan. Thanks for your reply. For #2, the following excerpt from
django's documentation located here:
http://www.djangoproject.com/documentation/tutorial02/
snip
And speaking of forms with dozens of fields, you might want to split the
form up into fieldsets:
class Admin:
fields = (
(None, {'fields': ('question',)}),
('Date information', {'fields': ('pub_date',)}),
)
The first element of each tuple in fields is the title of the fieldset.
Here’s what our form looks like now:
... image
You can assign arbitrary HTML classes to each fieldset. Django provides
a collapse class that displays a particular fieldset initially
collapsed. This is useful when you have a long form that contains a
number of fields that aren’t commonly used:
class Admin:
fields = (
(None, {'fields': ('question',)}),
('Date information', {'fields': ('pub_date',), 'classes':
'collapse'}),
)
... image
/snip
I haven't thought of the best way of implementing this at this point
since I am just coming up to speed with your package.
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.
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.
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
Regards,
David
Stephan Richter wrote:
On Wednesday 30 May 2007 11:06, David Pratt wrote:
1) An iteration of the wizard that will not allow show submit button or
allow submit until the end of all steps.
I have implemented this feature. The Finish button will now only show up
when all required fields are filled out. You can update your z3c.formdemo
checkout or download version 1.1.0.
2) A demo to show how fields can be grouped. Something like Django forms
with grouping would be really nice.
My two standard answers for this are usually:
1. Use sub-forms. That's what they are for.
2. Grouping fields does not make much sense, since in projects you want to lay
out widgets/fields manually anyways.
However, the first answer does not seem to fit your use case well and the
second is a bummer for beginners. So, how would *you* like to see grouping of
fields working?
There are several options here. For one, one could claim that interfaces
already group fields, so I could use them to define groups:
fields = field.Fields(interfaces.IPerson)
fields.groups[IPerson].title = u'Person'
Another option would be to define groups on the fields manager:
fields = field.Fields(interfaces.IPerson, group='person')
fields.groups['person'].title = u'Person'
We could also reuse the prefex:
fields = field.Fields(interfaces.IPerson, prefix='person')
fields.groups['person'].title = u'Person'
Some other approaches could include making multiple field.Fields instances
or have different field.Field implementations, similar to buttons.
The next question would then be how to iterate through the groups in the
widget manager. Would this be okay?
widgets.groups['person'].values()
[...]
Anyways, let me know hoe it could be done and I think about it some more. A
django example would be nice too.
Regards,
Stephan
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
Am Mittwoch, den 30.05.2007, 18:12 +0200 schrieb Maciej Wisniowski: Thanks. BTW, I am still looking for 1-2 demos to write but I am out of ideas. Do have anything related to forms that you would like to see demoed? It would be very interesting to see RDBMS interaction. Formlib for example is not trivial to use with RDBMS especially because of a lack of documentation and because everything seems to be written with ZODB objects in mind. It works together with a mapper like SQLAlchemy (and z3c.zalchemy). IMHO, it is not formlib's task to do mappings like that. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
On Sunday 27 May 2007 18:55, Vinny wrote: I did try the above, but it complained about needing a newer setuptools than I had. No big deal, I can update that easily enough. This is really strange. I thought that bootstrap.py would install the version of setuptools that is needed, but other people know more about setuptools and buildout to give better advice. Anyone? Before I go further though, does the above command set install a full version of zope and if so, what version? Do I need 3.4.0a1 to run this demo or can I use 3.3.0 or 3.3.1? I'm running 3.3.0 but can upgrade to 3.3.1. You will not need anything. Buildout will pull down all the eggs you need for you and install it in a local eggs directory, not effecting your global Python install at all! The z3c.form* packages do work with Zope 3.3.0 or Zope 3.4.0b1. I just checked in and released a compatibility module for z3c.form. Installation All packages have been released in source and binary-egg format on PyPI and ``download.zope.org/distribution``. You can use setuptools to install them. Here is a list of all packages: * z3c.form * z3c.formui * z3c.formdemo * jquery.javascript * jquery.layer * jquery.widget So, perhaps I can install those packages (in instance/lib/python) and I should be good to go? That would be one way to go. Of course you also need to isntall the ZCML slugs. However, the 5 steps to run the demo will do everything for you to get the demo to run. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
On Monday 28 May 2007 01:55, Darryl Cousins wrote: As to the version - I have no idea how that works with the egg distribution of separate packages. Both Zope 3.3 and Zope 3.4 work now with the z3c.form* packages. Of course, there are no eggs for Zope 3.3, so you cannot use setuptools for that version. But we do have support for the ZCML slugs, the the usual method works. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
On Wednesday 30 May 2007 12:27, David Pratt wrote: Another form related demo might show how to effectively use a data source with a large number of choices in a select list (like choosing a user in a select list from all users on the site) using an ajax widget where you can start typing and it will begin narrowing the choices - much like the way live search works (and without generating all options in the form). Yeah, there are some demos related to AJAX-features that could be done. Roger is already working on AJAX-related demos, including live search and input validation. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-dev] Re: [Zope3-Users] z3c.form 1.0.0 released!
On Wednesday 30 May 2007 15:07, David Pratt wrote:
class Admin:
fields = (
(None, {'fields': ('question',)}),
('Date information', {'fields': ('pub_date',)}),
)
This is s 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
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
On 31.05.2007, at 05:08, Stephan Richter wrote: On Sunday 27 May 2007 18:55, Vinny wrote: I did try the above, but it complained about needing a newer setuptools than I had. No big deal, I can update that easily enough. This is really strange. I thought that bootstrap.py would install the version of setuptools that is needed, but other people know more about setuptools and buildout to give better advice. Anyone? i had exactly the same problem with the bootstrap when i first used buildout i think it needs at least version 6c5, but i am not sure issue the command: sudo easy_install -U setuptools to upgrade setuptools ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
Hi Vinny, On Sun, 2007-05-27 at 18:55 -0400, Vinny wrote: For the curious and impatient ... - To run the demos do the following:: $ svn co svn://svn.zope.org/repos/main/z3c.formdemo/trunk formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout $ ./bin/demo fg I did try the above, but it complained about needing a newer setuptools than I had. No big deal, I can update that easily enough. Before I go further though, does the above command set install a full version of zope and if so, what version? Do I need 3.4.0a1 to run this demo or can I use 3.3.0 or 3.3.1? I'm running 3.3.0 but can upgrade to 3.3.1. Some tips with buildout that work for me. Create ~/.buildout/default.cfg:: [buildout] eggs-directory=/path/to/eggs develop-eggs-directory=/path/to/develop-eggs #optional Of course choose your own egg directories. Then run the buildout as in original post. This will take an awfully long time. The next time you install another zope 3 app from buildout, it will use the same eggs directory:: ./bin/buildout -N The -N means that it won't look for newer eggs if the local egg satisfies requirements. And it will take no time at all. As to the version - I have no idea how that works with the egg distribution of separate packages. Hope this helps. Regards, Darryl ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] z3c.form 1.0.0 released!
Hi, Congratulations Stephan and Roger. I've only read through 3 of the 5 'must read' doctest files. I remember my first reading of formlib/form.txt and being overwhelmed. This has been the opposite experience. The demos are impressive, to say the least. There is much by way of example in the writing of your doctests. Thanks for this effort. Regards, Darryl On Thu, 2007-05-24 at 12:01 -0400, Stephan Richter wrote: Hello everyone, Roger and I are proud to announce the first release of the new form and widget framework ``z3c.form``! After years of talking about it, months of thinking about it and many weeks of implementation, we have finally completed it. For the curious and impatient ... - To run the demos do the following:: $ svn co svn://svn.zope.org/repos/main/z3c.formdemo/trunk formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout $ ./bin/demo fg Now you can access the demo under: http://localhost:8080/ Since this takes a while to build, you can read on while waiting for the demo to come up. :-) Goals of z3c.form - While taking the best of the older ``zope.app.form`` and ``zope.formlib`` packages, this new framework provides much more flexibility and hooks as are needed in daily development. For example, creating a simple form can look almost identical to ``zope.formlib``, but integrating sub-forms is much simpler. Another important issue for us was keeping up-to-date with today's latest Web developments, especially AJAX-features. It is an expressed goal of this framework to provide enough flexibility to fully support AJAX-driven forms and widgets. A secondary goal is to provide flexibility to allow experimentation with new ideas without interupting the entire framework. Many of the features are implemented as components allowing simple replacement as desired. State of the Code - We consider the code feature complete with some real-world user scenarios implemented. The framework has not been used in a production environment yet, but we will base all our future project on it and switch older projects to this framework as needed. z3c.form This is the main package implementing the framework. It is 100% tested in a multitude of text files; start by reading README.txt, which provides you with an overview and priorities the text files for you. Unit Tests: 478 Documentation: 193k in 24 text files Architecture Layout: form-graph.png, widget-graph.png z3c.formui ~~ This package contains some base templates for DIV- and TABLE-based form layouts. Both layout options are implemented in different layers, allowing you to chose either layout default by simply adding the layer to your skin. z3c.formdemo Here you will find some small demo sub-packages that demonstrate the framework as it is to be used: * Hello World Message A demo of adding, editing and displaying simple message objects. It demonstrates the simple usage of add, edit and display forms. It also adds another button to the edit form. * Widgets A simple form whose purpose is to demonstrate the completeness of the input widgets. All fields except Dict and Object have an input widget as demonstrated in the form. It also demonstrates how the content object retrieval can be customized in a form. * Calculator A simple calculator implemented as a form. The demo shows how to write different types of buttons, register handlers for those button types and hook in a custom action manager. * Wizard This simple, linear wizard demonstrates the sub-form capabilities of ``z3c.form``. Since these packages do not provide an object widget, this demostration also shows how this need can bebetter solved using sub-forms. * Table/Spreadsheet This little table allows you to add and edit a simple content component within a table. The table is rendered using the ```zc.table`` package demonstrating how the two packages can be used together. jquery.* The ``jquery`` namespace packages provide a first attempt to have AJAX-enabled forms. It is already possible to validate widget values and do some other form-unrelated UI goodies. The features within the ``jquery`` and form packages will soon be demonstrated in detail on the new www.zope.org website, which will also be available in code form as ``z3c.website``. So stay tuned! Installation All packages have been released in source and binary-egg format on PyPI and ``download.zope.org/distribution``. You can use setuptools to install them. Here is a list of all packages: * z3c.form * z3c.formui * z3c.formdemo * jquery.javascript * jquery.layer * jquery.widget Enjoy! Regards, Roger and Stephan ___ Zope3-users mailing list Zope3-users@zope.org
[Zope3-Users] z3c.form 1.0.0 released!
Hello everyone, Roger and I are proud to announce the first release of the new form and widget framework ``z3c.form``! After years of talking about it, months of thinking about it and many weeks of implementation, we have finally completed it. For the curious and impatient ... - To run the demos do the following:: $ svn co svn://svn.zope.org/repos/main/z3c.formdemo/trunk formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout $ ./bin/demo fg Now you can access the demo under: http://localhost:8080/ Since this takes a while to build, you can read on while waiting for the demo to come up. :-) Goals of z3c.form - While taking the best of the older ``zope.app.form`` and ``zope.formlib`` packages, this new framework provides much more flexibility and hooks as are needed in daily development. For example, creating a simple form can look almost identical to ``zope.formlib``, but integrating sub-forms is much simpler. Another important issue for us was keeping up-to-date with today's latest Web developments, especially AJAX-features. It is an expressed goal of this framework to provide enough flexibility to fully support AJAX-driven forms and widgets. A secondary goal is to provide flexibility to allow experimentation with new ideas without interupting the entire framework. Many of the features are implemented as components allowing simple replacement as desired. State of the Code - We consider the code feature complete with some real-world user scenarios implemented. The framework has not been used in a production environment yet, but we will base all our future project on it and switch older projects to this framework as needed. z3c.form This is the main package implementing the framework. It is 100% tested in a multitude of text files; start by reading README.txt, which provides you with an overview and priorities the text files for you. Unit Tests: 478 Documentation: 193k in 24 text files Architecture Layout: form-graph.png, widget-graph.png z3c.formui ~~ This package contains some base templates for DIV- and TABLE-based form layouts. Both layout options are implemented in different layers, allowing you to chose either layout default by simply adding the layer to your skin. z3c.formdemo Here you will find some small demo sub-packages that demonstrate the framework as it is to be used: * Hello World Message A demo of adding, editing and displaying simple message objects. It demonstrates the simple usage of add, edit and display forms. It also adds another button to the edit form. * Widgets A simple form whose purpose is to demonstrate the completeness of the input widgets. All fields except Dict and Object have an input widget as demonstrated in the form. It also demonstrates how the content object retrieval can be customized in a form. * Calculator A simple calculator implemented as a form. The demo shows how to write different types of buttons, register handlers for those button types and hook in a custom action manager. * Wizard This simple, linear wizard demonstrates the sub-form capabilities of ``z3c.form``. Since these packages do not provide an object widget, this demostration also shows how this need can bebetter solved using sub-forms. * Table/Spreadsheet This little table allows you to add and edit a simple content component within a table. The table is rendered using the ```zc.table`` package demonstrating how the two packages can be used together. jquery.* The ``jquery`` namespace packages provide a first attempt to have AJAX-enabled forms. It is already possible to validate widget values and do some other form-unrelated UI goodies. The features within the ``jquery`` and form packages will soon be demonstrated in detail on the new www.zope.org website, which will also be available in code form as ``z3c.website``. So stay tuned! Installation All packages have been released in source and binary-egg format on PyPI and ``download.zope.org/distribution``. You can use setuptools to install them. Here is a list of all packages: * z3c.form * z3c.formui * z3c.formdemo * jquery.javascript * jquery.layer * jquery.widget Enjoy! Regards, Roger and Stephan ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
