struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerome Jacobsen" <jerome.jacob...@gentootech.com>
Subject RE: Tab Libraries? Bah!
Date Wed, 24 Apr 2002 20:25:21 GMT
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>


Mime
View raw message