struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Tab Libraries? Bah!
Date Wed, 24 Apr 2002 21:08:55 GMT


On Wed, 24 Apr 2002, Joe Osowski wrote:

> Date: Wed, 24 Apr 2002 16:34:43 -0400
> From: Joe Osowski <josowski@fulltilt.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: 'Struts Users Mailing List' <struts-user@jakarta.apache.org>
> Subject: RE: Tab Libraries? Bah!
>
> <snip>
> The "solution" to avoid scriptlets is custom tags.  But to avoid scriptlets
> most custom Tags *must* include HTML.  Thus your Java web developer is
> writing HTML in custom Tags which breaks the seperation of concerns between
> the Java web developer and the HTML designer (JSP writer).
> </snip>
>
> Basically this is broader debate about separation of Interface and Business
> / programming Logic.  Its like separation of church and state... it works
> well in theory. :-)
>

At the end of the day, *somebody* has to ultimately render HTML if a web
browser is your client -- whether it is the page developer writing it by
hand or some dynamic component that is doing part of the rendering for
you.  Whether it's JSP or not is hardly the issue.

Personally, I'd much rather have my page designers learn one custom tag
that does a bunch of the grunt work for you rather than having to
tediously code that same work by hand every time they need that kind of
output.

For example, folks using Struts tags like <html:link> don't have to worry
about:
* URL rewriting so sessions work even without cookies.
* Resolving application-relative URLs so that they work no matter
  what the context path is (and what sub-app you are in if you
  are using Struts 1.1).
* Dynamically assembling query string parameters for the request URL,
  complete with URL encoding of special characters embedded in those
  values.

Doing this kind of stuff requires some dynamic processing somewhere.  If
you consider rendering HTML in tags is evil, feel free to code <a> tags by
hand ... but don't come to me when a session gets dropped on a cookie-less
client because the page developer forgot to URL rewrite on one link out of
the hundreds in your app :-).

Craig


