You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2004/05/10 01:26:27 UTC
Re: Why cleanup the template context after LoginAction ?
=?iso-8859-1?Q?Edgar_Gonz=E1lez?= <eg...@valhallaproject.com> writes:
Hi,
"Shooting down" the context object in the login/logout action, while
being clumsy is actually the right thing to do at this point because
the request tools aren't in there yet.
The Request pull tools are not put into the page context until the
page itself is loaded and its context is requested (in the
TurbineVelocityService::getContext(RunData data) method).
So this does not affect the tools themselves. If you try to manipulate
the velocity context from an action: Please don't. Tools belong to the
Velocity implementation of the TemplateService of Turbine (this means:
Page, Screen, Layout) and are not at all related to the action part of
Turbine. If you need to transfer information from an Action to a Tool,
use a model object which is stored in the Session context.
If you try accessing the Velocity Context from an Action (I wonder how
you might do this), your best bet is, that you get "stale" tools from
the last request cycle, which might be recycled back to your
screen. What you really get when your application comes under load and
the pools start to adjust by producing more objects of the tools
classes, for this, all bets are off.
You can't manipulate the Velocity Context from an Action. Yes, you
might be able to get a reference to it somehow, but trust me: It
simply does not work this way.
Actions (just as Pages, Screens and Layouts) are part of the Turbine
module concept, which is a layer below the templating solutions.
The Velocity pages are just an implementation of a Screen and/or Page
class. If you assume in your action that the resulting screen will be
a Velocity screen and you try to modify its context directly, you
basically commit a layer violation.
If you elaborate what you're trying to do, I might be able to tell you
how to do it right. :-)
So: I won't apply your patch. It just introduces an unneccesary
dependency between Turbine core and Pull Service and it won't help you
anyway because what you're trying to do does not work with the Turbine core.
Regards
Henning
>------=_NextPart_000_0000_01C423CE.3FC2E970
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>Hi,
>=20
>Why cleanup ALL the template context after LoginAction ?
>=20
>In T2.3 the Turbine servlet remove the template context from the RunData
>after execute the LoginAction.
>=20
>Reading the CVS annotations, I found that Henning said that he coded in =
>this
>way, to fix a bug related to session pull-tools. But with this code if =
>the
>LoginAction (in my case this extends VelocityAction) put some object =
>into
>the context, it isn't available in the template. The same happens with =
>the
>request pull-tools, if the LoginAction modified a request tool, this
>modification isn't available in the template, because ALL the template
>context is cleaned and then rebuilded (with a "clean" request tool).
>=20
>So, why to break all the standard functionality of
>Pull-Tools+Context+Actions+Screens in the LoginAction?=20
>=20
>Why not to just remove the session pull-tools from the context, after =
>the
>LoginAction, and not remove ALL the context?
>=20
>Any comment? Am I missing something?
>=20
>TIA
>=20
>-------------------------------------------------------------------------=
>---
>Edgar Gonz=E1lez Gonz=E1lez
>VALHALLA Project, s.a.
>Chief Technology Officer
>Web: www.valhallaproject.com
>E-mail: egg@valhallaproject.com / egg@cantv.net
>Phone: +58-212-242.4379 / 6662 / 4055 / 6475
>Fax: +58-212-242.6809
>"The limits of my language mean the limits of my world."
>Ludwig Wittgenstein
>-------------------------------------------------------------------------=
>---
>=20
>=20
>-------------------------------------------------------------------------=
>---
>Edgar Gonz=E1lez Gonz=E1lez
>VALHALLA Project, s.a.
>Chief Technology Officer
>Web: <BLOCKED::http://www.valhallaproject.com/> www.valhallaproject.com
>E-mail: <BL...@valhallaproject.com> =
>egg@valhallaproject.com /
><BL...@cantv.net> egg@cantv.net
>Phone: +58-212-242.4379 / 6662 / 4055 / 6475
>Fax: +58-212-242.6809=20
>"The limits of my language mean the limits of my world."
>Ludwig Wittgenstein=20
>-------------------------------------------------------------------------=
>---
>=20
>------=_NextPart_000_0000_01C423CE.3FC2E970--
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Au�erdem k�nnen in Deutschland alle Englisch. [...] so entf�llt die
Notwendigkeit [...] Deutsch zu lernen."
-- Johan Micoud auf die Frage warum er kein Deutsch spricht.
(http://www.spiegel.de/spiegel/0,1518,273205,00.html)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Why cleanup the template context after LoginAction ?
Posted by Edgar González <eg...@valhallaproject.com>.
Hi Henning,
Thanks for your response.
What I want to do, is implement an approach like the used by Scarab
with the the scarabR tool.
I'm use a tool like this to set (in actions and screens) and show the
messages (in templates).
In fact this approach works great in Turbine 2.2.
>"Shooting down" the context object in the login/logout action, while
>being clumsy is actually the right thing to do at this point because
>the request tools aren't in there yet.
At this point it's a request and I should be able to service it with
a VelocityAction
>The Request pull tools are not put into the page context until the
>page itself is loaded and its context is requested (in the
>TurbineVelocityService::getContext(RunData data) method).
>
>So this does not affect the tools themselves. If you try to manipulate
>the velocity context from an action: Please don't. Tools belong to the
>Velocity implementation of the TemplateService of Turbine (this means:
>Page, Screen, Layout) and are not at all related to the action part of
>Turbine. If you need to transfer information from an Action to a Tool,
>use a model object which is stored in the Session context.
If this true, where does the VelocityAction fix?
>If you try accessing the Velocity Context from an Action (I wonder how
>you might do this), your best bet is, that you get "stale" tools from
>the last request cycle, which might be recycled back to your
>screen. What you really get when your application comes under load and
>the pools start to adjust by producing more objects of the tools
>classes, for this, all bets are off.
My login/logout actions are VelocityActions, so I can get access to
the context and its objects.
Why the RequestTools are to be related with the fact that the user is
logged-on or logged-off?
I understand this consideration applies to the SessionTools, that
make sense. But not the RequestTools which "scope" is just the request.
>
>You can't manipulate the Velocity Context from an Action. Yes, you
>might be able to get a reference to it somehow, but trust me: It
>simply does not work this way.
>
>Actions (just as Pages, Screens and Layouts) are part of the Turbine
>module concept, which is a layer below the templating solutions.
>
>The Velocity pages are just an implementation of a Screen and/or Page
>class. If you assume in your action that the resulting screen will be
>a Velocity screen and you try to modify its context directly, you
>basically commit a layer violation.
>
>If you elaborate what you're trying to do, I might be able to tell you
>how to do it right. :-)
>
>So: I won't apply your patch. It just introduces an unneccesary
>dependency between Turbine core and Pull Service and it won't help you
>anyway because what you're trying to do does not work with the Turbine core.
>
> Regards
> Henning
It's true about the new dependency with the PullService, but already
exists a dependency with the VelocityService.
I have no excuse for that, but as you said in a comment in the
cleanupTemplateContext (Turbine.java):
// This is Velocity specific and shouldn't be done here.
// But this is a band aid until we get real listeners
// here.
Hope to hear from you soon
Thanks
----------------------------------------------------------------------
------
Edgar González González
VALHALLA Project, s.a.
Chief Technology Officer
Web: www.valhallaproject.com
E-mail: egg@valhallaproject.com / egg@cantv.net
Phone: +58-212-242.4379 / 6662 / 4055 / 6475
Fax: +58-212-242.6809
"The limits of my language mean the limits of my world."
Ludwig Wittgenstein
----------------------------------------------------------------------
------
>>Hi,
>
>>=20
>
>>Why cleanup ALL the template context after LoginAction ?
>
>>=20
>
>>In T2.3 the Turbine servlet remove the template context from the RunData
>>after execute the LoginAction.
>
>>=20
>
>>Reading the CVS annotations, I found that Henning said that he coded in =
>>this
>>way, to fix a bug related to session pull-tools. But with this code if =
>>the
>>LoginAction (in my case this extends VelocityAction) put some object =
>>into
>>the context, it isn't available in the template. The same happens with =
>>the
>>request pull-tools, if the LoginAction modified a request tool, this
>>modification isn't available in the template, because ALL the template
>>context is cleaned and then rebuilded (with a "clean" request tool).
>
>>=20
>
>>So, why to break all the standard functionality of
>
>>Pull-Tools+Context+Actions+Screens in the LoginAction?=20
>
>>=20
>
>>Why not to just remove the session pull-tools from the context, after =
>>the
>>LoginAction, and not remove ALL the context?
>
>>=20
>
>>Any comment? Am I missing something?
>
>>=20
>
>>TIA
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org