The Pull service places tool objects in the Velocity context for use by template engineers. It can handle tools with various different "scopes", namely:
The service must be enabled and the desired tools configured in TurbineResources.properties as shown below. The default properties file lists some request-scope tools that are needed for basic Turbine usage ($page, $link and $content), plus the useful UITool skinning tool.
# ------------------------------------------------------------------- # # S E R V I C E S # # ------------------------------------------------------------------- # Classes for Turbine Services should be defined here. # Format: services.[name].classname=[implementing class] # # To specify properties of a service use the following syntax: # service.[name].[property]=[value] services.PullService.classname=org.apache.turbine.services.pull.TurbinePullService . . . # ------------------------------------------------------------------- # # P U L L S E R V I C E # # ------------------------------------------------------------------- # These are the properties for the Pull Service, the service # that works in conjuction with the Turbine Pull Model API. # ------------------------------------------------------------------- # This determines whether the non-request tools are refreshed # on each request (request tools aren't ever, because they're # instantiated for the request only anyway). services.PullService.tools.per.request.refresh=true # Path to the resources of the application tools, relative to the # application root # services.PullService.tools.resources.dir=/resources/ # These are tools that are placed in the context by the service # These tools will be made available to all your # templates. You list the tools in the following way: # # tool.<scope>.<id> = <classname> # # <scope> is the tool scope: global, request, session, # authorized or persistent (see below for more details) # <id> is the name of the tool in the context # # For example: # # tool.global.ui = org.apache.turbine.util.pull.tools.UITool # tool.global.mm = org.apache.turbine.util.pull.MessageManager # tool.request.link = org.apache.turbine.services.pull.tools.TemplateLink # tool.request.page = org.apache.turbine.util.template.HtmlPageAttributes # # (the next two examples specify mythical classes) # # tool.session.basket = org.sample.tools.ShoppingBasket # tool.persistent.ui = org.sample.tools.PersistentUIManager # # # Tools are accessible in all templates by the <id> given # to the tool. So for the above listings the UITool would # be available as $ui, the MessageManager as $mm, the TemplateLink # as $link and the HtmlPageAttributes as $page. # # Scopes: # # global: tool is instantiated once and that instance is available # to all templates for all requests. Tool must be threadsafe. # # request: tool is instantiated once for each request (although the # PoolService is used to recycle instances). Tool need not # be threadsafe. # # session: tool is instantiated once for each user session, and is # stored in the user's temporary hashtable. Tool should be # threadsafe. # # authorized: tool is instantiated once for each user session once the # user logs in. After this, it is a normal session tool. # # persistent: tool is instantiated once for each user session once # the user logs in and is is stored in the user's permanent # hashtable. # This means for a logged in user the tool will be persisted # in the user's objectdata. Tool should be Serializable. These # tools do not need to be threadsafe. # <b>persistent scope tools are deprecated in 2.3</b> # # Defaults: none tool.request.link=org.apache.turbine.services.pull.tools.TemplateLink tool.request.page=org.apache.turbine.util.template.HtmlPageAttributes tool.request.content=org.apache.turbine.services.pull.tools.ContentTool #tool.request.om=org.apache.turbine.om.OMTool #tool.request.intake=org.apache.turbine.services.intake.IntakeTool # The UITool will allow you to skin your Turbine application using simple # properties files that are located in the WEBAPP/resources/ directory # hierarchy. tool.global.ui=org.apache.turbine.services.pull.tools.UITool ## See UI Service documentation for further configuration options for UITool tool.ui.skin=default
The first step in use of the pull service is deciding on a useful tool API for an object that is available to templates in the Velocity context. This could range from something as simple as the generation of URIs ($link and $content) to a tool for retrieving details of the user's current shopping basket. Define a set of public methods for the tool and they will be available through standard Velocity introspection.
The next step is to decide what scope you need to give the tool. If the tool is retrieving global data in a threadsafe manner, you can make the tool global. If the tool holds data specific to the user look at the session and authorized scopes. If the tool needs to be instantiated on each request to fulfill its function, or is not threadsafe, then the request scope will be appropriate.
Tools can implement the org.apache.turbine.services.pull.ApplicationTool or the org.apache.turbine.services.pull.RunDataApplicationTool interface. This will provide a hook for the service to initialise them through the 'init' method and, except for request scope tools, to be refreshed through the 'refresh' method. The type of the init argument 'data' (declared as type 'Object') depends on the scope of the tool. For global tools the argument will be null; for session and persistent scope tools, 'data' will be the current User object; and for request scope tools 'data' will be the current RunData instance.
If you activate the RefreshToolsPerRequest property, every tool is refreshed on each request. On Request Tools this makes no difference, because here, the refresh() is never called (they're instantiated on every request). All other scopes get a call to refresh() on every request. If you chose to implement the RunDataApplicationTool interface, you get the current RunData object passed to your tool.
Important note: request scope tools are recycled by the PoolService. This means they must be written to be reused. This usually means implementing the ApplicationTool interface, and having the 'init' implementation reset all fields.
Current examples of tools include the afore mentioned $link, $page and $content objects, the $ui UI service tool, the Intake service tool (org.apache.turbine.services.intake.IntakeTool) and the OM tool (org.apache.turbine.om.OMTool).
The Velocity Tools - Generic Tools project provides a number of useful tools that can be used with your Turbine applications. To do this, all you need to do is to add the relevant velocity-tools-generic jar file to your dependencies and then configure the desired tools in your TurbineResources.properties thus:
tool.global.dateTool = org.apache.velocity.tools.generic.DateTool tool.global.mathTool = org.apache.velocity.tools.generic.MathTool tool.global.numberTool = org.apache.velocity.tools.generic.NumberTool tool.global.escTool = org.apache.velocity.tools.generic.EscapeTool tool.global.renderTool = org.apache.velocity.tools.generic.RenderTool tool.global.sortTool = org.apache.velocity.tools.generic.SortTool ...