struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kusch, John" <John.Ku...@KRAFT.COM>
Subject RE: Taglibs decrease the separation between designer and develope r? (A designer's perspective)
Date Wed, 01 Aug 2001 17:32:14 GMT
As a designer, what I love about Struts is that, once you learn the taglibs,
you don't *need* the back-end programmers to put any code in the JSP's at
all.  As long as they're working closely with you on the behavioral
requirements of the app and accurately documenting their beans (i.e., which
beans contain which properties), the designer has full control over the
presentation of information, without having to "ignore" any code at all.
Granted, it does involve learning an entirely new set of tags, but at least
they're tags that resemble HTML, as opposed to raw JSP code.

I think that if a designer is armed with an undestanding of the Struts
taglibs, and is working with a developer who has solid communications
skills, Struts creates a working environment where the developer doesn't
have to muck around in JSP's, and the designer doesn't have to "ignore"
code.

In short, if you take the time to make sure the designer understands the
taglibs, you'll be free to focus on back-end development and let the
designer focus on presentation.  Hence, increased separation --- with a
little training.

--John Kusch

-----Original Message-----
From: Greg Maletic [mailto:greg.maletic@ZeroG.com]
Sent: Wednesday, August 01, 2001 12:15 PM
To: struts-user@jakarta.apache.org
Subject: Taglibs decrease the separation between designer and developer?


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:greg@ZeroG.com <mailto:greg@ZeroG.com>
http://www.ZeroG.com <http://www.ZeroG.com>

The leading provider of multi-platform software deployment solutions.
======================================


-----Original Message-----
From: struts-user-return-14335-greg.maletic=zerog.com@jakarta.apache.org
[mailto:struts-user-return-14335-greg.maletic=zerog.com@jakarta.apache.o
rg]On Behalf Of Tim Colson
Sent: Tuesday, July 31, 2001 7:57 AM
To: struts-user@jakarta.apache.org
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






Mime
View raw message