They are classes written that implement the ApplicationTool interface and are placed in the template context automatically by Turbine. Look under "PULL SERVICE" in TR.props. This lists all of the tools that Turbine will provide your templates.
"What is an ApplicationTool?" is a hard question to answer, basically, it can do about anything you want or need it to do. Here are some tools you probably have used in your templates but may not have even recognized $content $link $page $ui if you have used any of these in your templates, you've used an ApplicationTool. To make your own, just look at the source for some of these. Once you see how simple writing a "pull" tool is, you won't want to code your application any other way!!! Scott -----Original Message----- From: Paul Pattison [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 5:39 PM To: Turbine Users List Subject: RE: turbine "best practice" for handling forms What exactly is an ApplicationTool? Is this part of Turbine? Are there any docs on it? Paul -----Original Message----- From: Jonathan Carlson [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 5:34 PM To: Turbine Users List Subject: Re: turbine "best practice" for handling forms Why is using the HttpSession object better than writing a session-scoped ApplicationTool (i.e. pull tool)? Jonathan Carlson [EMAIL PROTECTED] Weaver, Scott wrote: >By all means! > >Scott > >-----Original Message----- >From: Jeff Linwood [mailto:[EMAIL PROTECTED]] >Sent: Monday, December 03, 2001 1:53 PM >To: Turbine Users List >Subject: Re: turbine "best practice" for handling forms > > >Do you mind if I include this in a best practices doc? > >jeff >----- Original Message ----- >From: "Weaver, Scott" <[EMAIL PROTECTED]> >To: "'Turbine Users List'" <[EMAIL PROTECTED]> >Sent: Monday, December 03, 2001 12:14 PM >Subject: RE: turbine "best practice" for handling forms > > >>data.getSession() returns the javax.servlet.http.HttpSession object. Use >>HttpSessions getAttribute() and setAttribute() to get and set persistant >>values across multiple requests. Alternatively, You can also store things >>in the User.setTemp() and USer.getTemp(). I prefer session objects >> >opposed > >>to hidden form values both from an ease-of-use and a security stand-point. >> >>Scott >> >>-----Original Message----- >>From: Nathaniel Reed [mailto:[EMAIL PROTECTED]] >>Sent: Monday, December 03, 2001 1:02 PM >>To: [EMAIL PROTECTED] >>Subject: turbine "best practice" for handling forms >> >> >>There are a series of screens in my application that are used to >>complete a task. This is fairly typical: the data from the first screen >>is parsed & stored, used by the second form, and the third step is to >>perform an action using the input from the first 2 screens. >> >>How should the data be persisted after the first screen parses the form >>parameters? Is there a session object? Is the RunData instance >>persisted for more than a single HTTP request? >> >>Right now the second screen parses the form parameters and the template >>generates another form with those values from the first screen as >>"hidden" form parameters.. >> >>In my other web development work I usually persist form parameters in >>the session because it's the easiest thing to do... Is this "kosher?" >> >>Thanks >>-- >>Nate Reed >>Physical Oceanography Distributed Active Archive Center >>Jet Propulsion Laboratory (Raytheon) >>[EMAIL PROTECTED] >>(626) 744-5528 >>(626) 744-5506 >> >> >> >>-- >>To unsubscribe, e-mail: >><mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: >><mailto:[EMAIL PROTECTED]> >> >>-- >>To unsubscribe, e-mail: >> ><mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: >> ><mailto:[EMAIL PROTECTED]> > >> > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
