Marc Portier wrote > > I think this has to be changed :) It should be done dynamically when > > the form is "rendered". > > > > this is fundamentally different to how it is done now > > we seem to think there is some advantage for 'caching' the > form-definition and instantiating the form from there > > even worse: the flow examples to date are holding a reference to > the form instance (just to give a popular usage example) > > as is now (and redeamed useful) the form has an important > function in analyzing the request-parameters and triggering the > validation.... all of those are happening before even deciding > which business object should be retrieved or if the form needs to > be rendered again or not... > > to support the general case woody kind of takes the existance of > it's form-definition prior to the existence of any business > object model (because it should be useable without it?) > Hmm, ok, caching does not prevent to have some dynamic elements in it. You can cache, let's say 89%, and 11% are calculated dynamically.
A question I was always asking myself is: how does woody handle user dependent forms? Which means, if the same form is used inside a user session and for example the user can edit his personal information. So you have a Form object for each user but use of course the same form description. Is this possible? (I guess so, but just want to make sure). > > Now, one of the problems is that I'm still not that familiar with > > the woody terms, but on the other hand of a clear vision on how > > it should work. > > > > well, you have a clear vision of what you want to do, and I try > to map that on what woody does, and which sensible changes could > be made based on the interesting features you bring > And I really appreciate that! > I think it is generaly good that someone is making suggestions > outside of the current woody scope... makes us rethink some (but > not everything ;-)) > I ignore this last remark in the brackets :) you know, sometimes I'm simply blind and deaf. :) Carsten
