tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Schneider <k...@dotech.com>
Subject Re: jsp versus xml syntax
Date Wed, 15 Jan 2003 03:43:38 GMT
Personally, I'm not convinced, but we all have our preferences. See 
inline comments on a couple of the technical issues.

Tolles, James wrote:
> I've just completed a long grueling year of jsp projects ( 3 total ), and frankly, I'm
fed up with tags. I love struts - the action dispatcher, and the templates;  but you can throw
the custom tag libraries in the dumpster. As it is now, if I have to go to some code to do
maintenance, I'm relieved to see scriptlets instead of tags.
> 
> Certainly, a jsp project can get corrupted with business logic mixed in with pagelayout,
but, Struts does an excellent job, a vital job, of helping out here.(Struts ought to be an
industry standard)
> 
> Maybe its because we don't have separate html/page layout people. In that case maybe
its more important to have only tags.
> 
> Here are a couple of points:
> 
>   - There are too many different tags : jsp tags, struts tags, struts 1.1 tags, and now
jstl tags, and of course custom tag libraries. In this example, seems like the scriptlet is
easy to understand than the jsp tag:
>    <%= customer.getName() %>
>    <jsp:getProperty name="customer" property="name"/>
> Aren't there enough syntaxes and concepts to master: java, java class libraries, css,
html, xml, javascript, jndi, sql, more sql..., ejb, jdo...
> 
> 
>  - several times we tried to eliminate all scriptlets in our jsp's only to give up. One
example was an html alphbet index - where each page presented each letter of the alphabet
as link to click into a search page. The author wrote a script that stepped thru a string,
build a <a href...> around each letter. As far as we could tell, there is no java iterator
over a string, so our effort to find a simple tag solution failed.

Do you mean you literally needed a java.util.Iterator for the characters 
in a String?

String s = ...;
char[] chars = s.toCharArray();
int numChars = chars.length;
Character[] characters = new Character[numChars];
for (int i = 0; i < numChars; i++) {
  characters[i] = new Character(chars[i]);
}
List charList = Arrays.asList(characters);
Iterator iter = charList.listIterator();

I guess it would be nice if it were simpler, but you've only gotta write 
it once as a utility method. Hey wait, I guess you could use the Commons 
Collections to just do:

Iterator iter = new ArrayIterator(s.toCharArray());

Ah! So many classes, so many libraries! ;-)

If you didn't need an Iterator explicitly, the mind boggles at how many 
ways you might step through a String...

>  
>  - conditional tags don't support else clause. Because of this some of the jsp pages
where the authors refused to use scriptlets are convoluted.
> 

<c:choose>
   <c:when test="...">
     ...
   </c:when>
   <c:otherwise>
     ...
   </c:otherwise>
</c:choose>

