Re: expected behaviour: global vars in flowscript
Seon Lee wrote:
Hey gang,
I'd like your input on some anomalous behaviour I am experiencing in
my 2.1.7 flowscript.
I have a function defined in javascript that expects a global var to
be available at the point in time it is invoked. However, this is not
the case -- the function is unable to see the recently initialized
global variable. The main entry point in my example is the URI
login. The area where the error occurs is in accessFoo().
Normal login processing occurs in my flowscript...
var _component = new AnAvalonComponent();
var _globalFoo;
var _initFlag;
function login()
{
if (_globalFoo == undefined) initSession();
else _globalFoo.reset();
cocoon.sendPage(pages/displayHome.xsp);
}
function initSession()
{
if (_globalFoo == undefined)
{
_globalFoo= new FooObject();
var session = cocoon.session;
}
}
function accessFoo()
{
var bean = _component.getBean(_globalFoo);
cocoon.sendPage(pages/displayBean.xsp, {bean :bean});
}
Here is my sitemap...
map:pipelines
map:pipeline internal-only=true
map:match pattern=pages/displayHome.xsp
map:aggregate element=page
map:part src=cocoon:/header.xsp/
map:part src=cocoon:/do.accessFoo/
map:part src=cocoon:/footer.xsp/
/map:aggregate
/map:match
map:match pattern=do.accessFoo
map:call function=accessFoo/
/map:match
map:match pattern=pages/displayBean.xsp
map:generate src=bean.jx type=jx/
map:serialize type=xml/
/map:match
/map:pipelines
map:pipelines
map:match pattern=pages/login.xsp
map:call function=login/
/map:match
/map:pipelines
The problem occurs when accessFoo() attempts to retrieve the recently
initialized _globalFoo object. The value of _globalFoo in that method
is undefined, even though the initSession() was invoked prior in the
pipeline before reaching accessFoo() -- eg. pages/displayBean.xsp
complains that the bean is undefined.
Can anyone shed some light into why this is happening? I have a
feeling I know what might be causing the problem but I'm looking for
input from more experienced cocoon developers.
Is there an alternative or best-practice recommendation as far as
initializing and accessing global vars in the flowscript (perhaps a
continuation object, or strictly passing objects in the pipeline, or
using the cocoon.session to pass the references)?
If you are trying to apply MVC here you're failing. You should not be
calling pages/displayHome.xsp but some displayHome flowscript function.
The flowscript function prepares the bean and does cocoon.sendPage(
pages/displayHome ) which is matched to:
map:match pattern=pages/displayHome.xsp
map:aggregate element=page
map:part src=cocoon:/header.xsp/
map:part src=cocoon:/pages/showFoo/
map:part src=cocoon:/footer.xsp/
/map:aggregate
/map:match
map:match pattern=pages/showFoo
map:generate src=bean.jx type=jx/
map:serialize type=xml/
/map:match
It means:
1. you invoke the controller
2. the controller performs business logic and prepares data for view
3. with cocoon.sendPage you call your view
In your case it is all pretty mixed up.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: expected behaviour: global vars in flowscript
Leszek Gawron wrote: If you are trying to apply MVC here you're failing. You should not be calling pages/displayHome.xsp but some displayHome flowscript function. The flowscript function prepares the bean and does cocoon.sendPage( pages/displayHome ) which is matched to: map:match pattern=pages/displayHome.xsp map:aggregate element=page map:part src=cocoon:/header.xsp/ map:part src=cocoon:/pages/showFoo/ map:part src=cocoon:/footer.xsp/ /map:aggregate /map:match map:match pattern=pages/showFoo map:generate src=bean.jx type=jx/ map:serialize type=xml/ /map:match It means: 1. you invoke the controller 2. the controller performs business logic and prepares data for view 3. with cocoon.sendPage you call your view In your case it is all pretty mixed up. So how would you fix it, assuming we wanted to aggregate different pieces into one page? Those peaces are used elsewhere in the program. Your comments weren't particularly helpful to either point to the specifics of how to expect flowscript to work or how to correct the code as it is. Seon's on my team, so I have a vested interest in getting this issue resolved. -- Design is a funny word. Some people think design means how it looks. But of course, if you dig deeper, it's really how it works. -- Steve Jobs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: expected behaviour: global vars in flowscript
Berin Loritsch wrote:
Leszek Gawron wrote:
If you are trying to apply MVC here you're failing. You should not be
calling pages/displayHome.xsp but some displayHome flowscript function.
The flowscript function prepares the bean and does cocoon.sendPage(
pages/displayHome ) which is matched to:
map:match pattern=pages/displayHome.xsp
map:aggregate element=page
map:part src=cocoon:/header.xsp/
map:part src=cocoon:/pages/showFoo/
map:part src=cocoon:/footer.xsp/
/map:aggregate
/map:match
map:match pattern=pages/showFoo
map:generate src=bean.jx type=jx/
map:serialize type=xml/
/map:match
It means:
1. you invoke the controller
2. the controller performs business logic and prepares data for view
3. with cocoon.sendPage you call your view
In your case it is all pretty mixed up.
So how would you fix it, assuming we wanted to aggregate different
pieces into one page? Those peaces are used elsewhere in the program.
Your comments weren't particularly helpful to either point to the
specifics of how to expect flowscript to work or how to correct the code
as it is.
Seon's on my team, so I have a vested interest in getting this issue
resolved.
let me see:
function login() {
setupMyFoo();
home();
}
function home() {
var foo = accessTheFoo();
cocoon.sendPage( displayHome, { bean: foo } );
}
and now the sitemap:
map:match pattern=displayHome
map:aggregate element=page
map:part src=cocoon:/header.xsp/
map:part src=cocoon:/showBean/
map:part src=cocoon:/footer.xsp/
/map:aggregate
/map:match
map:match pattern=showBean
map:generate src=bean.jx type=jx/
map:serialize type=xml/
/map:match
map:match pattern=login
map:call function=login/
/map:match
map:match pattern=home
map:call function=home/
/map:match
Sorry if I sounded rude at first.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: expected behaviour: global vars in flowscript
Leszek Gawron wrote:
Berin Loritsch wrote:
Leszek Gawron wrote:
If you are trying to apply MVC here you're failing. You should not be
calling pages/displayHome.xsp but some displayHome flowscript function.
The flowscript function prepares the bean and does cocoon.sendPage(
pages/displayHome ) which is matched to:
map:match pattern=pages/displayHome.xsp
map:aggregate element=page
map:part src=cocoon:/header.xsp/
map:part src=cocoon:/pages/showFoo/
map:part src=cocoon:/footer.xsp/
/map:aggregate
/map:match
map:match pattern=pages/showFoo
map:generate src=bean.jx type=jx/
map:serialize type=xml/
/map:match
It means:
1. you invoke the controller
2. the controller performs business logic and prepares data for view
3. with cocoon.sendPage you call your view
In your case it is all pretty mixed up.
So how would you fix it, assuming we wanted to aggregate different
pieces into one page? Those peaces are used elsewhere in the
program. Your comments weren't particularly helpful to either point
to the specifics of how to expect flowscript to work or how to correct
the code as it is.
Seon's on my team, so I have a vested interest in getting this issue
resolved.
let me see:
function login() {
setupMyFoo();
home();
}
function home() {
var foo = accessTheFoo();
cocoon.sendPage( displayHome, { bean: foo } );
}
and now the sitemap:
map:match pattern=displayHome
map:aggregate element=page
map:part src=cocoon:/header.xsp/
map:part src=cocoon:/showBean/
map:part src=cocoon:/footer.xsp/
/map:aggregate
/map:match
map:match pattern=showBean
map:generate src=bean.jx type=jx/
map:serialize type=xml/
/map:match
map:match pattern=login
map:call function=login/
/map:match
map:match pattern=home
map:call function=home/
/map:match
Sorry if I sounded rude at first.
If you need it you can make your flowscript call login only when needed:
function main() {
cocoon.response.setHeader( Expires, -1 );
cocoon.response.setHeader( Cache-Control, no-cache );
cocoon.response.setHeader( Pragma, no-cache );
var action = cocoon.parameters[action];
if ( springContext == null )
setupSpringContext();
if ( cocoon.session.user == null ) {
loginInternal();
}
invoke( action );
}
function invoke( action ) {
var func = this[ action ];
if ( func != undefined )
func.apply( this );
else
cocoon.sendPage( action, {} );
}
the sitemap:
map:match pattern=*.do
map:match type=request-parameter pattern=continuation-id
map:call resource=resume-continuation
map:parameter name=continuation-id
value={1}/
/map:call
/map:match
map:call function=main
map:parameter name=action value={1}/
/map:call
/map:match
this way you can just call
http://localhost:/home.do
and the main function will be called which will detect if user is
logged in. If not login screen is shown first and later the home()
function is being run (with func.apply() ).
It's a poor's man intercepted flow.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
