Very interesting.

Since these appear to be 'competing technologies' I see you have chosen
Struts over barracuda.  There was a long comparison on the enhydra site
which paints XMLC in a good light, but without a detailed investingation
doesn't mean much.

My questions are:

        1) Are the technogolies incompatible (or at least the off the
shelf version)?
        2) How much control to you get of the client or are you force to
manipulate it through a filtering layer?
        3) How good are the controls it generates?

Thanks in advance.


-----Original Message-----
From: Andrew Hill [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, November 24, 2002 10:40 PM
To: Struts Developers List
Subject: RE: Velocity vs. JSP: objective tests?

A DOM based rendering methodology might be more appropriate for this
sort of thing.

For example the home baked view technology Im using with my struts app
is based around the idea of giving each page a 'layout' - this is just
an xhtml file - or several actually since I tend have have some shared
templating type stuff going on, and the dynamic content is inserted into
the DOM by Java code.

Some neat side effects of this are that one can modify the xhtml to
quite an extent (or pass it on to ones website guru to make it look
great) - without changing the code that renders the dynamic stuff (such
as field values, menus etc..) There is a much stronger seperation
between layout and content this way, which imho is a 'good thing'.
Obviously the html dude and the designer have to agree on things like
how to identify nodes (ie: which values to use for 'id' attributes for
the most part) but it means that the two don't step on each others toes
half as much as can happen with JSP. It also means one can do neat
tricks like having several different layouts
(skins) for ones pages and choosing from these at runtime - without
having to replicate the code that renders the dynamic content in each
one. Being able to randomly access any part of the page from the
rendering code is also very useful. For example its a breeze to apply
the decorator pattern to ones output - such as hunting for all <a
hef=... to modify the links in some way etc...

This isn't a novel approach. My stuff is heavily inspired by XMLC -
which is the view technology used by the Barracuda framework. See and
XLMC is an interesting beastie. Instead of reading the DOMS from html
files at runtime using a parser, it is used to create a class that
contains the code that will build the DOM for you (not unlike the
concept of JSPs being compiled to java servlets). I gather it can be
setup to do this at runtime as well and you can drop in an html file and
it will rebuild and reload the class. (These classes have a method that
returns the DOM which can be manipulated using the org.w3c.dom classes
or with a whole bunch of convienience methods XMLC provides). </btw>

-----Original Message-----
From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Johnson
Sent: Saturday, November 23, 2002 06:53
Subject: Re: Velocity vs. JSP: objective tests?

David Graham wrote:

> I've always found it amusing that people are worried about page 
> authors totally screwing up the application by executing arbitrary 
> code.  Who are these rogue page authors you're hiring that will 
> destroy your app?

What if, for example, you have an e-Commerce catalog and you want to
allow ordinary users to edit the catalog item page templates through a
web interface. If you Do you really want ordinary catalog users to be
able to execute arbitrary code from these page templates? I don't think
so. Using JSP for the user-editable page templates is really not an
option in this case. Wouldn't you agree?

- Dave

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to