I have to say that I have been reading every response in this thread and
find it to be one of the more interesting discussions I've heard in a while.
Choosing the right framework for a project is, in my opinion, the most
critical aspect in any implementation. I think it would be nice to have a
more formal presentation of some of the ideas expressed here. If anyone has
any good reference material (books, sites, etc) dealing with this subject
I'd be very interested to look at them.
Thanks.
John
-----Original Message-----
From: Joni Suominen <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Saturday, April 28, 2001 7:10 AM
Subject: Re: MVC/XML Framework Comments please
>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]
>
