You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Will Glass-Husain <wg...@forio.com> on 2002/01/21 18:48:27 UTC
Implementing Pull MVC model
Hi,
As a new Turbine user, I read Jon Steven's article on the Pull MVC model.
Makes a lot of sense to me (this is how I've been working with Velocity for
the last 6 months).
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
But Turbine's default implementation appears to be a Push model, where every
Velocity page requires a Java class. However, I'd like to enable my
template designers to add new navigational links without requiring the
programmer to write a new Java class.
Is there a built-in structure that enables this, or do I implement my own
additional framework? I searched the docs, but didn't see an obvious
recommended solution. What's the "Best Practice" here?
Thanks,
WILL
_______________________________________
Forio Business Simulations
Will Glass-Husain
(415) 440-7500 phone
(415) 235-4293 mobile
wglass@forio.com
www.forio.com
Re: Implementing Pull MVC model
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Hey Jeff, this is good stuff. If you'd like to merge it into the
existing documentation and submit a patch to turbine-dev, it would be
much appreciated.
Daniel Rall
"Jeff Linwood" <je...@greenninja.com> writes:
> Thanks for pointing that out - I just spent a lot of time creating a HOWTO
> for Using pull models in Turbine 2, based on that recent email. I didn't
> know about the pull service HTML.
>
> Well, here's what I wrote - I can put it into XDOC format if anyone is still
> interested.
>
>
> Using the pull model with Turbine 2
>
>
>
> Turbine 2 can be used with two different programming models - the push model
> and the pull model. The difference is in how the Context is built up. The
> Context is used by the Velocity or WebMacro template files to "fill in the
> blanks" and introduce dynamic data into a static HTML-based template. This
> programming concept is incredibly powerful - because it allows the web
> designer, who may be experienced with HTML, CSS, and Javascript but not
> Java, to put data fields wherever they want on a page without having to ask
> the Java programmers to change a Java class and recompile. For more
> information on which to choose for your Turbine application, read Jon Steven
> 's informative commentary Push vs Pull.
> http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
>
>
>
> The push model is found in the Flux/NewApp application that is distributed
> with the TDK 2.1. It is based on a one-to-one mapping of Java Screen
> classes and Velocity template files. The Screen class puts key/value pairs
> into the Context. The Context HowTo
> http://jakarta.apache.org/turbine/turbine-2/howto/context-howto.html
> explains this approach.
>
>
>
> The pull model allows the web designer even more freedom than the push
> model. Java programmers can create globally accessible Java classes known as
> Tools. These Tools are going to be useful for getting data out of a
> service and bringing it to the presentation layer, authenticating users, or
> creating links (see the TemplateLink tool that is built into Turbine).
>
>
>
> Your SimpleSecurityTool should implement ApplicationTool, which is a simple
> interface with two methods, init(Object data) and refresh. It could be a
> facade class that calls other classes, or it could have its own business
> logic.
>
>
>
> To make the Tool available to Turbine, you need to define your Tools in the
> TurbineResources.properties file. The "Pull Service" section of the
> properties file is where the tools are listed. You can use the following
> syntax (all explained in the TurbineResources.properties):
>
>
>
> tool.<Scope>.<Id> = <Classname>
>
>
>
> tool.request.formsTool = com.yourcompany.turbine.tools.SimpleFormsTool
>
>
>
> Classname is your java classname -
> com.yourcompany.turbine.tools.SimpleFormsTool
>
>
>
> Id is a unique identifier that you will use in your Velocity templates -
> formsTool, for instance.
>
>
>
> Scope defines the life cycle of the Tool. There are four, global, request,
> session, and persistent.
>
>
>
> Global: The tool is instantiated once and is available to all templates for
> all requests. Must be threadsafe.
>
>
>
> Request: The tool is instantiated once for every request to Turbine.
> Doesn't need to be threadsafe. The link, page, and flux tools are all
> defined as request scope.
>
> Session: The tool is instantiated once for each user session. Should be
> threadsafe. Useful for tools that might hold user profiles, or items in a
> shopping cart.
>
>
>
> Persistent: Tool is instantiated once for each user session, and is stored
> along with the user information. Must be threadsafe and implement
> Serializable. An example of how this scope would be used would be great!
>
>
>
> Additional tool-defined properties can be configured in the
> TurbineResources.properties. The syntax is defined under the "Pull Service"
> section.
>
>
>
> ----- Original Message -----
> From: "Rodney Schneider" <rl...@arcalink.com>
> To: "Turbine Users List" <tu...@jakarta.apache.org>
> Sent: Monday, January 21, 2002 10:24 PM
> Subject: Re: Implementing Pull MVC model
>
>
>> Hi,
>>
>> Also see:
>>
>> <http://jakarta.apache.org/turbine/turbine-2/services/pull-service.html>
>>
>> Regards,
>>
>> -- Rodney
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Implementing Pull MVC model
Posted by Will Glass-Husain <wg...@forio.com>.
Thanks to everyone for the helpful comments.
As a new user, I definitely recommend this and similar info be added as a
HOWTO in the docs.
WILL
-----Original Message-----
From: Jeff Linwood [mailto:jeff@greenninja.com]
Sent: Monday, January 21, 2002 9:29 PM
To: Turbine Users List
Subject: Re: Implementing Pull MVC model
Thanks for pointing that out - I just spent a lot of time creating a HOWTO
for Using pull models in Turbine 2, based on that recent email. I didn't
know about the pull service HTML.
Well, here's what I wrote - I can put it into XDOC format if anyone is still
interested.
Using the pull model with Turbine 2
Turbine 2 can be used with two different programming models - the push model
and the pull model. The difference is in how the Context is built up. The
Context is used by the Velocity or WebMacro template files to "fill in the
blanks" and introduce dynamic data into a static HTML-based template. This
programming concept is incredibly powerful - because it allows the web
designer, who may be experienced with HTML, CSS, and Javascript but not
Java, to put data fields wherever they want on a page without having to ask
the Java programmers to change a Java class and recompile. For more
information on which to choose for your Turbine application, read Jon Steven
's informative commentary Push vs Pull.
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
The push model is found in the Flux/NewApp application that is distributed
with the TDK 2.1. It is based on a one-to-one mapping of Java Screen
classes and Velocity template files. The Screen class puts key/value pairs
into the Context. The Context HowTo
http://jakarta.apache.org/turbine/turbine-2/howto/context-howto.html
explains this approach.
The pull model allows the web designer even more freedom than the push
model. Java programmers can create globally accessible Java classes known as
Tools. These Tools are going to be useful for getting data out of a
service and bringing it to the presentation layer, authenticating users, or
creating links (see the TemplateLink tool that is built into Turbine).
Your SimpleSecurityTool should implement ApplicationTool, which is a simple
interface with two methods, init(Object data) and refresh. It could be a
facade class that calls other classes, or it could have its own business
logic.
To make the Tool available to Turbine, you need to define your Tools in the
TurbineResources.properties file. The "Pull Service" section of the
properties file is where the tools are listed. You can use the following
syntax (all explained in the TurbineResources.properties):
tool.<Scope>.<Id> = <Classname>
tool.request.formsTool = com.yourcompany.turbine.tools.SimpleFormsTool
Classname is your java classname -
com.yourcompany.turbine.tools.SimpleFormsTool
Id is a unique identifier that you will use in your Velocity templates -
formsTool, for instance.
Scope defines the life cycle of the Tool. There are four, global, request,
session, and persistent.
Global: The tool is instantiated once and is available to all templates for
all requests. Must be threadsafe.
Request: The tool is instantiated once for every request to Turbine.
Doesn't need to be threadsafe. The link, page, and flux tools are all
defined as request scope.
Session: The tool is instantiated once for each user session. Should be
threadsafe. Useful for tools that might hold user profiles, or items in a
shopping cart.
Persistent: Tool is instantiated once for each user session, and is stored
along with the user information. Must be threadsafe and implement
Serializable. An example of how this scope would be used would be great!
Additional tool-defined properties can be configured in the
TurbineResources.properties. The syntax is defined under the "Pull Service"
section.
----- Original Message -----
From: "Rodney Schneider" <rl...@arcalink.com>
To: "Turbine Users List" <tu...@jakarta.apache.org>
Sent: Monday, January 21, 2002 10:24 PM
Subject: Re: Implementing Pull MVC model
> Hi,
>
> Also see:
>
> <http://jakarta.apache.org/turbine/turbine-2/services/pull-service.html>
>
> Regards,
>
> -- Rodney
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing Pull MVC model
Posted by Jeff Linwood <je...@greenninja.com>.
Thanks for pointing that out - I just spent a lot of time creating a HOWTO
for Using pull models in Turbine 2, based on that recent email. I didn't
know about the pull service HTML.
Well, here's what I wrote - I can put it into XDOC format if anyone is still
interested.
Using the pull model with Turbine 2
Turbine 2 can be used with two different programming models - the push model
and the pull model. The difference is in how the Context is built up. The
Context is used by the Velocity or WebMacro template files to "fill in the
blanks" and introduce dynamic data into a static HTML-based template. This
programming concept is incredibly powerful - because it allows the web
designer, who may be experienced with HTML, CSS, and Javascript but not
Java, to put data fields wherever they want on a page without having to ask
the Java programmers to change a Java class and recompile. For more
information on which to choose for your Turbine application, read Jon Steven
's informative commentary Push vs Pull.
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
The push model is found in the Flux/NewApp application that is distributed
with the TDK 2.1. It is based on a one-to-one mapping of Java Screen
classes and Velocity template files. The Screen class puts key/value pairs
into the Context. The Context HowTo
http://jakarta.apache.org/turbine/turbine-2/howto/context-howto.html
explains this approach.
The pull model allows the web designer even more freedom than the push
model. Java programmers can create globally accessible Java classes known as
Tools. These Tools are going to be useful for getting data out of a
service and bringing it to the presentation layer, authenticating users, or
creating links (see the TemplateLink tool that is built into Turbine).
Your SimpleSecurityTool should implement ApplicationTool, which is a simple
interface with two methods, init(Object data) and refresh. It could be a
facade class that calls other classes, or it could have its own business
logic.
To make the Tool available to Turbine, you need to define your Tools in the
TurbineResources.properties file. The "Pull Service" section of the
properties file is where the tools are listed. You can use the following
syntax (all explained in the TurbineResources.properties):
tool.<Scope>.<Id> = <Classname>
tool.request.formsTool = com.yourcompany.turbine.tools.SimpleFormsTool
Classname is your java classname -
com.yourcompany.turbine.tools.SimpleFormsTool
Id is a unique identifier that you will use in your Velocity templates -
formsTool, for instance.
Scope defines the life cycle of the Tool. There are four, global, request,
session, and persistent.
Global: The tool is instantiated once and is available to all templates for
all requests. Must be threadsafe.
Request: The tool is instantiated once for every request to Turbine.
Doesn't need to be threadsafe. The link, page, and flux tools are all
defined as request scope.
Session: The tool is instantiated once for each user session. Should be
threadsafe. Useful for tools that might hold user profiles, or items in a
shopping cart.
Persistent: Tool is instantiated once for each user session, and is stored
along with the user information. Must be threadsafe and implement
Serializable. An example of how this scope would be used would be great!
Additional tool-defined properties can be configured in the
TurbineResources.properties. The syntax is defined under the "Pull Service"
section.
----- Original Message -----
From: "Rodney Schneider" <rl...@arcalink.com>
To: "Turbine Users List" <tu...@jakarta.apache.org>
Sent: Monday, January 21, 2002 10:24 PM
Subject: Re: Implementing Pull MVC model
> Hi,
>
> Also see:
>
> <http://jakarta.apache.org/turbine/turbine-2/services/pull-service.html>
>
> Regards,
>
> -- Rodney
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing Pull MVC model
Posted by Rodney Schneider <rl...@arcalink.com>.
Hi,
Also see:
<http://jakarta.apache.org/turbine/turbine-2/services/pull-service.html>
Regards,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing Pull MVC model
Posted by Jeff Linwood <je...@greenninja.com>.
Hi,
Also, you'll need to define pull service Tools in your
TurbineResources.properties.
For instance,
tool.global.simpleSecurityTool=com.yourcompany.turbine.tools.SimpleSecurityT
ool
Your SimpleSecurityTool should implement ApplicationTool, which is a simple
interface with two methods, init(Object data) and refresh. It could be a
facade class that calls other classes, or it could have its own business
logic.
>From your velocity template, call $simpleSecurityTool.getUserName() or what
have you.
Jeff
jeff@greenninja.com
----- Original Message -----
From: "John McNally" <jm...@collab.net>
To: "Turbine Users List" <tu...@jakarta.apache.org>
Sent: Monday, January 21, 2002 12:13 PM
Subject: Re: Implementing Pull MVC model
> You only need one java class per top level directory, so if you have
> your templates stored in src/templates
> screens/Index.vm
> screens/admin/Index.vm
>
> One screen package module will work <package.prefix>.screens.Default
>
> This class does not have to do much, but it is a reasonable place to
> implement a security policy, if desired.
>
> john mcnally
>
> Will Glass-Husain wrote:
> >
> > Hi,
> >
> > As a new Turbine user, I read Jon Steven's article on the Pull MVC
model.
> > Makes a lot of sense to me (this is how I've been working with Velocity
for
> > the last 6 months).
> >
> > http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
> >
> > But Turbine's default implementation appears to be a Push model, where
every
> > Velocity page requires a Java class. However, I'd like to enable my
> > template designers to add new navigational links without requiring the
> > programmer to write a new Java class.
> >
> > Is there a built-in structure that enables this, or do I implement my
own
> > additional framework? I searched the docs, but didn't see an obvious
> > recommended solution. What's the "Best Practice" here?
> >
> > Thanks,
> >
> > WILL
> > _______________________________________
> > Forio Business Simulations
> > Will Glass-Husain
> > (415) 440-7500 phone
> > (415) 235-4293 mobile
> >
> > wglass@forio.com
> > www.forio.com
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing Pull MVC model
Posted by John McNally <jm...@collab.net>.
You only need one java class per top level directory, so if you have
your templates stored in src/templates
screens/Index.vm
screens/admin/Index.vm
One screen package module will work <package.prefix>.screens.Default
This class does not have to do much, but it is a reasonable place to
implement a security policy, if desired.
john mcnally
Will Glass-Husain wrote:
>
> Hi,
>
> As a new Turbine user, I read Jon Steven's article on the Pull MVC model.
> Makes a lot of sense to me (this is how I've been working with Velocity for
> the last 6 months).
>
> http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
>
> But Turbine's default implementation appears to be a Push model, where every
> Velocity page requires a Java class. However, I'd like to enable my
> template designers to add new navigational links without requiring the
> programmer to write a new Java class.
>
> Is there a built-in structure that enables this, or do I implement my own
> additional framework? I searched the docs, but didn't see an obvious
> recommended solution. What's the "Best Practice" here?
>
> Thanks,
>
> WILL
> _______________________________________
> Forio Business Simulations
> Will Glass-Husain
> (415) 440-7500 phone
> (415) 235-4293 mobile
>
> wglass@forio.com
> www.forio.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing Pull MVC model
Posted by Luke Holden <al...@prodigy.net>.
This would be done using turbines pull service.
In your.package.tools you might have a class called something like
'lotsOfCoolStuffTool'... which Implements 'ApplicationTool' and 'Recyclable'.
This tool would be put into contex from the TR.prefs file with a line like
this:
tool.request.cool=your.package.tools.lotsOfCoolStuffTool
the documentation for how this works is in the default TR.prefs file... but
basically 'request' is the scope, 'cool' is the context and
'your.package.tools.lotsOfCoolStuffTool' is your pull tool.
In your code you would access the class via $cool.
Editing the TR.prefs file you will also notice 'tool.request.link' and
'tool.request.page'. I have sure you have used $link and $page in your code
somewhere. Those classes are just pull tools.
>From there its as simple as adding new methods to your new class and letting
your template designers know about them.
For example... I have a pull tool specific to a set of forms. The template
pulls the data from the tool to fill out the form. That or the tool gives
blank data if the form should be blank. The submit is sent to an action which
verifies the data. On an error, the action dumps the user back to the form
(in which case when the template pulls data from the tool, the tool see's
this and gives the data the user was editing instead of pulling data from the
db.) Other wise the action finishes up processing the data and the user moves
on to the next form.
Anyways... That should get you started. Sorry for the poor explenation I just
woke up :)
Luke
On Monday 21 January 2002 09:48 am, you wrote:
> Hi,
>
> As a new Turbine user, I read Jon Steven's article on the Pull MVC model.
> Makes a lot of sense to me (this is how I've been working with Velocity for
> the last 6 months).
>
> http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
>
> But Turbine's default implementation appears to be a Push model, where
> every Velocity page requires a Java class. However, I'd like to enable
> my template designers to add new navigational links without requiring the
> programmer to write a new Java class.
>
> Is there a built-in structure that enables this, or do I implement my own
> additional framework? I searched the docs, but didn't see an obvious
> recommended solution. What's the "Best Practice" here?
>
> Thanks,
>
> WILL
> _______________________________________
> Forio Business Simulations
> Will Glass-Husain
> (415) 440-7500 phone
> (415) 235-4293 mobile
>
> wglass@forio.com
> www.forio.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>