Greg,
I think you are exagerating a bit when you say that "Struts
taglibs--and other taglibs--introduce, in essence, yet another language
that we all have to learn." Comparing a handful of scripting tags that,
for the most part, correspond directly to existing html tags to the
learning of a language is a bit much.
That said, if your designer is unable to understand struts tags, I
would recommend that you ask him not to touch them. I don't understand
why you would feel the need to teach a designer "the ins and outs" of
Struts tags. Maybe you could try something like this: design the app,
using completely stripped jsp pages. Ask your designer to do the
interface, then put the tags in his interface. If the designer needs
control of the presentation of html contained within custom tags, use
style sheets.
Also, if you honestly do feel that things were easier without
struts, don't use it. It is not a part of the servlet/jsp spec or
anything, and its use is completely optional. But I would urge you to
stick with it a little more. I think its many advantages far outweigh
the small learning curve.
One more thing, since you have experience with servlets/jsp, you
must admit that code for a select box that looks like this is a thing of
beauty: :)
<html:select property="prizeTypeId">
<html:options collection="prizeType" property="value"
labelProperty="label"/>
</html:select></td>
Bill
Greg Maletic wrote:
> 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
