cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject [cforms] still reviving the generator
Date Tue, 23 Dec 2003 13:21:57 GMT
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.

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

View raw message