cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Hiding business logic in flow: how to get at naked request?
Date Wed, 24 Dec 2003 17:21:31 GMT
Hunsberger, Peter wrote:

>As per my previous message we're converting existing code to use Cocoon
>flow.  We've got a bunch of action handlers that can be converted to
>encapsulate some business logic pretty straight forwardly.  However, I'd
>like to hide most of the complexity of dealing with the business logic
>from the flow layer, and just have the actual flow script hand off
>decision making to these classes without having to be aware of any of
>the details of the contract between the business logic classes and the
>front end.  
>In particular, in our case the front end is dynamically generated from
>metadata and the business handlers also have access to the metadata to
>understand the complete context of any request from the front end.
>There seems no reason to recreate any of this metadata handling in the
>flow layer, I'd like it to work as a simple presentation controller
>without exposing the particulars of the various requests to it.  
>This at first seemed straight forward enough but I've run into one snag.
>In our flow script I've got code like the following (it's actually more
>generic, but this example makes things a little more concrete for
>discussion purposes):
>	function logon(  )           
>	{
>	    var logonOk = false;
>	    while ( !logonOk )
>	    {
>	        cocoon.sendPageAndWait( "page/logon/" );
>	        logonOk =
> cocoon.request );
>	    }
>	    cocoon.sendPage( "page/main.frameset" );
>	}
>The problem is that cocoon.request is a FOM_Request which is an inner
>class of FOM_Cocoon. I've followed the discussion on what to expose to
>the flow layer, but in this case I think the model is too conservative.
>I believe we need a way to get at the real Cocoon Request, making the
>inner class public ally available wouldn't really help since you'd still
>need to unwrap it in the end...??
>Am I missing something?  Is there another way to get some generic
>request level objects out of the flow and to our business logic classes?

There is a way. Not that straightforward, though.

You should use the new cocoon.createObject(classname) method that 
instanciates an object and goes through the various lifecycle 
interfaces. Your class has to be Contextualizable, and you can then get 
the request from the context using ContextHelper.getRequest(context).

Now I agree with you that having a restricted object model in the flow 
is too much constraining.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message