>  - Some parts of the project, from third party vendors use lots of custom tag libraries.
Hidden in the tag source code, ah ha!, hundreds of lines of servlet code. My guess is this
happens all the time. Writing servlet code is bad practice, but easy to crank out, so its
hidden inside of a custom tag library (where its worse practice) covered with a veneer of
respectability.
> 
>  - the tag library spec is meant to allow the custom tags to access the request and session
objects, so there is alot of power there - but... to me, the sesion, and request objects,
are like global data, and stuff can get lost and stepped on - so its better to avoid using
it - custom tag libraries encourage its use.
> 
>  - debugging exceptions that run thru tag libraries can be tricky.
> 
> What I've begun using is a "page" tier. Building on Struts, a form is submitted to an
action class, the action class does it business, going to the database thru  a "data" tier
( a package of facade classes), building up its results in a simple java "page" class (build
around a hashmap) which is inserted into the session. The action class forwards to the jsp's
( we use lots of frames - typical page has 7 ), the JSP's fetch the page class from the session.
The page class performs as much of the page layout logic as possible, returning simple strings
for output - even select boxes that are built from the database. 
> 
> The jsp becomes::
> 
> <%
> ARProcessPage page =(ARProcessPage) session.get("arProcessPage");
> %>
> 
> <html>
> <body>
>               
>   <tr><th class="pagetitle"><%=page.getPageTitle()%></th></tr>
>   <tr><th class="pagesubtitle"><%=page.getPageSubTitle()%></th></tr>
> 
> <% if (page.isWritable()) { %>
> 
>     <td><input size="12" value=<%=page.get("value")%> ></td>
>      ....
> 
> <% else %>
> 
>     <td class="readonly"> <%=page.get("value")%></td> 
>     .....
> 
> <% } %> 
> 
> </body>
> </html>   
> 
> In the earlier projects, custom tag libraries were used to generate page titles an other
elements. But if a class is simply returning html strings, why does it need to be a taglibrary;
why not a simple java class?
> 
> 
> We do use some of the basic struts tags:
> <logic:present>
> <logic:iterator>
> but, the requirement to not have scriptlet code has been reduce to a suggestion.
> 
> Thanks,
>   James
> 
> 
> 
> 
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Tuesday, January 14, 2003 3:48 PM
> To: Tomcat Users List
> Subject: Re: jsp versus xml syntax
> 
> 
> 
> 
> On Tue, 14 Jan 2003, Erik Price wrote:
> 
> 
>>Date: Tue, 14 Jan 2003 16:45:43 -0500
>>From: Erik Price <eprice@ptc.com>
>>Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
>>To: Tomcat Users List <tomcat-user@jakarta.apache.org>
>>Subject: Re: jsp versus xml syntax
>>
>>
>>
>>Craig R. McClanahan wrote:
>>
>>
>>>I feel that users who use variable declarations, function declarations,
>>>and scriptlets in JSP pages *at all* (no matter what syntax) are probably
>>>making a mistake.  Mixing Java code with JSP code is likely to lead to a
>>>morass of spaghetti that mixes business logic and presentation logic
>>>together, and will ultimately make maintenance much harder.
>>
>>I'm going to question this but not because I disagree but rather b/c I'm
>>new and am always willing to listen to advice.
>>
>>Since all of my JSPs in my site will need a navigation bar, I have
>>sectioned the navigation bar off into its own JSP file, which is then
>>included into the main JSP files (at compile time).  This is nice
>>because if I change the navigation system in one place, it is changed
>>across the site and I don't have to repair every single JSP.
>>
>>But in that JSP, there is a conditional test to determine whether or not
>>certain links should be displayed.  Namely, administrative functions
>>should not be displayed to users who don't have administrative access.
>>The way I have it right now is an "if" statement in a scriptlet, which
>>displays the appropriate HTML depending on the user's session
>>information (the user is represented with a bean, and it checks one of
>>the properties of the bean to make this decision).
>>
>>I know that this is how a lot of JSPs are written, so it's not
>>necessarily *bad*.  But you seem to be hinting at a better way of doing
>>it.  My best guess is that you're referring to creating a custom tag of
>>some sort that displays the navigation, and the logic for what to
>>display should be tucked away into the tag definition?  I'm only
>>guessing here.  If you could expound a bit that would be helpful for a
>>lot of us, I'm sure.
>>
> 
> 
> This is a pretty good example use case, that we can use to illustrate how
> JSP has matured over the years, and also explain *why* you see so many
> pages with this sort of thing (and yes, I do consider it to be a poor
> practice to use a scriptlet for this).
> 
> Let's take a concrete case where you're simply checking for the existence
> of a particular request attribute as your decision rule.
> 
> In the early days (1.0) of JSP, there wasn't really much choice -- you had
> to write a scriptlet to get conditional behavior:
> 
>     <% if (request.getAttribute("foo")) { %>
>       ... foo is present ...
>     <% } else { %>
>       ... foo is absent ...
>     <% } %>
> 
> which, of course, gets confusing because there are so many punctuation
> symbols, and you have to remember to use braces around all the conditional
> blocks.  You'd be amazed at how frustrated an HTML page author can get
> trying to get this right.
> 
> In JSP 1.1, we gained the ability to write custom tags, which lets you
> encapsulate Java code inside what looks (to the page developer) like a
> tag.  Several tag libraries became available to do lots of simple things,
> including the Jakarta Taglibs project (http://jakarta.apache.org/taglibs).
> Further, MVC frameworks like Struts (http://jakarta.apache.org/struts)
> started to become available, and offered a way to architect your entire
> application in a way that maximizes the separation between the business
> layer and the presentation layer.  Among other things, Struts also
> includes tags in its tag library that work for this use case:
> 
>     <logic:present name="foo" scope="request">
>       ... foo is present ...
>     </logic:present>
>     <logic:notPresent name="foo" scope="request">
>       ... foo is not present ...
>     </logic:notPresent>
> 
> Page authors are more used to tag syntax than they are to programming
> syntax, so this makes more sense, but it is somewhat wordy.  (Part of that
> is because Struts does not have an "else" concept in its tags -- long
> story, but it's not easy to do an elegant if-then-else with tags).
> 
> Custom tags are not that hard to write -- IF you are a Java programmer,
> and if you can get your head around the complexities of the invocation
> protocol (you have to implement several methods, and deal with the fact
> that your tag instance might get pooled, ...).
> 
> JSP 1.2 improved many things about JSP, but didn't change the basic model
> for tags much.  However, a parallel effort called the JSP Standard Tag
> Library (JSTL) was started to standardize the most common sorts of tags
> that everybody needs.  In addition, it became clear that page authors *do*
> tend to understand at least a little programming syntax, depending on
> their exposure to JavaScript.  In particular, JavaScript variable
> references (with the "." operator) were fairly easy to grasp.
> 
> JSTL 1.0 was released last June, (the reference implementation is based on
> the "standard" tag library at Jakarta Taglibs, so it's freely available),
> and formalized standard versions of tags for conditionals, iteration,
> formatting, XML processing, and such.  In addition, it defined an
> "expression language" (EL) that can be used a syntax as close as we could
> get to JavaScript/ECMAScript.  For example (not the same use case as
> above), you can say things like:
> 
>   <c:if test="${customer.type = 'Special'}">
>     ... display options for special customer ...
>   </c:if>
> 
> where "customer.type" essentially says "go find the 'customer' bean in
> whatever scope it lives in, and call getType() method on it."
> 
> JSTL can be used on any JSP 1.2 platform (such as Tomcat 4.x), just like
> any other tag library.  However, EL expressions only work in the
> attributes of JSTL tags (although some other tag libraries are adopting
> this syntax as well -- Struts 1.1 now includes a version of the Struts
> tags that have been EL-enabled, for example).
> 
> JSP 2.0, among other things, incorporates the new EL syntax.  And not just
> in tag attributes, but *anywhere* in the page.  So, if you need to write
> out a customer name to the output page,instead of saying something like:
> 
>   <% out.println(customer.getName()) %>
> 
> or (slightly shorter for this particular scenario):
> 
>   <%= customer.getName() %>
> 
> or the "official" JSP 1.x way to do it:
> 
>   <jsp:getProperty name="customer" property="name"/>
> 
> you can now say:
> 
>   ${customer.name}
> 
> in your page.  Of course, we're barely touching the surface of what you
> can do with expressions, but basically there's almost no scenario where
> the only way to solve a problem is to use a scriptlet when you've got this
> kind of power available, and presented in a way that is much more
> understandable to page authors.
> 
> There's *lots* of other cool things coming in JSP 2.0 (including the
> ability to essentially create a custom tag out of a chunk of JSP code,
> without writing any Java, and reuse it).  JSP 2.0 is part of J2EE 1.4,
> which will go final this year.  Tomcat 5 will support it, as will all
> other J2EE vendors when they get their 1.4 based products out.
> 
> The bottom line, though, is that much (probably more than half) of the
> books and articles about JSP that you can find focus on the 1.0 and 1.1
> syntax, and they don't show you how to do things differently.
> 
> I try to encourage newcomers to adopt good habits in the first place --
> that's one of the reasons I created Struts, because way too many people
> were trying to mix the Java code to process forms into the same JSP pages
> that contain the forms themselves -- this works for "guest book" sized
> apps, but quickly becomes a maintenance nightmare on large projects.
> 
> The more recent books about JSP, JSTL, and web app frameworks are starting
> to get this right.  If you are into book learning, I'd strongly encourage
> you to get one of the recent texts (look for JSP 1.2 coverage) that
> encourages practices that will help keep your pages understandable and
> maintainable.
> 
> And if you've got a 5000-line JSP page that has "all in one" support for
> three input forms and four follow-up screens, all controlled by "if"
> statements in scriptlets, well ... please don't show it to me :-).  Its
> almost dinner time, and I don't want to lose my appetite :-).
> 
> 
>>Thanks,
>>
>>Erik
>>
> 
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
> 
> 

-- 
Kris Schneider <mailto:kris@dotech.com>
D.O.Tech       <http://www.dotech.com/>


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


Mime
View raw message