> "Geir Magnusson Jr." wrote:
>[snip]
> > 2. VelocityServlet to provide a hook for subclasses to be able to
> > setup (a layered) context.
> > I also believe that VelocityServlet should not be abstract any
> > more to allow something like the JSP examples which operate
> > directly on the request and response objects.
>
> Hm. Not sure I am overjoyed about the change to handleRequest(), but
> I can't really think much about it until tonight when I get home.
The change in handleRequest() was to make the VelocityServlet
non-abstract. It is just an example of how it could be done
and uses the PathInfo to define the requested template name.
>
> >
> > These patches are fully backward compatible.
>
> Famous last words ;)
The signature of the existing mehtods did not change.
Only the prepareContext() was added, which contains the
(hard-wired) extracts of the original doRequest().
>
> > Next things I'm going to do:
> > A. Fix the log messages to reflect the correct template name
> > for errors within #parsed files. Also fix the parse depth
> > bug.
> > I will use a stack for the template names in the
> > LocalContextAdapter.
Fixed. Tested. Submiting patch next.
> > B. Fix FileResouceLoader and Logfile to allow files relative
> > to the servlet WEBAPP (when the properties entries do not
> > start with a /). If no servlet context has been setup,
> > then it will continue using the current pwd.
>
> Jason and I talked about that a while ago, and it's not clear that
> the FileResourceLoader is the way to go there, as it's something
> that can and should be handled at application level, as using
> Velocity in a servlet in a servlet runner is an application thing.
>
> In the interest of full disclosure :), I wanted to make a
> 'wrapper loader' that would use FileResourceLoader, but prefix as
> you suggest above (and to not do it conditionally :) ),
OK, so do you recommend to create a WebappResourceLoader?
> but on further consideration, and having it pointed out that
> Turbine does this internally just fine, I dropped the idea.
> The less app-specific support cruft in Velocity, the better,
> I think.
>
> For example, that might be something to add to VelocityServlet,
> incorporated in the init(), which is how I assume turbine does it.
I inspected this posibility. It is not possible to do what Turbine
does - it configures Runtime before is does the Runtime.init().
Overriding VelocityServlet.init() it either can:
* call super.init() before: causes the FileResourceLoader to be
already initialized and the adjusted path cannot be conveyed into it.
* call super.init() at the end of its own: will not allow using
the same properties file (which is loaded during Runtime.init())
and therefore requires an additional properties file.
>
> > C. Submit an ApplicationServlet and context tools that
> > allows creating an MVC servlet based on VTL. This is already
> > working greatly for me (I moved my whole application from
> > Trubine to Velocity! - since Turbine dev is yet to dynamic
> > and, AFAICS, Vel is reaching a state where it can be released).
>
> Sounds good, but I am 100% -1 on adding 'too many' special purpose
> context tools to the vel core distribution for a whole bunch of
> reasons. I think we should talk more about making a place for
> unsupported-and-dont-come-with-the-core-but-the-community-actively-supports
> toolsets like this.
I agree. We should create a contributions path or site.
>
> I will put in the ResourceManager patch tonight if there are no objections, but want
>a chance to look at the servlet stuff with clear focus.
>
> Good job.
>
> geir
:) Christoph
