Cory Updyke wrote:
>
> My issue with XML/XSL transformations is this: My theory for the
> presentation tier is to keep it as simple as possible. Occasionally, you
> find a designer who has every right to be a engineer, but designs because
> they enjoy it. This person will scoff(sp?) at the simplicity of XSL. Most
> of the time you will find designers who know HTML (PDF, etc.). Which
> concept is closer to HTML, XML/XSL or JSP? I think JSP. I also have found
> it easier to say "Do you see the green (or whatever color depending upon
> your IDE) colored text? Please don't delete that" than it is to teach
> someone the concept behind XSL. You can have a good hour conversation, hand
> them the JSP Syntax Reference document and say DESIGN good man.
I totally agree! Some years ago (before JSP) we implemented an XML based
publishing system. We used our own template language which was a
simplified version of XSL. The platform was techinically excellent and
contained more than 150.000 lines of Java code. We had a very complex
layered caching mechanism: cache for data objects, cache for XML data
sources, cache for precompiled templates, cache for generated HTML
snippets etc. The bad news for us came later. The system was a way too
complex for our designers and HTML coders! It took relatively long time
to do simple things. In other words, we went too far with the
abstraction.
> Anyway... enough talk... we use Struts and our own Model-2-Brew.
That's what we do also nowdays. We use Struts with some own add ons
which allow us to configure the caching policies and access control
lists for each action in struts-config.xml. Business objects and
processes are without an exception implemented as EJBs.
Joni
[EMAIL PROTECTED]
