cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: Hiding business logic in flow: how to get at naked request?
Date Fri, 26 Dec 2003 15:10:02 GMT
Sylvain Wallez <sylvain@apache.org> writes:
> 
> 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.

I got my code working within moments of getting in this morning: pages
had Logon as the name, the controller had "Login" (ancient code, sigh),
amazing what happens when you're not rushing about trying to get home
for Christmas....  So, currently passing the "cocoon" object from the
flow to the business logic classes works fine and seems to make sense.
"cocoon" has just about everything you'd ever need, including
getRequest() so we've already got some of this.

> 
> > 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.
> 
> 


Mime
View raw message