Before I get bashed again, I meant JSTL is replacing the use of the traditional JSP tags before all the <c:when> came out. I haven't seen one of those tags in ages.
Maybe it will still be called JSTL but maybe their will be nicer replacement tags for some of the ugly logic ones. Maybe that is the solution. -----Original Message----- From: Bailey, Shane C. [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 4:20 PM To: 'Struts Users Mailing List' Subject: RE: JSTL ot struts taglibs? But, what I really meant about JSTL being replaced was in popularity. JSP tags are being replaced (in popularity) with Struts tags, your JSTL, and alike. -----Original Message----- From: Bailey, Shane C. [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 4:02 PM To: 'Struts Users Mailing List' Subject: RE: JSTL ot struts taglibs? -----Original Message----- From: Erik Price [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 3:45 PM To: Struts Users Mailing List Subject: Re: JSTL ot struts taglibs? Bailey, Shane C. wrote: [Snip] Why should build files be composed of tags at all? I think Ant is great too (a lot better than make), but does the fact that it is tag-based have anything to do with it? No. The reason that the original author went with XML for the structure of Ant build files had nothing to do with tags -- it had to do with hierarchy. See <http://tinyurl.com/jg0d> to read his thoughts on the matter (sorry for the cachelink but I can't find the official permalink). [/Snip] I don't know why a build file should be composed of tags either. My point was that Ant is nicer and more recently popular than make and the developer could have thought, "You know, most people that will be using Any will probably know make so I am going to throw a bunch of "==" in there and that would be fine. Ant has more of an excuse to have "==" in the darn thing than a View (geared toward UI and graphic artist specialist) tag set does. And the Ant developer must have seen the light. (All my opinion, of course). [Snip] Faster? Given a programmer with equal knowledge of scriptlets and JSTL, scriptlets are definitely not faster for development. Since when are they faster for performance? Plus they tend to be difficult to read -- and I say this as a former PHP programmer. [/Snip] If they aren't faster in performance then something is wrong. All the JSP rendering practically has to do is put the code as is into the Servlet which is a Java class. No interpretation. I haven't looked at the source but I am sure the optimization for rendering code for Scriptlets vs JSTL has to be there. I know more Java programmers that could get a JSP page drawn if you simple told them <% ... %> for multiple code segments and do <%= ... %> to return an expression given all they knew was Java and no Web stuff (including JSTL at all). [Snip] Okay, first of all, JSTL is a JCP specification (JSR-52, for more info see <http://jcp.org/aboutJava/communityprocess/final/jsr052/>). It's not just some 3rd-party library that is going to be "replaced" any time soon. Second of all, it is actually a part of the JSP 2.0 specification (just as scriptlets are part of an earlier JSP specification). While scriptlets are still supported in JSP 2.0, it is clear that Sun and the JCP are trying to provide alternatives to scriptlets and at some point they might even be deprecated. [/Snip] Nothing is impossible. I remember being devastated after getting pretty efficient with AWT and then the model changed and then Swing came out. And you even mention how scriptlets WERE part of the spec and are now close to deprecation. So what is so ridiculous about my statement??? [Snip] So sorry, but I had to ask - what the crap were you talking about. [/Snip] No problem. --------------------------------------------------------------------- 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]
