cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [Woody] observations, issues, questions, best practices
Date Thu, 15 Jan 2004 20:32:04 GMT
On 15.01.2004 11:52, Marc Portier wrote:

>> 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 
  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?


View raw message