XMLC Comments Plus Velocity XMLEasyBean

[Terry Steichen <te...@net-frame.com>]

David,

I apologize for the delay in responding to your questions - but because you moved this discussion thread from the Enhydra list, I didn't get notified of your message (because I don't subscribe to this XMLC list), only learning of it by accident when I just checked the XMLC message archives.

What I actually said in my message to David Li was that 'all but the simplest changes require programmers' assistance with XMLC.  This is not conjecture on my part - it was readily acknowledged by Lutris' own Bill Karwin (http://enhydra.enhydra.org/project/mailingLists/enhydra/200110/msg00034.html) and Mark Diekhaus (http://enhydra.enhydra.org/project/mailingLists/enhydra/200110/msg00036.html).  They both acknowledged that XMLC is designed for programmers, not designers.  The simple fact is that, with XMLC, it is *very* easy to make minor changes in layout (though recompilation is required, of course).  But to go beyond that requires not just Java, but DOM/XMLC Java, which involves more than trivial Java programming skills.

The autocompilation feature you mention is great - but it, of course, pre-supposes that the programmer wrote the stuff correctly in the first place.

Like you, I too would be very interested in Lutris/XMLC reactions to Velocity's (more correctly, Geir Magnusson's) XMLEasyBean.  It seems able to do what the combination of XMLC and XSLT can do, but with one (quite simple) engine (which, BTW, works very nicely and easily with Enhydra) and excellent separation of programmer/designer roles.

Regards,

Terry

PS: I posted this back to the original Enhydra list because I think it has general relevance and I didn't want to cross-post.

==== On October 23, 2001, David Young said:

Hi Terry,
I've moved this back to xmlc.enhydra.org where it belongs...

I'm curious about your "simplest changes require programmers" comment.
We've been able to easily set up ASP customers in the past with the
ability to make changes to HTML, using GoLive or Dreamweaver to
rework presentation markup, moving the ID attributes around,etc ... then
Enhydra auto compiles and loads the new DOM templates.

I'm also curious if Christian Cryder has any comments on the XMLEasyBean
feature in Velocity...

David

Terry Steichen wrote:

> David,
>
> A couple of thoughts (==>) below.
>
> Regards,
>
> Terry
>
> > The following list both advantages and disadvantages of each technology.
> >
> >    JSP pros:
> >      - Simple to write for simple dynamic presentation
> >      - Easy syntax
> >      - taglib, jsp:include for module reuse
> ==> - widespread use and documentation (defacto standard?)
>
> >
> >    JSP cons:
> >      - Break the original html pages while codes are inserted
> >      - Require special support from Web authoring tools
> >      - Blur the division of labor of Web designer and programmer
> ==> (worse than 'blur' - requires code in layout)
> ==> - Very difficult to quickly visualize/follow logic of all but simplest
> page.
>
> >
> >    XMLC pros:
> >      - High level abstraction of the *ml pages in DOM and Java objects
> >      - Original pages are lefe intact, thus good authoring tool support
> >      - Clear division between Web designers and programmers
> >      - We love it! ;)
> >
> >    XMLC cons:
> >      - W3C DOM API are hard to use
> >      - Weak template supports
> >      - Do not address the structure of the manipulation codes
> ==> - programmers required for other than simplest page changes
>
> >
> > XSP comes to rescue:
> >
> > II. A XSP example
> --snipped stuff ----
> >    *1: executeOn is not officially in the spec.
> >    *2: document is a context object provide by the runtime pointing
> >        to the page objects
> >    *3: like JSP, the java codes on the page is compiled into Java
> >        and executed
> ==> Have you looked at Velocity/WebMacro?  I think they already do all this
> (except that they are not compiled per se).  You might take a special look
> at XMLEasyBean - converts XML file to DOM and then allows (Velocity)
> template-level manipulation (including conversion to HTML, WML, XYZ).
>
> _______________________________________________
> Enhydra mailing list
> Enhydra@enhydra.org
> http://www.enhydra.org/mailman/listinfo.cgi/enhydra