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: [EMAIL PROTECTED] / [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
