Hello Upayavira,
Thank you for your reply.
> That could work, but it would be working round, rather than working
> with, Cocoon. You would also be buffering your output, which is best
> avoided.
Yes, this is workaround. But why whole DOM tree caching is so bad idea?
> This is an issue that requires a full solution. I believe the preferred
> way is something like:
> cocoon.sendPageAndWait("url", bizData, function(){session.close()});
> But I think there are some issues with this approach, and I believe it
> doesn't work with cocoon.sendPage.
Thank you. I will try to use
cocoon.sendPageAndWait("url", bizData, function(){session.close()})
for my projects.
> Fancy doing some digging into Cocoon's internals?
I'm trying now to understand cocoon more deeper.
But also sometimes crazy ideas visit my head.
> Regards, Upayavira
> Peter Velychko wrote:
>>Hello Upayavira,
>>
>>May be it is off topic.
>>There was discussion on using lazy loading with Hibernate.
>>Just a wild idea about it.
>>In flowscript we have possibility to get OutputStream or even DOM
>>tree to variable. And we can use the resulting DOM tree to generate
>>response.
>>(I'm not clear in my mind how can I use OutputStream in this way.)
>>
>>function doSomething() {
>> var doc;
>>
>> if (doc == undefined || doc == null) {
>> doc = generateContent();
>> }
>>
>> // responsing
>> cocoon.sendPage("response-pipeline", {doc: doc});
>>}
>>
>>function generateContent() {
>> // initialization
>> var factory = cocoon.getComponent(factoryURI);
>> var session = factory.openSession();
>> var someThing = doSomeDataWithSession(session);
>> var viewData = {someThing: someThing};
>>
>> // generating content
>> var pipelineUtil =
>>
>> cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil);
>> var doc =
>> pipelineUtil.processToDOM("generate-content-pipeline", viewData);
>>
>> // releasing resources
>> session.close();
>> cocoon.releaseComponent(factory);
>>
>> return doc;
>>}
>>
>>So to realize this approach needs 3 sets of pipelines:
>>1. Set for invoking flowscript function
>> <map:match pattern="">
>> <map:call function="doSomething"/>
>> </map:match>
>>
>>2. Set for generating content (DOM)
>> <map:match pattern="generate-content-pipeline">
>> <map:generate type="jx" src="screens/generate.jx">
>> <map:parameter name="lenient-xpath" value="true"/>
>> </map:generate>
>> <map:transform type="i18n"/>
>> <map:serialize type="xml"/>
>> </map:match>
>>
>>3. Set for response
>> <map:match pattern="response-pipeline">
>> <map:generate type="jx" src="screens/response.jx"/>
>> <map:serialize type="html"/>
>> </map:match>
>>
>>I think it would be more advantageous to operate with OutputStream but
>>I don't know how it is possible to respond it from flowscript.
>>
>>
>>
>>>Stephan Coboos wrote:
>>>
>>>
>>
>>
>>
>>>>Upayavira wrote:
>>>>
>>>>
>>>>
>>>>>><map:match pattern="foo.jxt">
>>>>>> <map:generate type="jxt" src="foo.jxt"/>
>>>>>> <map:act type="closeHibernateSession"/>
>>>>>> <map:serialize type="html"/>
>>>>>></map:match>
>>>>>>
>>>>>>
>>>>>>
>>>>>This will not work.
>>>>>
>>>>>Actions are used when building a pipeline, not when processing it. So
>>>>>the action will take place before the view is processed, not after.
>>>>>
>>>>>
>>>>
>>>>Oh, what a pitty. It's a little bit consfusing me why action is
>>>>executed before processing the pipeline, but OK it is so. I think of
>>>>process switch within the pipline?
>>>>
>>>>
>>
>>
>>
>>>Actually, when understood, it makes complete sense.
>>>
>>>
>>
>>
>>
>>>So, to explain:
>>>
>>>
>>
>>
>>
>>>Any pipeline when built, goes generator->transformer...->serializer. And
>>>that is it. Anything else, such as matchers, selectors and actions, that
>>>influence the pipeline, are used when building the pipeline, not when
>>>using it. So imagine a process that goes:
>>>1) Which generator? Which transformers? Which serialiser
>>>2) Okay, I've worked out my pipeline, so: generator, go generate
>>>
>>>
>>
>>
>>
>>>And the generator then starts up, passing SAX events down the pipeline
>>>until the serialiser has consumed all resulting events and something has
>>>been returned to the user.
>>>Thus, actions are used when _building_ pipelines, not when _executing_ them.
>>>Hope that makes sense.
>>>Upayavira
--
Best regards,
Peter Velychko
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
