tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renick, Garrel" <>
Subject RE: Non Java Developers, programmers using JSTL and taglibs
Date Tue, 04 Feb 2003 22:41:59 GMT

If I were managing the group, my decision would be based 
on the abilities of "Philippe" (page designer) and "Mike" 
(the server-side engineer). If the page designer was part 
of the team and had an interest in the technology, 
I would try to get him to embrace JSTL and go for it. Have 
him spend some time with the engineer and prototype the site;
perhaps determine where they need each other's help. I don't 
think it would be much of a stretch if the page designer 
has some experience with basic programming principles and is 
willing to read and experiment (and stuggle at times). 
In the end, the whole team will be better off since Phillipe 
might be able to complete some of those "easy" requests while 
Mike is away designing back-end systems and business logic.

If Mike the engineer has an attitude and doesn't want to 
help Phillipe when he gets stuck, or Phillipe prefers Photoshop 
to working with a webapp, forget it and let Mike integrate 
the dynamic work into Phillipe's static designs.

Garrel Renick

-----Original Message-----
From: Pierre Delisle []
Sent: Tuesday, February 04, 2003 3:52 PM
Subject: Re: Non Java Developers, programmers using JSTL and taglibs

"Renick, Garrel" wrote:
> This is an interesting topic, and people obviously have
> strong opinions about successes and failures at using
> this technology within their work environments.
> My viewpoint is that JSTL provides a nice set of
> features that most page designers with some programming
> experience will be able to use, especially
> if they spend the time to learn about the web
> application environment (request/response, scope, etc.)
> and get a good reference like Manning's "JSTL in Action".
> Many work environments need web applications for simple
> tasks of presenting dynamic data, and JSTL is
> perfect for that. As the designers become more familiar
> with the technology, they can move on to more sophisticated
> projects that use frameworks such as Struts.
> I think part of the problem with this discussion is the notion
> that team members fit nicely in roles such as developer,
> page designer, and graphics artist. Jeez, the original poster
> even differentiated himself (the 'developer') from programmers and
> that distinction baffles me. I would guess that few shops have staff
> that fit so nicely into these roles, but instead there is a blending
> of disciplines and each staff member has one or more specialties.
> I have programming experience in other languages and web design experience,
> but I don't have the entire Java API under my belt (yet). For people
> like me that constantly deal with the view aspect of a project but
> also have some programming experience, JSTL offers a nice standards-based
> middle-ground where I can contribute. Conversely, if I was a pure graphics
> artist without programming experience, then I would have no interest in
> learning JSTL, even if it does look like HTML, and you'd be a fool to
> think that voila!, I could instantly understand the techniques for
> using JSTL to accomplish some tasks.

However, what would be, in your opinion, the best approach in a situation where 
a company requires a "Philippe" (graphics-artist/page-designer) to design 
a dynamic web site that is appealing and easy to use? Something, Mike, 
the server-side engineer is definitely not qualified to do even though he
can crank html very quickly (we're talking usability here ;-)

How much of a stretch is it to get Philippe (assuming typical knowledge of 
JavaScript a designer would have) to use JSTL so he can have full control
over the pages of the website?

Or is it simply easier to just forget about training Philippe, and
have Mike integrate the dynamic portions with the static designs
of Philippe, and go back and forth between the two.

Is it a tool issue?

Just curious... Trying to get as many data points as possible...

    -- Pierre

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message