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
wdyt?
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.
yes.
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.
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 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?)
just my 2c -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
