<map:match pattern="form"> <!-- pass the control to flowscript --> <map:call function="form"/> </map:match>
Here is the binding framework missing, I think. Is your solution without using the binding framework? How is the binding form vars <=> input xml doc done?
It's just shortened to the necessary :) Yes, the standard function needs some parameters.
The binding example uses parameters.
<map:call function="woody">
<map:parameter name="function" value="form2xml"/>
<map:parameter name="form-definition" value="forms/wd_movie.xml"/>
<map:parameter name="documentURI" value="http://localhost/cineportal/movieinfo.xml"/>-->
<map:parameter name="bindingURI" value="forms/wb_movie.xml"/>
</map:call>
<map:match pattern="shwoForm"> <!-- show the form to the user --> <map:generate src="formTemplate.xml"/> <map:transform type="woody"/> <map:transform type="woody-samples-styling.xsl"/> <map:trasnform type="i18n"/> <map:serialize type="html"/> </map:match>
That is nearly the same.
<map:match pattern="getData"> <!-- flowscript calls this pipeline to get the data --> <map:generate type="yourGenerator"/> <map:serialize type="xml"/> </map:match>
Done this, too.
<map:match pattern="showResult"> <!-- after finishing you maybe want to present a result, below is just an example --> <map:generate type="xsp" src="result.xsp"/> <map:transform src="result2html.xsl"/> <map:serialize type="html"/> </map:match>
Don't wanna use xsp. Is there a alternative in this case? I use usually JXTemplate Generator.
No problem, was really just an example.
function form() { initializeForm(); //pseudo code
What do you mean with this?
there is some init code in the samples. the above is again the shortened form.
//call pipeline to get the data var doc = cocoon.processPipelineToDOM("getData");
Ok, that sounds good.
//bind the data to the form form.load(doc);
See above. How is binding done??
//show the user the form form.showForm("showForm"); //save the data back to the XML form.save(doc); //get the object that will pass the data back to db or what ever
var component = cocoon.createObject("your.component.FormerlyKnownAsTransformer"); component.store(doc); //pseudo code
This is not as easy. Because my transformer has configuration files and so on.
What does "configuration files" mean? The component I think about is just the same like the transformer, but only misses the implementation of the transformer interface. So I see no problem to extract the "connect to backend" logic from your transformer. Both the generator and the transformer use this component then.
Pass some of this configuration to my backend processes. (it's not just one class)
From what I see you only need to separate the "connect to backend" logic from the cocoon specific interfaces generator and transformer. It allows higher reuse as you can access it directly from flow, no need to go through a superflouos pipeline.
cocoon.release(component); //at the end show a result cocoon.sendPage("showResult"); }
I hope this code is understandable.
Yes, it is!
I kicked your transformer and made a pure component out of it. A transformer > should in theory only transform documents and not interact with a backend.
What about a SQLTransformer? ;-)
I don't like it for exactly that reason. And would not use it.
Also calling a pipeline that controls the storage sounds not that preferable. In the above the flowscript controller has the control. I would maybe also abstain from the generator and call the same component. If you need the generator and the transformer in other cases, you could also call that component. That's better reuse I think.
WDYT?
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
