cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Prefill form with Woody and XML without binding?
Date Wed, 12 May 2004 19:21:07 GMT
On 12.05.2004 21:03, Christian Rosenberger wrote:

>> <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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message