[Woody] observations, issues, questions, best practices

[Joerg Heinicke]

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.

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?

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.

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?

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.

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 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106814306509920&w=2, 
which does work because of missing attribute. I simply added 
@action-command="cancel", but without any usage.

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?

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.

Joerg