What I mean is that there is no framework for creating multi-page forms and no automated support back-forward navigation. As a result you were required to hack...
True; but this framework will still have to organize WebContinuations, so addChild() will still be needed if such framework is implemented in javascript, don't you think?
Were I had to hack is when you need to preserve some local variables, such as "back" continuation, or "position" in the list of forms, or any such situation. But this will be solved with ContinuationLocals.
So, do you have in mind something totally different, or you are ok with adding addChild() method? (anyway, what is getChildren good for if it is (almost) always empty???)
Vadim
Chris
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Vadim Gritsenko wrote: <snip>
AFAIK, that is already the behavior. If you invalidate the parent, it invalidates all of its children.
Yes, if it has them. But the problem here is that he has got no children. You have to stick all the different web continuations trees generated by showForm calls into the root, and only then you can invalidate them.
Other option is to maintain ArrayList of all continuations, which is not that pretty.
Vadim
The current version of showForm creates contnuations unnecessarily (at least at the moment). I originally wrote that code to support automated back-forward navigation as in JXForms. However, multi-page presentation of Woody forms is not possible because the entire form is processed in each request. A new design for multipage Woody forms (and a new implementation of showForm()) is required in my opinion.
Why not possible? Then how it is working for me? :-)
It's actually not "multi page form" per se, but more like multiple independent forms.
Vadim
