Pier Fumagalli wrote: >I believe that Andy doesn't quite know what "templates" are ! :-) Dude, >we're not talking about the beauty of XML around here, but stuff that >Macromedia DreamWeaver can parse and (somehow) render! :-) > In my shop we've gone our own way, with our own templating sytem targetting Dreamweaver users specifically. Its been our experience that web designers shouldn't write jsps, but that servlet writers should, because it makes their html errors easier to fix. So, for the last year we'd automated conversion of the static mockups the web designers do into jsps using the struts taglibs, with hooks to allow replacement of links to static pages by links to struts actions, and so on. Active portions of the pages were developed as jsp's that got included by the struts template library (we identified replaceable chunks using id attributes, similarly to xmlc). The code to do this was written in house as an ant task, and took about 10 man days.
Over the course of time the amount of static content has come to dominate and the speed of the jsps had become an issue. We originally converted to jsps because it would allow the developers to fix up any conversion problems quickly, but in fact this rarely if ever happened. Also, we didn't make enough use of the fact that the web designers developed using their own templating system (the .dwt/.lbi sytem in dreamweaver). So now we're doing the same static-dynamic conversion on the fly, replacing DreamWeaver's .dwt template #BeginEditable... and #BeginLibraryItem... sections instead of the id-attributed elements we used before. The whole thing is now data-driven rather than compiled, and is much faster than the old jsps. The java developers do the rump of the code that needs to be dynamic, using the same included jsps; but there are far, far fewer jsps in the sites now - 125 instead of 1154 in one of them. Its much faster than the jsps, and has taken all of the static content out of the webapp. I've never been that happy with templating languages - they just seem to shift the problem from html-in-code to code-in-html. By using struts and driving the look from a static site we have very little of either. The closest things to what we're doing I could find were xmlc and jdynamite[1]. xmlc was a no-go area for us because of its use of jtidy - the html emitted is not the html you put in; and our approach needed less coding than jdynamite, partly since the chunks we replace with dynamic code are quite coarse. I've tried the xml/xsl-based site thing too, in another company - it made some sense there because they had wml and webtv sites on top of the html ones (25 sites in all, all based off the same content). However it was dog slow (the xalan compiler wasn't out yet) and there aren't enough folk competent in xsl to maintain stuff like that. Its horses for courses though. We have a marketing-driven website, with a lot of mainly-static content, which needs to be reskinned for deployment with many customers. On the other hand we also develop an intranet application - which is essentially a standard GUI app but deployed over the web - where something like Tapestry would be more appropriate, as the developers are much more involved in the GUI. -Baz [1]http://jdynamite.sourceforge.net/doc/jdynamite_sf.html Privacy and Confidentiality Notice ------------------------------------------------ The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
