By way of general commentary on this: the functionality sounds great as a
starting point for something that could compete well with Confluence. The
functionality here is still mostly oriented at solving technical problems
though, and in the case of docs.ofbiz.org there are certain functionality
requirements we need that would still have to be built.
I would also be concerned with this for a public wiki unless the code that you
can include in a page is extremely limited and can't do much, and even then it
would be a constant security concern. If you have an internal group working on
stuff then it's not such a big deal, but for a public wiki even if controlled
going in that direction is a bit scary.
However it's done when there is an alternative that is totally open source, and
it is one that the ASF supports or is likely to support, then we can go for it.
Until then, there's not much we can do.
For this thing on its own it looks pretty cool and it will be great to see it
available in an open source project.
-David
Adam Heath wrote:
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.
