on 1/14/01 5:34 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:
> 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.
Actually, we have several TE's working for us at CollabNet and several of
our clients also "supply" people with these skills to work with us.
> 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.
I agree, that is a traditionalist point of view. That is why I'm working
hard to come up with solutions to break that POV and smash it to shreds.
We are getting very close over in Turbine/Velocity land. There is one last
major thing to do which John McNally is working on...automatic handling and
generation of the objects which represent the <form>. In other words, we
want to be able to define the business logic for our forms in a .xml file
and then auto-generate Java code as needed to deal with handling of the
forms. Think Object-Relational tool not for RDBMS, but for <FORMS>! :-) Even
cooler is that this will be tied into the OR definitions in order to define
things like the maxlength of a form input text field based on the size of
the column definition. We will also support things like auto-populating of
the form data when the page is redisplayed due to an error or in the case
where we are re-displaying the page to show previously entered data.
This isn't anything really "new"...however, it is fairly new in the context
of Java App Frameworks that are OSS as well as being implemented within the
idea of the 100% pull paradigm.
If you would like to be part of this, we welcome you to subscribe to the
Turbine list and start discussing it.
> 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.
Right, let me repeat what I'm hearing you say: in the 2 role way, you would
have a designer and an java engineer. In that case, that is fine as well,
the java engineer would simply be responsible for the template engineer's
job.
In CollabNet's case though, we have clients which may be "web savvy" enough
to be able to learn enough template language and API's (although maybe not
savvy enough to learn Java) and we need to be able to give them a way to
edit/modify their sites that we create for them without having to have us
involved all the time. In other words, we need to be able to scale our
business without having to hire huge teams of engineers to support our ever
growing client base.
> 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 agree. I'm very opinionated. I'm also glad there is someone like
me...otherwise, we would all continue to sit around the table looking silly
at each other at dinner with nothing to say! :-)
thanks,
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
