Sylvain Wallez <[EMAIL PROTECTED]> writes: <snip/>
> > > >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). Uggg.... > > Now I agree with you that having a restricted object model in > the flow > is too much constraining. > Just tried the following: pass the cocoon object straight to my class from the flow and tell my code to expect a FOM_Cocoon. It can then run the getRequest() method directly. It didn't work, I believe it can't find the method in my class for some reason? Does the cocoon object get recast on the way to my class?
