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... <btw> 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). </btw> -----Original Message----- From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Johnson Sent: Saturday, November 23, 2002 06:53 To: [EMAIL PROTECTED] 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]>
