Ofbiz/Webslinger preparation discusssion

[Adam Heath-2]

As discussed several times(thru mail and irc), we(Brainfood) want to get
 our template system integrated into ofbiz.  Towards that end, there are
several things that we'd like to get done in ofbiz first, before we can
submit our code.

First, however, I think I should restate some of the features that
Webslinger brings to the table.

==
1: File access is done quite consistently thru commons-vfs.  This is a
more advanced file api then what you get thru java.io.File and
java.net.URL.  We've written several layered filesystems to support
features unique to webslinger.  The most important one is a
COW(Copy-On-Write) layer; the second is being able to have 'attributes'
as normal files(each file can have an optional $file@ dir, where each
attribute is stored as a separate file).

2: Events and templates are quite advanced in webslinger.  These are
based on bsf(the template engine extends BSFManager), so the programming
api is proven.  bsf has been extended to support more advanced file-like
loading.  The primary parameter based to bsf is no longer a String, but
a generic Object(this doesn't actually change the api; if you look
closely, it already takes an Object).  A generic simple vfs-lookup
interface is then used to fetch a String/InputStream from that object,
for handling by each engine.  There are also several patches that add to
the api, so that proper caching of compiled/parsed templates/classes can
be done(for extreme speed).  We have fast implementations of events for:
java(janino), javascript(rhino), python(jython), ruby(jruby),
python(quercus), beanshell; templates for: velocity, freemarker.

3: Cross-event dispatch model: The template engines listed above have
their own internal way to extend their runtime, with macros.  So, the
webslinger template engine has a generic macro extension mechanism.  A
macro can be written in *any* language(event/template/something else),
and be called using the template's native syntax.  For example:

velocity:
#MyMacro($arg1 "foobar")text body#end

freemarker:
<@MyMacro name="${arg1}" value="foobar">text body</@MyMacro>

In these cases, MyMacro maps to /WEB-INF/Macros/MyMacro, which can be
implemented in any language.

4: COW implementation: Websites in webslinger have the separate
hostname->website mapping.  Multiple hostnames can be mapped to a single
website.  This website then maps to a primary commons-vfs url, and
several base urls to inherit from.  Creating a new website is just a
matter of creating a few entities, and then editting files.  As they are
editted, the COW code makes local copies as appropriate.  Websites are
extremely lightweight, no full copy needs to take place.

5: Modules: Modules can extend webslinger, by being 'mounted' into the
VirtualFileSystem implementation we have.  They are then overlayed using
the COW code, so that they all appear as a single file system.  Each
module has a www/path/to/file, unique to whatever it is attempting to
do, and the website sees them all as one.

==

That's the basic set of features.  However, to make webslinger and ofbiz
fit optimally together, several things need to be done to ofbiz first.

1: Remove hard-coded lists of implementations.  For instance,
org.ofbiz.base.util.template.FreeMarkerWorker has a list of classnames
that it tries to load dynamically.  These classes are located *outside*
of base.  So, whenever something is changed elsewhere, you also have to
change base.  This is poor, even more so if ofbiz is ever split up into
a base download, and a set of application downloads.

The fix for this is to use javax.imageio.spi.ServiceRegistry.  This code
will find all /META-INF/services/$name files, and load all classes
listed therein.  It can be used to have an extension implement some
interface, and a base class can then just register all found
implementations.

I am willing to fix all cases of code in this manner.  In addition to
the above example, the service engine also should be altered to use this
loading api.

2: Modify the container/component loader, so it can use relative paths.
 I already have a patch for this.  This makes it easier to extend ofbiz,
by just dropping an application into hot-deploy, or somewhere else, and
not being concerned about where in the tree it is.

3: Use commons-vfs, instead of FlexibleLocation.  In addition to
supporting more file system types(cifs/svn), it supports http; this
could be combined with COW, where the base is a remote filesystem, with
a local pointer overlayed on top.  Once all file access goes thru
commons-vfs, it becomes simple to do complex virtual hosting.  I already
have implementations of ofbiz-component://$component/path and
ofbiz-home://path for commons-vfs.

I need help with this item.
==

I'll be sending some patches to start this work shortly.

[Adam Heath-2]

Adam Heath wrote:
> 2: Events and templates are quite advanced in webslinger.  These are
> based on bsf(the template engine extends BSFManager), so the programming
> api is proven.  bsf has been extended to support more advanced file-like
> loading.  The primary parameter based to bsf is no longer a String, but
                                  passed
> a generic Object(this doesn't actually change the api; if you look
> closely, it already takes an Object).  A generic simple vfs-lookup
> interface is then used to fetch a String/InputStream from that object,
> for handling by each engine.  There are also several patches that add to
> the api, so that proper caching of compiled/parsed templates/classes can
> be done(for extreme speed).  We have fast implementations of events for:
> java(janino), javascript(rhino), python(jython), ruby(jruby),
> python(quercus), beanshell; templates for: velocity, freemarker.