Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Wed, 15 Oct 2003 17:10:59 -0400
From: Javier del Gesu <delgesu-cocoon@thinknola.com>
To: dev@cocoon.apache.org
Subject: Re: Avalon+XSLT+Mozilla = The Wobzilla-editor
Message-ID: <20031015211059.GB22593@maribor.izzy.net>
Mail-Followup-To: dev@cocoon.apache.org
References: <20031015124244.GA2237@quench>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031015124244.GA2237@quench>
User-Agent: Mutt/1.4.1i

* Christopher Kohlhaas <christopher@einfachanders.de> [2003-10-15 12:20]:

> Wobzilla is a Mozilla Application with XForms-like and also
> document-centric editing capabilities. It is written in JavaScript and
> most processing is done without server-interaction.

> Wobzilla doesn't use a XSLT-processor it just borrows the XSLT-concept and
> -syntax. In fact the Wobzilla-language is just an Avalon-configuration written
> in XSLT-syntax. This approach facilitates a very declarative and
> side-effect-free way of designing user-interfaces.

> Wobzillas components already cover a majority of the xslt 1.0
> functionality (including sorting and variables). On the editing side
> there are features like undo/redo, context-menus, tables and tree-like
> structures.

> Still in scratchpad are the following two components:

> 1. A component that integrates the mozile richtext-editor 
>    (currently no undo/redo support and some focus problems)
> 2. An active image uploading component, as in linotype.
>    (currently the server-side mechanisms is missing)

> I've also experimented with the inclusion of a midas like component
> (e.g. linotype). There's only the one drawback that the components size
> is fixed for midas.

> Wobzilla was originally intended to be a frontend for cocoon. But I
> soon got facinated by the use of XPath, DHTML and avalon on the
> client-side and focused on implementing this part of the editor.

Hello Christopher

I am adopting Cocoon to create a document management interface that
uses Mozilla and XUL as a client. I have worked with Mozilla for a
year now. Using Cocoon as a backend for your Wobzilla is a sound
choice. I've migrated to Cocoon and Java away from Perl.

You and I are among many who are jumping on Mozilla as an Open
Source implemnation of the "e-forms" concept fowarded by Adobe and
Microsoft. There are many applicaitons out there that are document
centric, that do not lend themselves to an HTML forms
implementation. These applications are specialized enough that
cross-browser is not as much of a concern, but cross-platform is
always a plus. Targeting Mozilla is wise, especially when Microsoft
has a master plan involving a product called X-Docs (similiar to
your creation.) Mozilla lets you play on Widows, Linux, and OS X.
Mozilla is difficult to find, but for the problems your application
will solve, running an installer is not too much to ask. XPI makes
distribution of the JVM and Wobzilla itself simple.

Your online demo is jaw-dropper, but to get rich functionality, you
will probably have to package your application as an XPI with
permissions to do all the naughty things the browser won't permit.

The application I am developing is similiar to yours, except that it
deploys Cocoon on the client side. Syncrhonization of documents with
the server and generation of the documents for display in Mozilla is
very simple with Cocoon/Java. This comes from much experience with
XPCOM and JavaScript. Java is more robust, easier to test, easier to
deploy. Components can move from client to server or vice versa as
performance dictates. Same with XML and XSLT.

Do you know of any similiar projects out there? Who else is creating
a Mozilla based "e-forms" application?

-- 
Javier del Gesu - delgesu@thinknola.com