David E. Jones wrote:
Um, this seems bad. Using non-free software for a free software
project? Wouldn't this be equally bad, now that ofbiz is an apache
project?
David Welton answered this pretty well. Here again I like a pragmatic
approach. I'm all for open source software, when it's available and a
tenable option. I'll be the first to admit that OFBiz, for example, is
not the solution for all problems.
Yeah, he did.
I'd love to use OFBiz-based stuff instead of commercial things (even
open source based commercial things like the Atlassian products, of
which Jira actually even uses parts of OFBiz), but we just don't have
the functionality on the business/applications level in these areas nor
the resources to build them out, especially not within the time frame we
need them (like immediate and ongoing...).
Well, if you recall, last summer during the OfBiz User's Conference, we
were displaying some wiki based software. We're fast approaching the 1
year mark on it's birth, and we haven't sat still with it's development.
Right now, I am rewriting the basic framework in it, extracting it out
of OfBiz proper, and making it a stand-alone project. Said project will
be under either a BSD or ASF license; we haven't fully decided.
Main features:
* commons-vfs for generic file access
* implemented filesystems:
* COW(Copy-On-Write). Used for quick templating/extension.
Changing a file contents is supported, as are deletes. Multiple
parents are supported(a single directory can have multiple parent
directories it inherits from). Also, if a parent directory is
also COWed, then it can still walk all that. Directory listings
function as expected.
* flat. Attributes of files are stored in a foo@ directory, one
file per attribute. This sits on top of COW, so overriding a
single attribute is simple.
* SVN. Uses libsvnjava-hl, for automatic revision control of file
modifications. The actual SVN filesystem itself uses a generic
revision control API, so in theory other systems could be plugged
in.
* BSF, with compilation support
* Existing BSF engines were rewritten, to support dynamic class-based
source loading. This includes the ability to load from File,
String, URL, and FileObject(commons-vfs). The BSF API uses an
Object as the source, so this was a straight-forward extension.
* The new implementations also compile the source, for a large
speedup.
* python(jython), java(janino), php(quercus), javascript(rhino), and
ruby(jruby) all exist in this new framework.
* Only one extension to BSF has been made: apply allows for optionally
specifying the type of the named arguments
* A template engine, based on the BSF API
* freemarker and velocity are plugged into this system
* A macro can be written in any template language, and included in
any
template language.
* Macros can have both parameters, and bodies.
* A resource can be in any language; it's parent template that it is
included into can then be in another language. Named sections can
also be written in any language.
For example, /foo has a template set to /templates/bar.
/templates/bar then has a template of /templates/baz. /foo is a
velocity file. bar could be an event(which could be written in
java/python/php/ruby/javascript), that changes the text based on
permissions, time-of-day, or phases of the moon. Like maybe
changing the color, css, or switching left/right sides of a div.
Then, once the event had made it's decision, the baz template would
be used to wrapped it's output.
* A resource can be a bit of text, interpeted as a template, or a bit of
code, that is run when it is requested.
* Code-based resources include standard events, and something we call a
filter(bad name). A filter can do whatever kind of processing it
wants with the rest of the path that comes after it. For example:
/category/10000/0/20/summary
This would show category 10000, starting and page 0, show 20 items per
page, and show the summary of the products. What is nice about this
approach, is it makes for very nice entries in access logs.
* Since a resource can be either code or text, the template engine also
works with that. A named section, parent template, or macro can
actual be a bit of code, that does complex processing. Again, and
example may be the easiest way to describe this.
freemarker:
<tr>
<td>
<@TemplateMerge name="/category/10000/0/20/summary"/>
</td>
<tr>
* Most code(with the exception of the very low-level commons-vfs
filesystems, and the single servlet) is runtime changeable. You can
edit the actual dispatcher code at runtime, and the classloader will
be recycled.
* A runtime controllable(by having events run, or even editting the
dispatcher java file itself), allows one to have very complex
request->site mapping. One can do the normal host->site mapping, but
could also do something based on time-of-day.
* Something that could be done with this system, is a nice use of the
COW feature, and the above site mapping. There could be a base
directory, that contained all the code for a site. Then, when a
request comes, a COWed directory that inherits from the code base
could be selected, based on the user's locale, and possibly a geo-ip
lookup.
As a framework, is it very extensible. However, as with most projects,
it has reach a point where it has accumulated cruft; both in the form of
poorly implemented features, and backwards compatibility. This is the
reason I am currently reworking it to be standalone, and a separately
released project.
However, the existing code-base has been put to quite a bit of testing.
An example of both the framework, and the ofbiz integration, is at
http://checkmark.heart.org.
