Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Message-ID: <38EFEF8B.DBD3EE06@lutris.com>
Date: Sat, 08 Apr 2000 19:48:43 -0700
From: "David H. Young" <david.young@lutris.com>
Reply-To: david.young@lutris.com
MIME-Version: 1.0
To: cocoon-users@xml.apache.org
Subject: Re: Enhydra vs Cocoon
References: <Pine.LNX.4.20.0004071907120.13688-100000@pvl.pvl.at>
 <00040814392401.23724@dsl-64-34-44-253>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I don't know if anybody from enhydra.org has spoke up before here,
so let me take a stab at explaining the design center behind Enhydra
XMLC, one of the many technologies included in the Open Source
Enhydra Java/XML application server...

The #1 goal was to address the product lifecycle problems created by
embedding Java or any other structured language inside a mark-up language:
difficult-to-maintain presentations that required technical expertise to
change.  We (Lutris) as consultants wanted our HTML designers to
focus on HTML design and not Java development.  So we came up
with a way to leverage HTML/XML attributes to isolate areas of HTML
created dynamically, such as a table of customers.  XMLC fixed a bunch
of things.  First, the HTML code just became a resource of Java.  It put
Java in full control of the flow of the presentation, rather than HTML
dictating flow with Java inserted where needed.  Second, it became
much easier to work with 3rd party HTML designers because the only
handshake required was to agree on the ID names, such as
"DustomerName", in the string <TD ID=CustomerName>John Doe</TD>.

Thirdly, one could leave mocked up data, such as a mocked up table,
to be removed automatically at compile time or during
runtime exection.  That meant only one "truth" document was required.
rather than maintaining two parallel documents (one without embedded
Java code, the other with embedded Java code).  So, the work flow goes
something like... the HTML or WML designer creates a template, using
mocked up data and all, inserting the agreed-upon ID attributes to identify
areas of dynamic content.  The Java developer takes the document and
compiles it into a DOM with xmlc which creates the java class, with
accessor functions automatically created to access nodes based on the id
names, such as htmlDocument.setTextCustomerName( ).  Enhydra will
perform automatic compilation if the html/wml/xml document has been
altered since a previous compilation.

XMLC's design strategy means that the programmer can stick to Java for
manipulating the DOM (except when inserting JavaScript, usually to
perform client-side validation checks).  There's little need for scripting,
which is really another form of embedding a programming language.
With enhydra xmlc you don't need XSL editors and because there are
_no_ HTML tags introduced, it works with any HTML editor.

As always, it comes down to picking your poison.  And figuring out the
nature of your project, the capabilities of your team and how you allocate
different groups to different parts of the project.

David

Ed Knutson wrote:

> On Fri, 07 Apr 2000, Roman Seidl wrote:
> > On Fri, 7 Apr 2000, Ed Knutson wrote:
> >
> > > So the question to ask is: am I trying to publish documents or build
> > > applications?
> > What if you build applications that publish documnets?
>
> In that case, go with Cocoon unless you know it doesn't support something you
> need.  Most of the work is already done, even if you do have to "hack"
> it now and then.  Use Enhydra to do things Cocoon can't do.  Otherwise, why
> reinvent the wheel?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org

--
David H. Young
Chief Evangelist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 200
Santa Cruz, CA 95060 USA
831.460.7310; 831.471.9754 (fax)
http://www.lutris.com
http://www.enhydra.org