Tres Seaver wrote:
I just checked in a preliminary pass at viewifying the
'full_metadata_form' (now 'metadata.html' as a view):
A couple of things to note:
- I adopted a "don't generalize too soon" approach on this,
rather than trying to come up with a perfect reuse example.
I have two views registered, 'metadata.html' for the template
and 'metadata.py' for the controller to which it POSTs (since
it needs to do redirects). This is a sort of "hybrid" strategy.
Before discussing *how* to implement the 'form flow' we should try to
agree on *what* we want to implement.
The best 'form flow' pattern I know (for browser forms, without using
tokens or sessions) is this:
- Forms should always be POSTed to themselves. This is the only way to
keep the URL consistent if we response with validation error feedback.
Redirecting to the original location is no option because we can't get
the POST data through a redirect.
- If a form submission was successful (means triggered a database
change), the response should always be a redirect. See this link
(Post/Redirect/Get pattern) for the reasons:
CMFFormController uses that pattern and most CMF 1.5 forms follow that
Your "hybrid" strategy works only if you *always* redirect. So it is not
suitable for implementing that pattern. Your example has no validation
and ignores completely the possibility that 'update' might fail.
I need to review Yuppie's branch for folder_contents as well:
This branch is work in progress.
What it does already:
- It shows how to use the __call__ method as dispatcher. I still believe
that using the __call__ method for this is the Right Thing.
- It splits up the big folder_contents script in a set of small methods.
I came quite far, but I'm not done.
- It doesn't change any behavior or functionality of folder_contents.
- It shares the template with the skin. This is just a proof of concept,
not sure if we need that.
What's still missing:
- Only folder_contents itself is converted into a view. It still depends
on several skin scripts.
- There are no unit tests.
- Some methods are called more than once. Some kind of caching might be
useful if these methods perform expensive tasks. The most expensive
tasks are currently performed in the __call__ method to make sure they
are called only once. I'm not happy with that.
Feedback on both branches would be appreciated; we have folks gathering
here in FXBG to hammer out the remaining viewification plan for CMF 2.0
metadata.html/metadata.py has some issues that are not related to the
viewification itself, but are new compared to full_metadata_edit:
- In CMF 1.5 all method names (besides folder_contents) are fully
configurable through Actions and Method Aliases. metadata.html has
hardcoded method names.
- metadata.py doesn't catch ResourceLockedErrors.
- The controller code is not scalable. Adding validators doesn't look
very easy and implementing something like folder_contents looks almost
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests