Re: [Zope-CMF] Re: CMF and Five views: hooking up "POST"
yuppie wrote at 2005-10-17 15:24 +0200: > ... >I don't think so: > >1.) If you start rendering the default view before the controller has >finished you need extra code to abort the rendering if necessary. E.g. a >tal:condition that wraps the whole template. > >2.) A cleaner separation of controller calls and view rendering makes >the code simpler and therefore easier to write and maintain. > >3.) Rendering useless views wastes resources. "CMFFormController" does a nice job in this respect. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
Hi Tres! Tres Seaver wrote: Lennart Regebro wrote: On 10/17/05, yuppie wrote: I know that pattern, but I don't like it. [...] The code on the goldegg-folder_contents branch processes the input in the __call__ method of the view class. The template is only invoked if needed. It's much cleaner to use the template just for displaying results, not for triggering controllers. That's purely a matter of taste. From a principal standpoint I don't think there is any difference, really. I think we might be able to come up with a heuristic for choosing between the two patterns (this might be a mini pattern language, if refined): - For "simple" forms, which redisplay themselves even after a successful POST, and which do not redirect, prefer a template-driven version, and make the form self-posting; in ZCML, use with the 'template' attribute). The classic 'document_edit' form fits this bill, I think. I don't know many use cases for 'simple' forms. 'document_edit' redirects to itself if 'change' was successful and to view if 'change_and_view' was successful. The redirect after a successful update is necessary to avoid further changes if people reload the page. And even if we have a 'simple' form: A customized '__call__' method is simpler than a 'Update' method that has to be called from the template. - If you have to add logic to the template to cope with possible redirects, then publish a method of the view, and have the view redirect or return a template; in ZCML, use with the 'attribute' variant. "Add" forms fit this pattern, as well as the folder_contents stuff that Yuppie has done. If we call an 'attribute' we can't specify the template in ZCML. We have to hard-code the template in the view class. Using the '__call__' method we can get the advantages of both patterns. The folder_contents stuff uses the '__call__' method. - For a set of inter-related pages sharing common view logic, you may end up mixing and matching -- the ':method' bit on submit button names is a way to get "off" the original template when needed. ZCML for this case may either be a mixture of the 'template' and 'attribute' variants of , or else with several subdirectives. I don't like using ':method' because that pattern uses the same URL for different pages. But I never tried to use ':method' with views. Does that even work? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
Hi Lennart! Lennart Regebro wrote: On 10/17/05, yuppie wrote: I know that pattern, but I don't like it. [...] The code on the goldegg-folder_contents branch processes the input in the __call__ method of the view class. The template is only invoked if needed. It's much cleaner to use the template just for displaying results, not for triggering controllers. That's purely a matter of taste. From a principal standpoint I don't think there is any difference, really. I don't think so: 1.) If you start rendering the default view before the controller has finished you need extra code to abort the rendering if necessary. E.g. a tal:condition that wraps the whole template. 2.) A cleaner separation of controller calls and view rendering makes the code simpler and therefore easier to write and maintain. 3.) Rendering useless views wastes resources. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On 10/17/05, yuppie <[EMAIL PROTECTED]> wrote: > >>I know that pattern, but I don't like it. [...] >>The code on the goldegg-folder_contents branch processes the input in >>the __call__ method of the view class. The template is only invoked if >>needed. It's much cleaner to use the template just for displaying >>results, not for triggering controllers. > > > That's purely a matter of taste. From a principal standpoint I don't > think there is any difference, really. I think we might be able to come up with a heuristic for choosing between the two patterns (this might be a mini pattern language, if refined): - For "simple" forms, which redisplay themselves even after a successful POST, and which do not redirect, prefer a template-driven version, and make the form self-posting; in ZCML, use with the 'template' attribute). The classic 'document_edit' form fits this bill, I think. - If you have to add logic to the template to cope with possible redirects, then publish a method of the view, and have the view redirect or return a template; in ZCML, use with the 'attribute' variant. "Add" forms fit this pattern, as well as the folder_contents stuff that Yuppie has done. - For a set of inter-related pages sharing common view logic, you may end up mixing and matching -- the ':method' bit on submit button names is a way to get "off" the original template when needed. ZCML for this case may either be a mixture of the 'template' and 'attribute' variants of , or else with several subdirectives. How does that sound? Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDU6Un+gerLs4ltQ4RAt7lAJsGoqwDOJ3JlzEsjGy5U2+wT36dvwCZAUde BsjX68zwDWcatkVxWaF7ZoA= =3aqS -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
On 10/17/05, yuppie <[EMAIL PROTECTED]> wrote: > I know that pattern, but I don't like it. [...] > The code on the goldegg-folder_contents branch processes the input in > the __call__ method of the view class. The template is only invoked if > needed. It's much cleaner to use the template just for displaying > results, not for triggering controllers. That's purely a matter of taste. From a principal standpoint I don't think there is any difference, really. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
Hi Lennart! Lennart Regebro wrote: The standard Zope3-ish way is to have a m,ethod called Update() which you call every time the views template is displayed. This method can prepare all the data to be displayed, as well as handle any form postings. Instead of checking on POST I usually check on the button-presses, but of course if you don't want GET-forms to work, checking for POST is the right thing to do. I know that pattern, but I don't like it. While the default action is to display the results of 'Update' in the template of the view, we can't be sure that's the case before we processed the input. It doesn't make sense to invoke the template if we return a redirect. The code on the goldegg-folder_contents branch processes the input in the __call__ method of the view class. The template is only invoked if needed. It's much cleaner to use the template just for displaying results, not for triggering controllers. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF and Five views: hooking up "POST"
The standard Zope3-ish way is to have a m,ethod called Update() which you call every time the views template is displayed. This method can prepare all the data to be displayed, as well as handle any form postings. Instead of checking on POST I usually check on the button-presses, but of course if you don't want GET-forms to work, checking for POST is the right thing to do. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
Hi Jens! Jens Vagelpohl wrote: On 16 Oct 2005, at 16:21, yuppie wrote: Jens Vagelpohl wrote: Doing some more work on Five views for CMF right now. I have the edit view hooked up and working find for my sample content type. The view class given to me by Tres defines a POST method, but I can't seem to get that hooked up correctly. These sentences don't make any sense to me: What is your goal? Why do you need to 'hook up' POST if your edit view works already? When should your POST method be called and what does that POST method? Are you working on something special or just on a normal edit view? The goal is very simple: The edit form posts to itself. If a POST is received, I want to edit the content item with the values from itself. Very same principle as we have now, with the exception that the current setup looks into the REQUEST to find button names to decide on what to do. Again, I'm working with a class Tres gave me which has a POST method on the editing view class. Don't know why Tres gave you a class with a POST method. Are you aware of the goldegg-folder_contents branch? CMFDefault/browser shows a working example. (Well. While refactoring the code I broke some logic, but the view itself works.) HTH Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
On 16 Oct 2005, at 16:21, yuppie wrote: Jens Vagelpohl wrote: Doing some more work on Five views for CMF right now. I have the edit view hooked up and working find for my sample content type. The view class given to me by Tres defines a POST method, but I can't seem to get that hooked up correctly. These sentences don't make any sense to me: What is your goal? Why do you need to 'hook up' POST if your edit view works already? When should your POST method be called and what does that POST method? Are you working on something special or just on a normal edit view? The goal is very simple: The edit form posts to itself. If a POST is received, I want to edit the content item with the values from itself. Very same principle as we have now, with the exception that the current setup looks into the REQUEST to find button names to decide on what to do. Again, I'm working with a class Tres gave me which has a POST method on the editing view class. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF and Five views: hooking up "POST"
Jens Vagelpohl wrote: Doing some more work on Five views for CMF right now. I have the edit view hooked up and working find for my sample content type. The view class given to me by Tres defines a POST method, but I can't seem to get that hooked up correctly. These sentences don't make any sense to me: What is your goal? Why do you need to 'hook up' POST if your edit view works already? When should your POST method be called and what does that POST method? Are you working on something special or just on a normal edit view? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
