Hmm...that could certainly be an obstacle. With just a few minutes looking into the code, it looks like the basic TemplateNavigation.doBuildTemplate(RunData data) is called (start tracing the call stack at o.a.t.util.template.TemplateNavigation.toString()), which eventually uses TurbineVelocity.getContext(data) to get a generic context. The screen class will call the same method, but unfortunately the two returned context objects will not be the same.
We might consider making this an issue in Scarab -- it would be great for navigations and screens to share a single populated context. As a workaround, you could use a combination of pull tools and navigations -- navigations to avoid #parse() and a pull tool to share data among navigations and screens. Good luck, Chris > -----Original Message----- > From: Bruce Altner [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 27, 2003 8:06 AM > To: [EMAIL PROTECTED] > Cc: dave Godbey; nathan Shaw > Subject: Fwd: RE: how to use template/screen class pairing in a parse > situation? > > > An interesting suggestion so I tried it. Unfortunately, the navigation > context and the screen context appear to be different objects > because what > I put into the context in the VelocityNavigation class was > available to my > navigation template, but it was not available to the screen templates > (neither the master template, Index.vm, nor the parsed templates included > within Index.vm). Therefore, this does not meet the need I described, > unless I can get the navigation and screen templates to talk to > each other. > > Thanks, > Bruce > > > >>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > >>List-Unsubscribe: <mailto:[EMAIL PROTECTED]> > >>List-Subscribe: <mailto:[EMAIL PROTECTED]> > >>List-Help: <mailto:[EMAIL PROTECTED]> > >>List-Post: <mailto:[EMAIL PROTECTED]> > >>List-Id: "Turbine Users List" <turbine-user.jakarta.apache.org> > >>Reply-To: "Turbine Users List" <[EMAIL PROTECTED]> > >>Delivered-To: mailing list [EMAIL PROTECTED] > >>From: "Chris K Chew" <[EMAIL PROTECTED]> > >>To: "Turbine Users List" <[EMAIL PROTECTED]> > >>Subject: RE: how to use template/screen class pairing in a > parse situation? > >>Date: Wed, 26 Feb 2003 14:25:56 -0700 > >>X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) > >>Importance: Normal > >>X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > >> > >>I am not positive, but you might also find navigation templates > & classes > >>helpful. They are pretty analogous to calling #parse, in that > you can call > >>them dynamically from a screen template. The advantage over > #parse is that > >>you can create a com.mycompany.modules.navigations package with > navigation > >>classes paired by name that work exactly like screen classes. > >>$navigation.setTemplate() in your screen template will call > navigation class > >>to fill the context before the template is parsed and the > output generated, > >>whereas the #parse command will do nothing with the screen/navigation > >>classes. > >> > >>Additionally, I find it kind of difficult to intelligently > handle exceptions > >>thrown in pull tools, because Turbine is past the action/screen > execution > >>and already into output generation. This brings the > application over to the > >>push side, which some people consider to be bad, but I find that a push > >>model is more easily tested with better fault-tolerance. > >> > >>I should put a disclaimer that I haven't ever used navigation > classes, but > >>just figured this out a few days ago. I could have removed > quite a bit of > >>logic from my templates in previous projects had I known better. > >> > >>Good luck, > >> > >>Chris > >> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
