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

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

This isn't a novel approach. My stuff is heavily inspired by XMLC - which is
the view technology used by the Barracuda framework. See
http://xmlc.enhydra.org/index.html and http://barracuda.enhydra.org/
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).

-----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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

Reply via email to