"Jon Stevens" <[EMAIL PROTECTED]> wrote:
> 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.
[snip]
> > 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.
Seems to me that your argument rests on the assumption that there exists
such a beast as a "template engineer" - someone who is skilled in HTML and
who understands coding without ever having had formal programming training.
Call me traditionalist, but having coding done by non-coders is a recipe for
disaster. For example, I think that a template engineer who was capable of
rewriting templates to split a form across several pages would probably be
worth paying as much as a Java coder anyway. For example, you can easily
hire a qualified HTML coder or a Java coder, but it's pretty difficult to
hire a qualified "template author", especially when you want them to know
your own flavour of YATL.
Saying all that I'm sure if you set up your organisation with these three
classes of developers it would work. It's simply a question of which way
would be more efficient overall. I favour the 2 role way, you the 3 role
way.
> > 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.
Aw, chill out man! You just come across as, er, quite opinionated, thats why
people always get the wrong impression. I've been hanging around this scene
for long enough to appreciate the way you do stuff... without getting _too_
upset :-) Certainly no need for any paranioa ... :-)
> I spent a bunch of time coming up
> with valid reasons why other technologies are sorely lacking. At least you
> could do the same.
I think I am! :-)
Cheers
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
