On Fri, Aug 22, 2008 at 4:39 PM, Lilianne E. Blaze
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> Nathan Bubna wrote:
>> No, i don't have JSF plans, and i'm not aware of anyone else having them.
>>
>> As for VelocityView, you don't really need it unless you want
>> VelocityTools support included in your tags. You can load and process
>> templates just fine with only a VelocityEngine and any Context
>> instance.
>>
>> If you do want a VelocityView and need to use your own VelocityEngine
>> instance, then you probably have a lot of work cut out for you, as
>> that isn't well supported at this time. Basically, you will have to
>> subclass VelocityView to override getVelocityEngine() and probably a
>> few other things as well. If you want more details on doing that,
>> i'll help. Just let me know. However, i would seriously question
>> whether that is worth it. You might just find it easier to use the
>> VelocityEngine set up for you by VelocityView, either in parallel with
>> or as a replacement for Spring's.
>>
>> And no, yes, you could just drop your own VelocityView in the
>> application attributes, and ServletUtils would find it. It is not,
>> however, a ServletContextListener. It would only look for it when
>
> I know it isn't now, but that's how I'd do it (see below).
>
>> requested (usually only at init of servlet/tag/filter, not during
>> runtime). Because of this, it is recommended that you use a
>> org.apache.velocity.tools.view.class init-param to point ServletUtils
>> to your custom VelocityView subclass and let it create the instance.
>> Otherwise, just use
>> application.setAttribute(ServletUtils.VELOCITY_VIEW_KEY, myVV), but
>> make sure that the filter/tag/servlet making that call does so before
>> any other servlet/tag/filter that wants the VelocityView.
>
> Which in my case would be from a ServletContextListener just after
> Spring's SCL.
>
> Ok, here's how I see it - please tell me what you think. Note this is
> pseudo-code, I haven't tried it yet. If I get it right, such
> initialization would modify the provided VelocityEngine to add
> Tools-specific things but otherwise leave most of it's custom
> initialization intact, correct?
actually, Tools isn't much concerned with the VelocityEngine. what is
most important for Tools support is the Context used.
> Also, could you consider adding VelocityView(JeeConfig,VelocityEngine)
> and/or VelocityView(ServletContext,VelocityEngine) constructors?
i'd rather not. Then we have to worry about whether the Engine passed
in has been initialized already or not. Just override
VelocityView.getVelocityEngine() to return the engine of your choice.
Here, i've modified your pseudo-code below:
>
> public class CustomVVEagerInit implements ServletContextListener
> {
>
> public void contextInitialized(ServletContextEvent sce)
> {
> ServletContext sc = sce.getServletContext();
>
> engine = getVelocityEngine();
>
> view = new CustomVV(application, engine);
> application.setAttribute(ServletUtils.VELOCITY_VIEW_KEY, view);
> }
>
> protected VelocityEngine getVelocityEngine()
> {
> // get or create custom VelocityEngine
> }
>
>
> }
>
> class CustomVV extends VelocityView
> {
> private VelocityEngine engine;
> public CustomVV(ServletContext context, VelocityEngine engine)
> {
> JeeConfig jeeConfig = new JeeConfig(context);
> init(jeeConfig);
> }
>
> public VelocityEngine getVelocityEngine()
> {
> return engine;
> }
>
> }
i think that might do the trick, assuming you use the latest code in
the trunk of VelocityTools.
>
> Greetings, L
>
>
>
> ---------------------------------------------------------------------
> 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]
