4. The switching of binding to XML or beans costs to much effort. Binding file, JXTemplate (for the result), flow script. Maybe I did something the wrong way, but the XML needs at least a root element, why this would be annoying for the bean. Some ideas for that?
hm, both are supported, but that doesn't necesarrily mean that swapping between both is that easy.
I encountered the same when doing the first of my binding-samples... I ended up switching easily by not passing the DOM directly into the binding, but rather the root-node. Note: when binding to XML you need to pass in a DOM Node, not a DOM Document!
Sometimes it's soo simple. But could it be that it is a one-way ticket? Saving the "document" back does not work, because document is null.
5. Closely related the next question: The bizData passed from sendPage() is it simply an object? What are the constraints? I know it's accessed in the Woody samples in the success pages via JXTemplateGenerator. The reason i ask is the need of a JXTemplate for every type of these success pages. I don't like that, but would like much more a generic generator that converts bizData into SAX events.
yep, again an issue I had as well: you can see in the recent binding-samples how I hacked myself into having a somewhat generic jxtemplate for both XML and Beans in the bizdata.
Good to know that you went the same way ...
I would prefer your generator, lemme know when it's done :-)
I will see how often I need this generator. At latest after the third JXTemplate I will write the generator :)
9. Now I come to the unsure part of my prototype. The architecture I imagine at the moment is really Struts-like. I bind the values of the form to a bean and call an Action with the bean as parameter. This will cause much typing - the more granular the better, but the more typing. It's more a question for best practices. How do you meet such requirements?
'fraid I don't really understand. do you really mean a Cocoon Action? could you elaborate on your setup?
No, a Struts-like Action like at http://it.cappuccinonet.com/strutscx/grafics/struts_architecture_big.gif. The architecture will also be similar to this picture only with Controller replaced with flow script and of course a different view. You will probably recommend to use Avalon components, but this "architecture" was a compromise to the second developer, who has no Cocoon but only a Struts background.
10. And a last question: validating the form in application context (e.g. simple case "login already exists"). Last week there was a discussion about it. Are there any restrictions or constraints about it or is it just an arbitrary method call that returns true or false?
An important part of the issue is missing. The last sentence/question refers to form.validator.
I haven't got into all depths of the validation discussions. I have to admit to me these kinds of examples should not be handled by the form internally...
IMHO we should avoid to let the form become a complete application template: woody should remain something that is just usable in a number of contexts, it should not grow to be it's own context to which you'r application modelling needs to bend itself to. (Compare to 4GL environments vs reusable libraries?)
I see your point. But I don't know a better solution than a hook like form.validator at the moment.
Today I found another issue, so:
11. wd:action and wd:submit have a child wd:on-action while wd:repeater-action and wd:row-action have a child wd:on-activate. Isn't it somewhat inconsistent?
Thanks for your comments, Marc. Where are all the others having already played with Woody?
Joerg
