Found this: http://www.manning.com/bayern/appendixA.pdf
From a new book JSTL in Action.
Aaron
Andrew Hill wrote:
Afraid my knowledge of both is strictly second-hand. Havent used either! Sorry :-(
Im sure you can find jstl info online though, whats google return for it?
-----Original Message----- From: Aaron Longwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, 18 June 2003 21:50 To: Struts Users Mailing List Subject: Re: My View Is Messy
Andrew,
2 things. First, is there a good tag reference (similar to the Struts docs) for the JSTL tags online? I've never worked with JSTL before.
Second, I've looked at the stxx web site, and it looks like an intelligent system.... on the other hand... it looks like it might add a good chunk of development time:
BEFORE: 1) Create JSP to display code
AFTER: 1) Make All actions extend Stxx Action 2) Implement saveDocument for all actions 3) Create XSL stylesheet for all actions
This seems like a lot of additional steps, with the increased debugging issue of having to compile the action and restart the webapp for each change.... JSPs can be edited live and reloaded to see the changes. On the other hand, Stxx adds in a few new features (like delivery to a cell phone, XML-output to use with an XML Web Services app, etc). Have you used it? Do you like it?
Thanks, Aaron
Andrew Hill wrote:
extension<snip> (serializing to XML just to reserialize to HTML seems like an unnecessary performance hit) </snip>
Yeh, Id imagine it can get pretty expensive when the server is under heavy load.
I wouldnt want to do that for amazon.com type sites ... although actually
for xslt, I think the modern browsers can understand it, so you could just
write the xml to the response from jsp and whatever it is you need to do
tell the browser where to pull the stylesheet and let it do the grunt
work... havent tried it myself though. Have you looked at the stxx
yet?
Really though I reckon what you want to look at is the tiles extension, and for smaller 'fiddly bits' that reoccur a lot banging together your own jsp tags.
oh yeah! - The other thing you should look at (first!) is JSTL and/or the struts-el tags as I believe they support a somewhat more concise (and certainly less ugly) syntax for what your doing in that example.
-----Original Message----- From: Aaron Longwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, 18 June 2003 21:27 To: Struts-User Subject: My View Is Messy
Morning everyone,
I have been working on an event manager application in Struts for about 3 days. I'm just getting to the point of displaying a monthly calendar full of events. I finished up the JSP last night, and it's a mess. First, there's a lot of code in it. For example, to print out the event time, name, and description looks like this:
<dt:format date="<%= event.getStartDate() %>" pattern="hh:mma"/> - <dt:format date="<%= event.getEndDate() %>" pattern="hh:mma"/> : <bean:write name="event" property="title"/><br/> <bean:write name="event" property="description"/>
All that code just to print this:
4:00pm - 5:00pm : Watch TV<br/> Watch TV event description
Cold Fusion salespeople always tout the fact that Cold Fusion is "tag-based." I've always thought markup tags for dynamic content took up way too much space in the HTML.... I don't like Cold Fusion. My view is starting to look like Cold Fusion.
I've looking for some recommendations for better view frameworks. Do you use Velocity? Do you use an implementation of XSLT? How do these affect application performance (serializing to XML just to reserialize to HTML seems like an unnecessary performance hit)? How do they affect development time (all of them seem to require extra effort to develop (i.e. compiling a new servlet for each view, etc)?
Thanks for the recommendations, Aaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
