There's a diagram in the docs for our FormKit that may help clarify the situation:
http://dalchemy.com/opensource/formkit/architecture.html
About half way down.
For form processing, we changed pre-action and post-action to merge the lifecycle more closely back into the normal respond; basically, we call writeHTML from post-action, which effectively inserts actions in *before* the output, rather than doing "some" of the output in pre/post.
Yes, that's pretty much what I was thinking too -- I was putting writeHTML in respond, but it fits more cleanly in postAction.
Another option would be to require the action author to call writeHTML manually. When you are creating non-HTML content based on an action this can be convenience -- specifically, external editor support in the wiki does this for one action, but all the other actions do normal HTML processing.
The way I do it there is with the special view attribute, where writeHTML is entirely suppressed if ``not self.view``. But requiring an explicit call to writeHTML would also work, and wouldn't require any very dramatic changes to Page (really, just a change to convention).
Ian
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
