[opencms-dev] On how to integrate OpenCMS and velocity:

[Michael Emmerich]

Alex,

> Velocity integration will require more then the "simple" addition of a
> new launcher. I already have looked into this, since it is close to my
> JSP approach, and this is not the answer. Here's why:

as I said, my thoughts were based on Werners mail and code example. The
"simple" addition of a new launcher & resource type  would of cousrse
have soem challanging aspects in it :)
 
> 1. The synchronized issue Werner has pointed out is not going to
> disappear, since it is the _Velocity_ engine that requires this. Werners
> implementation of the OpenCMSResourceLoader.class is used within
> Velocity and the class is not initialized from OpenCms. Velocity can
> with that class already access files in the OpenCms repository. The
> synchronization is the hack to put the current cms Object into the
> Velocity OpenCMSResourceLoader, which has a static cms Object. There is
> not other simple way to pass the current CmsObject to the Velocity
> ResourceLoader (at last not one I can think of right now). Adding a new
> launcher will not solve this problem, since the ResourceLoader must
> still be initialized.

Sure. But when you look at Werners code example, you just see one method
call which parses the VTL and gets the out put back. This output is then
set into the XMLTemplate. Take a look what happens:

1) A resource is requested from OpenCms.
2) The resource header is loaded form the DB.
3) The OpenCms XML-Launcher is selected.
4) Werners getContent Method is called
5) The content of Werners XML-Template is loaded and parsed.
6) Werners LC_Velocity_OpenCMS.getInstance().parseTemplate method is
called, the VTL is loaded, parsed and the output is
generated
7) The VTL output is set into the XML-Template
8) The XML-Template is processed and its output is send back to the
client.

So the OpenCms Template mechanism is used as a wrapper to start the VTL
processing - at least this is what the code example looks like. The
LC_Velocity_OpenCMS is initialized somewhere outside the example, but
what would prevent to initialize the ResourceLoader in a new OpenCms
launcher class?

> 2. Velocity is in many aspects like the XMLTemplates of OpenCms. A
> Velocity template must be called from a servlet. Previously, the servlet
> must set parameters in a context that will then be accessible in the
> VTL. Same as with XMLTemplates. Advantage of the VTL is much easier
> syntax and the ability to iterate over arrays, enumerations and such,
> which is not possible in the XMLTemplates. So if you write a launcher
> for VTL this must be able to also select a "default" velocity servlet
> along with the template. So additionally to the launcher, one must also
> provide something like a com.opencms.template.CmsRootTemplate.

The current Template mechansim always used a template and a Java Class
to process the template, so a launcher for Velocity could use avery
similar mechanism, define a VTL and a Velocity servlet. As you said,
this is very similar than the current template mechanism works within
OpenCms. Therefore this would even more be an argument to use a launcher
based integration into OpenCms.
 
> BTW here's what I think would be the way to improve the situation:
> 
> For 1) I currently think of 3 Options:
> 
> Option 1: Mirror to "real" FS
> In this scenario, every VTL file in the VFS is mirrored to the "real" FS
> in some directory. Similar to my JSP approach. Velocity then read these
> files using it's standard "file" ResourceLoader. Problem: Mirrored files
> must be managed by OpenCms, and files in "real" FS will have no
> permission system attached.

Well, remember that we once had a way to mount the real FS into the VFS.
With the current project mechanism, you would have to map into an online
and an offline verison in the FS, this makes it much eaiser than our old
approach. Regarding the permission system, we had the the workarounds to
get them run on the real FS as well. But an alternaertive would be to
keep the permissions databesed based even for resourcs that are stored
in the FS itself, as you say, the files in the FS must be managed by
OpenCms therefore it should be possible to store the access permissions
somewhere else.

> Option 2: Pass CmsObject to Velocity ResouceLoader
> Lets assume it would be possible to pass an initialized CmsObject cms to
> the Velocity ResouceLoader. How this would be done I was not able to
> figure out yet, maybe it would require some extending of the internal
> Velocity classes. The goal would be that the ResourceLoader would have
> acceess to a CmsObject like in Werners implementation, however this
> would not need to be synchornized. That way, each access to a VTL would
> be done using the permissions of the current logged in user. However,
> this would mean a lot of work in (probably extending Velocity) and also
> would make template caching in velocity rather unusable, since this is
> also not OpenCms permission based. You would end up with having to load
> the template every time from the DB, which will impact performance.

I agree, this sounds like the most difficult alternative. And I don't
think that extending the internal Velocity classes would be the way to
be done to fully integrate it into OpenCms.

> Option 3: Have a standard Velocity permission set
> Here, every VTL in the OpenCms would be required to have some common
> permission structure, which might be a CmsUser or a CmsGroup. Let's say
> we have a standard user "velocity". Every VTL must be made accessible to
> "velocity". A new Velocity ResourceLoader would simply always work as a
> user "velocity", and the username / password could be set in the
> Velocity property file.
> 
> For the record, I currently would go with Option 3.

Ok, but what is your approach for the "problem" that started this
thread? Should the VTL still be integrated inside a OpenCms XML
Template? 
 
> For 2) I have not thought about that in great detail, but I think there
> could be something like a "CanonicalRoot" for the VTL, ie. a velocity
> sevlet with some standard action.

> PS: Michael, what about my question regarding the wrapping of the
> response output - stream? BTW, I have found out there is a
> javax.servlet.http.HttpServletResponseWrapper already defined in the
> Servlet 2.3 API for _exactly_ that purpose. That pretty much answers the
> question, I would say.

I had no time to look on your question so far - project work......

> I should RTFM more often ;-)

No comment on this..... :)


Bye,
	Michael



-- 
Home   : emmerich at german-navy.de
Work   : michael.emmerich at framfab.de
ICQ    : 18897063
WWW    : German Naval History http://www.german-navy.de