cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [Woody] observations, issues, questions, best practices
Date Thu, 15 Jan 2004 10:52:28 GMT

Joerg Heinicke wrote:

> Hello,
> at work I may convert a Struts application into a Woody one. I played 
> around with the Woody samples and created a form handling prototype for 
> my application. But I came across some problems and made some 
> observations I want to point out here. On the other hand the 
> architecture is not "fixed", especially the communication with the 
> backend, so the handling of the business logic is not that perfect.
> 1. When the template contains a reference to a not defined widget, I get 
> an exception: "EffectWoodyTemplateTransformer: Widget with id 
> "addcontact" does not exist in the container."
> What would be helpful in this error message is the mentioning of the 
> file and the line number.

It would, but:
Most woody definition files are read into a DOM which is completed with 
location info, and thus have such info available.

Woody template files are the odd exception since they are not read in as 
DOM, but fed into the transformer throught the SAX-events in the Cocoon 
pipeline.  The info is available of course through the 'locator' in SAX, 
but might not be that usefull since the previous component in the 
pipeline might be more complicated then the straightforward 
FileGenerator (think XSLT or JX), no?

I have not actually invested in the transformer yet, but I would expect 
above to be the main reason/dificulty.

> 2. When a flow script function is not available (called via woody2.js, 
> line 213) I only get a "CascadingRuntimeException: The undefined value 
> has no properties." Isn't it possible to give a more exact explanation 
> or at least to point to the expression that returns undefined?

I'm not your self-declared js expert, but maybe this could help:

you could try out extending the logic with some test for != undefined 
before doing the call to apply() (which is now inline)

based on the test you can consider throwing a more sensible exception 
with explanation and actual reference to the "function" you were looking for


> 3. JXTemplateGenerator: Here I mixed ${} and #{} and / and , so I got a 
> double coercion exception - what ever that means. I found it out because 
> I did only little steps.

no idea

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

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

I would prefer your generator, lemme know when it's done :-)

> 6. Next thing is about what we called table view in our LoFEx project. 
> It's closely related to the repeater we already have and I like very 
> much. The feature I didn't see at first sight is the native support for 
> switching between parts of a result set (e.g. rows 1 - 10, rows 11 - 20, 
> and so on). Something like first-page, next-page, last-page, 
> previous-page actions are missing.


> 7. A short question: When to use wd:submit in the definition file and 
> when a simple <input type="submit"/> in the template?
> 8. Why a wd:submit needs an @action-command? I tried the solution at 
> which does work because of missing attribute. I simply added 
> @action-command="cancel", but without any usage.

sorry, no idea on wd:submit, hopefully others can complete

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

> 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?
> So, I would like to hear you comments, proposals or what ever you like.

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 

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

just my 2c
Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message