cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Velychko <v_pe...@ukr.net>
Subject Re: cocoon and hibernate sessions
Date Thu, 01 Jul 2004 13:30:43 GMT
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                            
v_peter@ukr.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message