on 1/14/01 3:11 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:
> "Jon Stevens" <[EMAIL PROTECTED]> wrote:
>> on 1/11/01 8:30 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
>> Let me also state that at this point in time, I see Velocity+Turbine as
>> being one of the best solutions out there.
>
> I agree it has benefits over JSP, but I do think it's still too hard for
> HTML only coders to deal with the Velocity syntax. Does an HTML person
> understand what $data.Parameters.getString($key) means? I think not. So,
> WM/Velocity is good (or at least better than JSP :-) for developing apps
> where the HTML is developed by people with Java experience - but thats
> exactly what I believe we should be heading away from.
Actually, you have missed the point entirely. I'm not expecting or even
asking designers to understand what $data.Parameters.getString($key) means,
however, I can expect them to be able to work around those fields in a page.
There are several classifications of people who are expected to work on a
web application:
#1. Designers. People who know HTML. May know some javascript. Nothing more.
#2. Template Engineers. People who know how to work with an API and
understand the template language (ie: people who understand what
$data.Parameters.getString($key) *does*, but may not understand the Java
behind it). Eventually, they may become engineers.
#3. Java Engineers. People who are responsible for developing the API and
doing the Actions.
> In contrast XMLC seems to be heading in the right direction because template
> authors need only understand (pure) HTML. Not that I'm necessarily
> recommending XMLC as a practical solution, I've never used that either...
> but I have written YATL, so I feel I have enough experience to comment.
Right, however XMLC is push based and that is bad for all the reasons
documented in my Pull document. It also has the problem of tying the HTML to
the Java code. For example, say you want to break elements of a <form>
across several pages. If you can't do that without editing Java code on the
back end, that is bad because then you have to pay java engineers to make
the changes that template engineers should be able to do.
> Hey Jon, come on, I know it's your baby, I don't want a flame war - I'm only
> interested in the theoretical issues.
It wasn't a flame war. It really saddens me to always be guilty before being
proven innocent. Quit thinking that I'm always trying to start a flame war.
This is a conversation and if I don't agree with something, that isn't a
flame...that is me stating an opinion. I spent a bunch of time coming up
with valid reasons why other technologies are sorely lacking. At least you
could do the same.
-jon
--
Honk if you love peace and quiet.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
