You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Hunsberger, Peter" <Pe...@stjude.org> on 2003/12/24 17:48:30 UTC
Hiding business logic in flow: how to get at naked request?
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?
Peter Hunsberger
Re: Hiding business logic in flow: how to get at naked request?
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> 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
>
> One way to make this easier would be to make
> FOM_Request/Response/Session/Context implement the
> Request/Response/Session/Context interfaces. These interfaces would
> not be accessible in JS code but would be in Java code.
Great idea! This will greatly ease the communication between flowscript
and Java classes.
> The only drawback is for code that attempts to downcast e.g. Request
> to HttpRequest which would not work. Since HttpRequest is a class, not
> an interface, it cannot be implemented by FOM_Request. Given that is
> the case, such downcasting is probably a Bad Thing (TM) anyway.
Agree.
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
Re: Hiding business logic in flow: how to get at naked request?
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> 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
>
One way to make this easier would be to make
FOM_Request/Response/Session/Context implement the
Request/Response/Session/Context interfaces. These interfaces would not
be accessible in JS code but would be in Java code. The only drawback is
for code that attempts to downcast e.g. Request to HttpRequest which
would not work. Since HttpRequest is a class, not an interface, it
cannot be implemented by FOM_Request. Given that is the case, such
downcasting is probably a Bad Thing (TM) anyway.
Re: Hiding business logic in flow: how to get at naked request?
Posted by Sylvain Wallez <sy...@apache.org>.
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 =
>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