>
> ----Original Message-----
> From: Jerome Jacobsen [mailto:jerome.jacobsen@gentootech.com]
> Sent: Wednesday, April 24, 2002 4:25 PM
> To: Struts Users Mailing List
> Subject: RE: Tab Libraries? Bah!
>
>
> IMHO JSP and technologies like it are fundamentally flawed.  However, I have
> not tried out other Java dynamic web presentation frameworks/technologies.
>
> Enhydra's (http://www.enhydra.org/) architecture sounds promising.  As I
> understand it the HTML designer writes HTML.  The Java web developer writes
> the code to add the dynamic content to the HTML by manipulating the HTML's
> DOM.  The DOM manipulation code looks for class attributes agreed on between
> the HTML designer and Java web developer.  That's all I know.  Not sure if
> HTML 'includes' would be supported, which is something I'd like.
>
> I've also read about Echo (http://www.nextapp.com/products/echo/).  It is
> NOT designed to seperate concerns between the HTML designer and the Java web
> developer.  What it claims to do is make web development (targeted for HTML)
> like doing typical MVC, such as developing a Swing application.  It looks
> too beta right now.  No i18n support.
>
> WHAT I HATE ABOUT JSPS:
>
> You can't do JSPs for dynamic sites without including scriptlets unless you
> code tons of custom Tags.  The design idea behind JSPs was that it look like
> XML and not include Java.  That the JSP writer does not have to know Java.
> The "solution" to avoid scriptlets is custom tags.  But to avoid scriptlets
> most custom Tags *must* include HTML.  Thus your Java web developer is
> writing HTML in custom Tags which breaks the seperation of concerns between
> the Java web developer and the HTML designer (JSP writer).
>
> Let's say you can accept the fact that the JSP writer is the same person as
> the custom tag writer/Java web developer.  Then the seperation of concerns
> problem with JSP is not an issue.  But the JSP solution still results in a
> maintenance nightmare.  Scriptlets in JSPs are ugly and the resulting JSPs
> are very difficult to maintain.  On the other hand coding huge custom tag
> libraries to get around scriptlets is a maintenance nightmare and very
> tedious.  In either case there is typically a huge amount of presentation
> Java Beans to code.  Finally, because of stateless HTTP the amount of
> plumbing still required of the developer with Struts to do most dynamic webs
> is large: the Action classes.  The coupling between the Java Beans, Action
> classes, JSPs, and custom Tags is typically tight.  What we want in the case
> where seperation of concerns is not an issue is something like Echo (see
> above).  That is, plain old MVC.
>
> Maybe Java Server Faces will provide an adequate solution?
>
> So why use Struts?
> - Because you get the benefits of a framework, despite the major
> shortcomings of JSP.  The Struts framework already has support for Web
> development plumbing such as Security, i18n, and validation.  You don't have
> to use the presentation layer of  Struts to benefit from the framework.
> - There is a large user base.
> - Struts is covered in many articles and books.
>
> Sorry for the rant.
>
> -----Original Message-----
> From: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
> Sent: Wednesday, April 24, 2002 3:24 PM
> To: Struts Users Mailing List
> Subject: Re: Tab Libraries? Bah!
>
>
>
>
>
> I've come to the following conclusions:
>
>  - If Struts tries "to take the programmer out of the equation" completely,
> it will become an inferior solution.
>
>  - Other page development languages (Cold Fusion, ASP, JSP even) provide
> actual scripting languages with:
>      - Variable definition
>      - String manipulation functions
>      - Looping constructs that don't need to be tied to objects (or
> collections in objects)
>      - Other things that give the page developer power to create dynamic
> pages
>
> I don't believe that Struts can (or should, really) provide all these
> things. Yet these things become very handy when building dynamic pages.
>
> If you tell a page developer (and I have) that they need to leave one of
> the more powerful development languages that I described to use Struts,
> there are problems:
>
>  - The page developer has less flexibility than they used to have
>  - The page developer can contribute less to the project - they are used to
> having a more powerful language.
>
> So the only answer I can practically think of is to still allow some
> mixture of scriptlets. I think eliminating them all is a mistake - I tried
> it.
>
> So then, the real question is how - or where - do you draw the line?
>
> Asking page designers to become Java programmers is a problem. Giving them
> only Struts is a problem.
>
> Where is the middle ground?
>
> FWIW -
> Kevin
>
>
>
>
>
>
>
>
> Joe Osowski <josowski@fulltilt.com> on 04/24/2002 03:14:50 PM
>
> Please respond to "Struts Users Mailing List"
>       <struts-user@jakarta.apache.org>
>
> To:   "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
> cc:
> Subject:  Tab Libraries?  Bah!
>
>
> <bitchSession>
> This kind of thing has really bothered me about Tag libs.  The whole point
> of them is to keep HTML code as simple and clean as possible right?
>
> But if you have to break down and use the <%%> snippets inline, does it not
> make the whole process self defeating?  In my mind using <%%> snippets and
> tag libraries is more confusing then just using snippets alone, spaghetti
> code be damned.
>
> We're trying to take the programmer out of the equation, but as long as the
> tag libraries are implemented half ass, your not going to do anything but
> make the whole process more confusing and frustrating.
>
> </bitchSession>
>
> Thoughts?
>
>
> -----Original Message-----
> From: Galbreath, Mark [mailto:Galbreath@tessco.com]
> Sent: Wednesday, April 24, 2002 2:44 PM
> To: 'Struts Users Mailing List'
> Subject: RE: html:select how to use it?
>
>
> Here's a simple example of how I retrieve a List of years to populate a
> dropdown list:
>
> <html:select property="ccExpYear" styleId="ccExpYear">
>   <html:option value="0">Year</html:option>
>   <logic:iterate id="expYear" name="listExpYears" scope="session">
>     <html:option value="<%= ( String) expYear %>">
>        <%= expYear %>
>     </html:option>
>   </logic:iterate>
> </html:select>
>
> 1.  The html:select property is a property in your bean, if one exists.
> 2.  styleId is just the HTML reference if you want to get a value with, say
> JavaScript.
> 3.  The first html:option is the default "selected" option that displays.
> 4.  The logic:iterate id is arbitrary but required to reference the list's
> elements.
> 5.  iterate name is the name of my ArrayList of years that I assigned to a
> session
>     attribute in my action class:
>
>    List listExpYears = new ArrayList();
>    for( int k = 1; k < 11; k++) {
>          listExpYears.add(( new Integer( 2000 +
>              Calendar.getInstance().YEAR + k))
>              .toString());
>    }
>    request.getSession().setAttribute(
>          "listExpYears", listExpYears);
>
> 6. In html:option value, remember to cast the List objects to strings as
> Struts is expecting a string.
>
> Easy as pie, eh?
>
> Mark
>
> -----Original Message-----
> From: Roshan Paiva [mailto:roshanp@erunway.com]
> Sent: Wednesday, April 24, 2002 3:17 PM
>
> > Hi...
> >
> > Could anyone pls tell me how to populate a dropdown list using struts
> > tag libraries.
> >
> > I have an arraylist of databeans.. The dropdown list should skim
> > through each item in the arraylist and take the value of
> > databean.getFirstValue() (or the firstValue property of the data
> > bean). I believe the tag is html:select. However I am not certain on
> > how to use it.
> >
> > Kind Regards
> > Roshan
> >
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <
> mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <
> mailto:struts-user-help@jakarta.apache.org>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------------
> This e-mail message (including attachments, if any) is intended for the use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt from
> disclosure.  If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
> ---------------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message