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 =
Packages.org.stjude.ct.ui.logon.LogonHandler.handle( 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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
