For those interested,

am still active in getting the WoodyGenerator up to speed with the flow (as was done with the WoodyTemplateTransformer)

here is some out-loud thinking:


[1. form/@action] we need to introducce the equivalent of this: <wt:form-template action="#{$continuation/id}.continue" ...

to allow to specify the action attribute that should be inserted on the generated form.

The way to do this is IMHO is by introducing some
<map:parameter name="form-action" value="#{$continuation/id}.continue"/>
to the woody-generator component...

some questions popping up though:
- what with other attributes we need to set on form (e.g. method and encoding for file-upload!)


- we should probably change the interface of the recent WoodyPipelineConfig: in stead of allowing access to the getJXPathContext() we should let the config itself just evaluateJXPath(String expression):Object?

[on the side: and in RT mode]
in fact: there are times when I contemplate if we shouldn't allow flow/jxpath to infect the cocoon core a bit more. SourceResolver around allows to resolve access to any (XML) file based on a URI-like string...


jxpath inside cocoon is rapidly fulfilling the same role for resolving lookup-expressions into the object-cloud surrounding a request. Maybe we should institutionalize this by introducing a common used ObjectResolver?


[2. woody xslt reuse]
I (currently) think the current default woody-stylesheet with some minor additions could be fully reused as a way to style the output of the generator as well...


haven't started yet on this but any suggestions, objections, recommendations concerning this are welcome.


wdyt? regards, -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]




Reply via email to