> do you do that kind of logic in the .vm file, or in some sort
> of specialized
> pull tool?
I always use pull tools that interface with manager services:
Example:
public class ProductService
{
public List getProducts()
{
//query logic goes here Torque, OJB, raw SQL, etc.
}
}
//A request pull tool pretty much just a facade to ProductService
public class ProductTool implements ApplicationTool
{
public List getProducts()
{
// getService() should return an instance of the ProductService
return getService().getProducts();
}
}
Access it in your .vm (ProductTool is defined as product in TR.props)
#set($p_list = $product.Products)
#foreach($aProduct in $p_list)
<!-- do some html stuf here -->
#end
Benefits:
- Changes in logic, API, etc. only affects the ProductService. Everything
that interacts with the ProductService need not be aware of the change.
- By centrallizing all query requests through a service, you can use JCS or
some other caching mechanism speed up your application by avoiding
unneccassry db look-ups (fits very well into you drop downs scenario).
- Using this pattern, my current system seamlessly integrates with multiple
databases simultaneously(DB2/400 on remote AS400 and MySQL local on the app
server). (Uses Torque AND ObjectBridge(OJB)).
A suggestion:
My rule of thumb is that if your queries require criteria like PK's or
filtering, is that you have the request pull tool extract that information
directly from query/form/path info instead of the requiring the web designer
to pass them as parameters to your tool methods. That way if you need to
add new criteria, all you have to do is have your pull tool look for those
specific values in the query/form/path info instead of having to create new
method signatures to fit each indvidual set of criteria.
hth,
Scott
> -----Original Message-----
> From: Eric Pugh [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 07, 2002 12:24 PM
> To: 'Turbine Users List'
> Subject: RE: Semi-Newbie. Is newapp push or pull?
>
>
> Also,
>
> I am curious about more complex queries... I have a page
> which lists out
> lots of data, including data in drop downs.. I am doing the
> queies against
> the database for that data in my screen classes, on the
> theory that I need
> that data on every screen, as is part of the ui..
>
> do you do that kind of logic in the .vm file, or in some sort
> of specialized
> pull tool?
>
> Eric
>
> -----Original Message-----
> From: Skip Walker [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 07, 2002 12:06 PM
> To: 'Turbine Users List'
> Subject: RE: Semi-Newbie. Is newapp push or pull?
>
>
>
> What does your Default.class look like?
>
> Well, more specifically, how do you get the authorization tool for the
> current user so you can check their permissions against your Security
> Service?
>
> Thanks,
>
> Skip
>
> > -----Original Message-----
> > From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, May 07, 2002 10:57 AM
> > To: 'Turbine Users List'
> > Subject: RE: Semi-Newbie. Is newapp push or pull?
> >
> >
> > IMOHO, pull is the way to go. You get an immense amount of
> > re-usability and
> > flexibility by using a pull model.
> >
> > Example, if some decides that they want to re-design the
> > entire look, feel
> > and flow an application. As the web engineer, there is very
> > little you will
> > have to do accomplish this since your logic (pull tools) is
> > de-coupled from
> > the view (templates).
> >
> > My "One screen to bind them all" example.
> >
> > My application has just one screen class that acts as a
> > secure, single point
> > of entry for security and authorization. Since it is the
> only screen
> > class, it is named "Default.class" and resides at the top
> of my module
> > hierarchy for screens which means it is called for every
> > template. This
> > screen class extracts the name of the template to be
> > processed and passes it
> > to a session pull tool that is assigned to each user as they
> > log in. The
> > session pull tool communicates with a security service that
> > uses an xml file
> > to tie security requirements (groups, roles and permissions)
> > to a template
> > (I also use it for actions, action events and component
> > authorization).
> > Once the requirements for that template have been extracted,
> > the pull tool
> > compares this to the user's ACL. If security is satisfied
> > the pull returns
> > true and the screen class allows the presentation of the template if
> > security is not satisfied the pull tool returns false and the
> > screen class
> > redirects to an authorization failure page.
> >
> > This makes changing security requirements for a template a
> > snap. All a web
> > designer has to do is go into xml file that defines security
> > and add what
> > the requirements are for that template. Not one single line
> > of code has to
> > written. What is even nicer is that I can easily take the
> > security pull
> > tool and use it directly within a template or use it from
> > within an action.
> >
> > This is just one example of the advantage of using pull
> tools with the
> > fulcrum service framework opposed to locking your code within
> > individual
> > screen classes (push model).
> >
> >
> > hth,
> > Scott
> >
> > > -----Original Message-----
> > > From: Mark Nutter [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, May 06, 2002 7:45 PM
> > > To: Turbine Users List
> > > Subject: Re: Semi-Newbie. Is newapp push or pull?
> > >
> > >
> > > On Sun, 2002-05-05 at 17:27, Bill Holloway wrote:
> > > > Gulp. OK. That steepens the learning curve -- maybe -- I
> > > was wondering
> > > > what all the "Flux" stuff was.
> > > >
> > > > Are there any users of this "mixed" model out there who
> > > have an opinion on
> > > > its stability/usability? Thanks.
> > >
> > > It's very useful, but each model has its place.
> > >
> > > Push model: I have a Java class tied to a particular screen (or
> > > layout), and the Java class pushes the data to that particular
> > > screen/layout. The data is available only to that
> > particular screen.
> > > Good for special purpose applications, e.g.
> restricted-access admin
> > > functions.
> > >
> > > Pull model: I have a Java class that creates data that might
> > > be useful
> > > on any number of arbitrary pages, and I can include that
> data on any
> > > screen or layout I want. The nice thing about pull model
> > is that you
> > > can define dynamic data, and make it available to less-technical
> > > designer types, without having to know or care which screen
> > > or template
> > > it appears on. For example, if you have a Localinfo pull
> > service that
> > > defines a time(), date() and weather() method, you can tell
> > your HTML
> > > pushers that they can easily include dynamic time, date,
> and weather
> > > info in their pages just by inserting tags that say
> > >
> > > $localinfo.time()
> > > $localinfo.date()
> > > $localinfo.weather()
> > >
> > > They can put that much on a 3x5 card, and then design the web site
> > > however they like.
> > >
> > > The difference between push and pull is strictly a matter
> of how the
> > > dynamic objects get put into the Velocity context. In the
> > > push model, a
> > > screen-specific or layout-specific class puts the dynamic
> > object into
> > > the context for that particular screen/layout. In the pull
> > model, the
> > > pull service put the dynamic object(s) into the Velocity
> > > context of all
> > > screens and layouts. In fact, the pull service puts the
> > objects into
> > > the contexts of screens and layouts that have push-model
> > > objects, so if
> > > you have a screen that uses the push model, you can use
> > both push and
> > > pull in the same screen.
> > >
> > > Caveat: I'm still learning Turbine, so if I'm misrepresenting
> > > something, feel free to correct me, but I believe that's correct.
> > >
> > > Mark Nutter
> > > [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]>
