Your post brings up a good point concerning what I think is a false
assumption concerning the separation between designer and developer.
Despite the potential good uses that taglibs can be put to, HTML pages with
JSP scriptlets are, I believe, easier to read by web designers than pages
with Struts taglibs. (The one caveat being the one I mentioned before--that
ONLY view logic--and not business logic--should reside in scriptlets.) My
reasoning--and experience--is that when I simply used JSPs, I told our
designer to completely ignore the stuff inside the "<% %>"s and code around
them. Things were fine.
Now that we're using Struts, I have to instruct our designer on the ins and
outs of a completely new set of pseudo-HTML tags that he doesn't understand
at all--and NOT to use the tags he's familiar with ("<form>", "<head>",
etc.)
It was much easier for both him and me before we made this switch. Struts
taglibs--and other taglibs--introduce, in essence, yet another language that
we all have to learn.
======================================
Greg Maletic
Chief Technical Officer
Zero G Software, Inc.
514 Bryant Street
San Francisco, CA 94107
tel: +1.415.512.7771 x303
fax: +1.415.723.7244
mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
http://www.ZeroG.com <http://www.ZeroG.com>
The leading provider of multi-platform software deployment solutions.
======================================
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg]On Behalf Of Tim Colson
Sent: Tuesday, July 31, 2001 7:57 AM
To: [EMAIL PROTECTED]
Subject: HTML in Taglibs (was: some comparision between JSP/struts &
velocity)
Niall wrote:
> Sorry, I couldnt disagree with you more.
> Custom tags are exactly the place to put html - they are part of the view,
Heh heh... I never said definitively that they weren't, just that in the
particular situation we had - it seemed like a bad idea. The bits in
question were definitively Designer territory.
BTW - you are correct when saying this was/is part of the View. However,
part of the separation I'm striving for is between Designer and Developer
roles. And I hope you'll agree with me that a TagLib isn't something a
Designer would likely build. <grin>
> if you look at struts html tags thats what they do.
Yes. I understand. And honestly, it makes me a trifle uneasy. ;-)
Real example - I had a Designer chap get stumped because the html:form
attribute "name" didn't actually map directly to the "name" of the "real
html form". When he tried to connect a javascript function to an element in
the form - he didn't know the name of the form. When he reasoned, "oh, I'll
just name my html:form 'bleckfoo', just like I would if it was standard
HTML... <html:form name="bleckfoo"... He got a lovely error similar to the
following:
> Error Location: Edit.jsp Internal Servlet Error:
> javax.servlet.ServletException: Must specify type attribute if name is
specified
> at org.apache.jasper.runtime.PageContextImpl.handlePageException
> (PageContextImpl.java:459)
> at jsp._0002fjsp_0002fEdit_0002ejspEdit_jsp_2._jspService
> (_0002fjsp_0002fEdit_0002ejspEdit_jsp_2.java:344)
(That was a fun one to explain - lemme tell ya. <grin> ;-)
My point - hiding complexity won't always make things simpler.
To my Designer colleague, the fact that the <html:form automagically
associates a Form bean with the form elements, as well as doing other nifty
things for him/her behind the scenes didn't matter. What mattered was that
they knew how to do HTML, and they were stumped about how to make this
"Struts thingy" work.
To which I have to reassure him that "Struts" is a good thing - it's the
darn JSP's that are a bit cumbersome. ;-)
Cheers,
Tim
