You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Tim Colson <tc...@cisco.com> on 2001/07/31 16:56:38 UTC
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
Re: custom XSL struts taglib (was: Re: Taglibs decrease theseparation between designer and developer?)
Posted by Jon Brisbin <br...@ipa.net>.
> Jakarta TagLibs also have a taglib that does XSL, have you thought about
> merging your result with theirs?
no, but that's certainly an idea...i wanted a little bit different approach
than the jakarta taglib, so i just rolled my own...
> What I think is the big disadvantage with using XSL it is very complex
> to use, especially if you want to take advantage of its more powerful
> features. If designers are going to have problems understanding
> scriplets and velocity, they're not going to fair much better with XSL
> (probably worse, in fact).
although this might be true now, wysiwyg XSL editors are coming into being
as we speak (the ibm xsl editor is actually pretty neat :-)...the XML/XSL
approach and structure is why i prefer it over scriplets or custom
tags...the whole XML/XSL approach is very OO-centric, where scriptlets or
custom iterative tags are basically hold-overs from structured programming
days...of course, if it ain't broke, yada, yada ;-)
i also find a smaller code size for the same functions, as well as faster
performance in using limited xsl for certain things...especially for ejb
stuff that iterates over records...wow, a big difference ;-)
xml/xsl also makes my EJB infrastructure much more open, as i can request
the data any number of ways and use it in disparate systems and in multiple
instances, without having to code special taglibs for various things...just
a big template file with lots of little stuff in it seems easier to manage
for me than taglib classes, .tld files, etc...
> One good thing about having model data as XML, however, is that you can
> utilize the xpath to access the XML data if you don't need all the bells
> and whistles of XSL
actually i like all the bells and whistles ;-)...
it ain't for everyone, but XSL seems much closer to something my designers
in the past have understood easily...they're more intimidated when they see
a lot of '%' signs ;-) i also off-load some work from myself by using xsl
instead of taglibs, as a java programmer doesn't have to do that
part...anyone that knows xml and xsl can do that...
Jon Brisbin
www.jbrisbin.net
Re: custom XSL struts taglib (was: Re: Taglibs decrease the
separation between designer and developer?)
Posted by Calvin Yu <ca...@mindspring.com>.
Jakarta TagLibs also have a taglib that does XSL, have you thought about
merging your result with theirs?
What I think is the big disadvantage with using XSL it is very complex
to use, especially if you want to take advantage of its more powerful
features. If designers are going to have problems understanding
scriplets and velocity, they're not going to fair much better with XSL
(probably worse, in fact).
One good thing about having model data as XML, however, is that you can
utilize the xpath to access the XML data if you don't need all the bells
and whistles of XSL (fortunately Jakarta TagLib also provides a taglib
that does this).
Calvin
On 01 Aug 2001 16:10:02 -0500, Jon Brisbin wrote:
> Thought I'd put a plug in for my own custom XSL taglib I use in my STRUTS
> apps...it helps me clean up the whole scriplet/custom tag thing by letting
> me use plain 'ol XSLT templates to output my forms with pre-filled values,
> etc...from my EJB's...i also use the struts form tags and a custom property
> copier that copies things from my ejb to my form, but this is considerably
> slower than using my session bean to extract raw xml from a sql statement,
> then transform it into a list or form...
>
> this XSL tag caches the compiled stylesheet into the application scope,
> keyed on the filename...this to increase performance, which it does well...
>
> you can nest xml tags and scriptlets in the body of the tag to get dynamic
> xml (you could theoretically do a full page of xml this way, with no HTML
> whatever...i just haven't migrated that far yet to have my app do that), or
> you can get your xml from an attribute...and transform *into* an attribute,
> if you wish...
>
> i'm quite pleased with the results of incorporating my xsl into struts this
> way...this might also help some out there that would like to try it
> too...email me if you want the source code and .tld file...
>
> Jon Brisbin
> www.jbrisbin.net
> Lamar, MO
>
> ----- Original Message -----
> From: "Greg Maletic" <gr...@ZeroG.com>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, August 01, 2001 3:07 PM
> Subject: RE: Taglibs decrease the separation between designer and developer?
>
>
> > Hi, Bill--
> >
> > I completely agree that Struts Taglibs are much cleaner than the pure HTML
> > alternative, so I concur that your "select box" example is very simple and
> > nice. I love all of the Struts form input tags, all of which are a real
> > pain to implement with pure HTML and JSP.
> >
> > But I don't think I'm exaggerating very much when I say that the Struts
> > taglibs are a new language: they include tags to define variables,
> looping
> > constructs, and if-then-else constructs, none of which correspond to
> actual
> > HTML tags, and all of which I'll need to employ if I'm to completely rid
> my
> > JSPs of scriptlets. I view that as pretty much a complete language. So
> my
> > novice reaction to the Struts taglibs is that I've swapped a language that
> I
> > know (Java) for a language that I don't know (Struts taglibs), and my
> > designer has swapped a language that he knows (pure HTML) for a language
> he
> > doesn't know (Struts taglibs), at the benefit of giving the designer the
> > potential to write virtual code when I know that he--and at least 95% of
> the
> > designers I've worked with--won't write view code that I would trust no
> > matter what the language is. (I'm not claiming they're stupid. My
> > experience has been similar to Chris's earlier post, where I let them
> > control the look and feel and I write the view code.)
> >
> > I'm not saying that the Struts taglibs are useless by any stretch of the
> > imagination. But the real benefit I see with taglibs is to clean up the
> > JSPs, not usher in a new age of empowered designers capable of building
> > views with no developer assistance.
> >
> > I should have prefaced my comments by saying that I'm quite new to Struts,
> > am not an expert, so my comments should be taken in that light. I am
> > impressed with Struts and am absolutely not giving up on it. My beef
> isn't
> > so much with Struts as it is with the whole concept of taglibs being "the
> > solution" to the MVC separation problem. The only solution to this
> problem
> > is to keep business logic out of the view, period. Scriptlets don't solve
> > the problem, but I don't think taglibs do either. The only real solution
> I
> > see is developer restraint.
> >
> > --Greg
> >
> > ======================================
> > 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 <ma...@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-14409-greg.maletic=zerog.com@jakarta.apache.org
> > [mailto:struts-user-return-14409-greg.maletic=zerog.com@jakarta.apache.o
> > rg]On Behalf Of Bill Clinton
> > Sent: Wednesday, August 01, 2001 12:10 PM
> > To: struts-user@jakarta.apache.org
> > Subject: Re: Taglibs decrease the separation between designer and
> > developer?
> >
> >
> > 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:greg@ZeroG.com <ma...@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
> >
> >
custom XSL struts taglib (was: Re: Taglibs decrease the separation between designer and developer?)
Posted by Jon Brisbin <br...@ipa.net>.
Thought I'd put a plug in for my own custom XSL taglib I use in my STRUTS
apps...it helps me clean up the whole scriplet/custom tag thing by letting
me use plain 'ol XSLT templates to output my forms with pre-filled values,
etc...from my EJB's...i also use the struts form tags and a custom property
copier that copies things from my ejb to my form, but this is considerably
slower than using my session bean to extract raw xml from a sql statement,
then transform it into a list or form...
this XSL tag caches the compiled stylesheet into the application scope,
keyed on the filename...this to increase performance, which it does well...
you can nest xml tags and scriptlets in the body of the tag to get dynamic
xml (you could theoretically do a full page of xml this way, with no HTML
whatever...i just haven't migrated that far yet to have my app do that), or
you can get your xml from an attribute...and transform *into* an attribute,
if you wish...
i'm quite pleased with the results of incorporating my xsl into struts this
way...this might also help some out there that would like to try it
too...email me if you want the source code and .tld file...
Jon Brisbin
www.jbrisbin.net
Lamar, MO
----- Original Message -----
From: "Greg Maletic" <gr...@ZeroG.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, August 01, 2001 3:07 PM
Subject: RE: Taglibs decrease the separation between designer and developer?
> Hi, Bill--
>
> I completely agree that Struts Taglibs are much cleaner than the pure HTML
> alternative, so I concur that your "select box" example is very simple and
> nice. I love all of the Struts form input tags, all of which are a real
> pain to implement with pure HTML and JSP.
>
> But I don't think I'm exaggerating very much when I say that the Struts
> taglibs are a new language: they include tags to define variables,
looping
> constructs, and if-then-else constructs, none of which correspond to
actual
> HTML tags, and all of which I'll need to employ if I'm to completely rid
my
> JSPs of scriptlets. I view that as pretty much a complete language. So
my
> novice reaction to the Struts taglibs is that I've swapped a language that
I
> know (Java) for a language that I don't know (Struts taglibs), and my
> designer has swapped a language that he knows (pure HTML) for a language
he
> doesn't know (Struts taglibs), at the benefit of giving the designer the
> potential to write virtual code when I know that he--and at least 95% of
the
> designers I've worked with--won't write view code that I would trust no
> matter what the language is. (I'm not claiming they're stupid. My
> experience has been similar to Chris's earlier post, where I let them
> control the look and feel and I write the view code.)
>
> I'm not saying that the Struts taglibs are useless by any stretch of the
> imagination. But the real benefit I see with taglibs is to clean up the
> JSPs, not usher in a new age of empowered designers capable of building
> views with no developer assistance.
>
> I should have prefaced my comments by saying that I'm quite new to Struts,
> am not an expert, so my comments should be taken in that light. I am
> impressed with Struts and am absolutely not giving up on it. My beef
isn't
> so much with Struts as it is with the whole concept of taglibs being "the
> solution" to the MVC separation problem. The only solution to this
problem
> is to keep business logic out of the view, period. Scriptlets don't solve
> the problem, but I don't think taglibs do either. The only real solution
I
> see is developer restraint.
>
> --Greg
>
> ======================================
> 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 <ma...@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-14409-greg.maletic=zerog.com@jakarta.apache.org
> [mailto:struts-user-return-14409-greg.maletic=zerog.com@jakarta.apache.o
> rg]On Behalf Of Bill Clinton
> Sent: Wednesday, August 01, 2001 12:10 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Taglibs decrease the separation between designer and
> developer?
>
>
> 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:greg@ZeroG.com <ma...@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
>
>
RE: Taglibs decrease the separation between designer and developer?
Posted by Greg Maletic <gr...@ZeroG.com>.
Hi, Bill--
I completely agree that Struts Taglibs are much cleaner than the pure HTML
alternative, so I concur that your "select box" example is very simple and
nice. I love all of the Struts form input tags, all of which are a real
pain to implement with pure HTML and JSP.
But I don't think I'm exaggerating very much when I say that the Struts
taglibs are a new language: they include tags to define variables, looping
constructs, and if-then-else constructs, none of which correspond to actual
HTML tags, and all of which I'll need to employ if I'm to completely rid my
JSPs of scriptlets. I view that as pretty much a complete language. So my
novice reaction to the Struts taglibs is that I've swapped a language that I
know (Java) for a language that I don't know (Struts taglibs), and my
designer has swapped a language that he knows (pure HTML) for a language he
doesn't know (Struts taglibs), at the benefit of giving the designer the
potential to write virtual code when I know that he--and at least 95% of the
designers I've worked with--won't write view code that I would trust no
matter what the language is. (I'm not claiming they're stupid. My
experience has been similar to Chris's earlier post, where I let them
control the look and feel and I write the view code.)
I'm not saying that the Struts taglibs are useless by any stretch of the
imagination. But the real benefit I see with taglibs is to clean up the
JSPs, not usher in a new age of empowered designers capable of building
views with no developer assistance.
I should have prefaced my comments by saying that I'm quite new to Struts,
am not an expert, so my comments should be taken in that light. I am
impressed with Struts and am absolutely not giving up on it. My beef isn't
so much with Struts as it is with the whole concept of taglibs being "the
solution" to the MVC separation problem. The only solution to this problem
is to keep business logic out of the view, period. Scriptlets don't solve
the problem, but I don't think taglibs do either. The only real solution I
see is developer restraint.
--Greg
======================================
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 <ma...@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-14409-greg.maletic=zerog.com@jakarta.apache.org
[mailto:struts-user-return-14409-greg.maletic=zerog.com@jakarta.apache.o
rg]On Behalf Of Bill Clinton
Sent: Wednesday, August 01, 2001 12:10 PM
To: struts-user@jakarta.apache.org
Subject: Re: Taglibs decrease the separation between designer and
developer?
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:greg@ZeroG.com <ma...@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
Re: Taglibs decrease the separation between designer and developer?
Posted by Bill Clinton <bc...@snipermail.com>.
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:greg@ZeroG.com <ma...@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
Taglibs decrease the separation between designer and developer?
Posted by Greg Maletic <gr...@ZeroG.com>.
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 <ma...@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