Re: Additional logic:iterate helper tags wanted

[Michael Lee]

Oh struts, definately. I use struts like a toolkit. I hand a web page to our
graphic artist with all the html:text.../ and bean:write.../ and
bean:message.../ in it. It can put them wherever he needs them with ease,
just like an html tag. All the session/request information and logic is
hidden through html 'like' (struts) tags (and our own custom tags). We use
the jakarta XSL taglibs when the data is pulled from the database in XML
format. I still wrapper the XML in a Java object so if we need to break it
up and do business logic on it the interface can stay the same. Then when it
gets to the JSP he just uses the jakarta XSL tag lib and transforms it where
necessary. I just look at this argument as kind of academic. I say, use
whatever your most familiar with but use it cleanly (JSPs use tags,
javascript use a .js tag instead of inline javascript, etc). View, in my
opinion, are not to be looked at as the reusable components of your system.
Those should be your JSP tags (yay struts and jakarta tag libs!) and/or XSL
documents. This is VERY pertinent to what we do as we make digital receipts
that come from the retailer in XML format. You can imagine we DON'T want to
have to write JSP code to transform every one of these for every new retail
customer we get. We use XSLT on that. But that is because the data is
comming as XML already and we're familiar with XSLT. The data we pull from
the database we use JSP/struts/internal tags and value/form objects to
populate the screens. Our graphic artist is great with XSLT so that is his
preference and as a developer it is easy enough to change a Java bean to XML
for him.

Here is a design I came up with (I'm the J2EE architect) for the system that
addresses both these issues.

All your value objects have a toXML() method. They also follow the bean
format for all the data. The XML transformations are handled by Helper
classes for serialization purposes.

You can just call User.toXML() and get the XSL sheet for that XML if you
want to use XML or you can use
bean:write name=user property=firstName/ if the data is not in XML but
stored in the Java object's fields. Either way the interface is the same.
This means that if we go to a new customer we don't have to change a lot of
code except at the view layer. We use EJBs and override them as needed for
new customers but deploy them to the same JNDI name (as long as the state
flow is the same).
Works like a champ so far. We're in development but it is nice.
Mike


- Original Message -
From: Donald Ball [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 11, 2002 6:06 PM
Subject: Re: Additional logic:iterate helper tags wanted


 On 9/11/2002 at 2:02 PM Michael Lee wrote:

 Basically how we got the data dictated the view. I've found XSLT to be
 'wordy'. I think its just as easy to write another damned JSP and parse
 the
 Java Objects up there as it is to create another XSL page and use the
same
 JSP.
 I consider views to be relatively non-reusable so time to market is my
big
 concern.

 Makes sense given your constraints. So when you throw together these
JSP's,
 do you use struts/JSTL taglibs or do you let yourself write scriptlets?

 - donald


 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Donald Ball]

On 9/6/2002 at 4:46 PM Martin Cooper wrote:

If you're using a JSP 1.2 container (e.g. Tomcat 4.x, Resin 2.x), you can
do
this (and many other cool things) using the JSTL c:forEach tag:

  c:forEach items=items var=item varStatus=status
c:out value=${item}/
c:if test=${!status.last}
  ...is followed by...
/c:if
  /c:forEach

This is a great reason to start getting familiar with JSTL. :-)

(sorry for resurrecting an old thread, I neglected to post my thoughts
earlier)

This is what totally bugs me about JSP pages, I'm curious to see if anyone
else here shares my concerns. Early JSP pages freely mingled java code
(scriptlets) and html markup. This development style was quickly seen to be
poor for a few reasons:

* java coders and html designers had to edit the same files, causing no end
of confusion and synchronization problems

* the intermingling of logic and design makes pages messy and hard to
maintain

* it was difficult to reuse code from page to page, except by cutting and
pasting

Taglibs are offered as a solution for this, but I wonder how effective they
really are at solving these problems. Instead of writing % for (int i=0;
i... etc % you write c:forEach pre={$i}=0 ...  or what have you.
Okay, it's arguably nicer looking and easier to validate since it tends to
follow standard xml syntax rules instead of the % % hacks, but does it
really solve the aforementioned problems? Sure, disciplined developers can
reuse code more easily by writing (and debugging!) their own taglibs, but
the first two problems remain.

And in the end condition, when you can do anything using JSTL or whatever
other taglibs that you could have written in Java, haven't you just come up
with an xml grammar for the Java language? Which might be intellectually
interesting, but who wants to _program_ using a verbose syntax like xml?
(If you wanted to use lisp, go ahead and use lisp. :))

I'm obviously not a jsp devotee. I think xslt is the natural bridge between
the model objects and the html view. But millions of jsp coders can't be
all wrong, right? What benefits am I glossing over or disregarding? 

- donald


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Craig R. McClanahan]

At the high level:  The JSTL tags are nice.  The JSTL expression language
(now adopted by JSP 2.0) is powerful enough to completely eliminate the
need for scriptlets and runtime expressions in JSP pages.  JSP 2.0 page
compilers will also let you use EL expressions directly in template text,
not just in tag attributes.

At the low level:  Given that you have to use *some* syntax for this
stuff, picking a syntax that lots of people are already familiar with
seems a lot smarter than making one up and having to teach it to all your
page authors :-).

Craig

On Wed, 11 Sep 2002, Donald Ball wrote:

 Date: Wed, 11 Sep 2002 11:17:27 -0400
 From: Donald Ball [EMAIL PROTECTED]
 Reply-To: Struts Users Mailing List [EMAIL PROTECTED],
  [EMAIL PROTECTED]
 To: [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: RE: Additional logic:iterate helper tags wanted

 On 9/6/2002 at 4:46 PM Martin Cooper wrote:

 If you're using a JSP 1.2 container (e.g. Tomcat 4.x, Resin 2.x), you can
 do
 this (and many other cool things) using the JSTL c:forEach tag:
 
   c:forEach items=items var=item varStatus=status
 c:out value=${item}/
 c:if test=${!status.last}
   ...is followed by...
 /c:if
   /c:forEach
 
 This is a great reason to start getting familiar with JSTL. :-)

 (sorry for resurrecting an old thread, I neglected to post my thoughts
 earlier)

 This is what totally bugs me about JSP pages, I'm curious to see if anyone
 else here shares my concerns. Early JSP pages freely mingled java code
 (scriptlets) and html markup. This development style was quickly seen to be
 poor for a few reasons:

 * java coders and html designers had to edit the same files, causing no end
 of confusion and synchronization problems

 * the intermingling of logic and design makes pages messy and hard to
 maintain

 * it was difficult to reuse code from page to page, except by cutting and
 pasting

 Taglibs are offered as a solution for this, but I wonder how effective they
 really are at solving these problems. Instead of writing % for (int i=0;
 i... etc % you write c:forEach pre={$i}=0 ...  or what have you.
 Okay, it's arguably nicer looking and easier to validate since it tends to
 follow standard xml syntax rules instead of the % % hacks, but does it
 really solve the aforementioned problems? Sure, disciplined developers can
 reuse code more easily by writing (and debugging!) their own taglibs, but
 the first two problems remain.

 And in the end condition, when you can do anything using JSTL or whatever
 other taglibs that you could have written in Java, haven't you just come up
 with an xml grammar for the Java language? Which might be intellectually
 interesting, but who wants to _program_ using a verbose syntax like xml?
 (If you wanted to use lisp, go ahead and use lisp. :))

 I'm obviously not a jsp devotee. I think xslt is the natural bridge between
 the model objects and the html view. But millions of jsp coders can't be
 all wrong, right? What benefits am I glossing over or disregarding?

 - donald


 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Donald Ball]

On 9/11/2002 at 9:17 AM Craig R. McClanahan wrote:

At the high level:  The JSTL tags are nice.  The JSTL expression language
(now adopted by JSP 2.0) is powerful enough to completely eliminate the
need for scriptlets and runtime expressions in JSP pages.  JSP 2.0 page
compilers will also let you use EL expressions directly in template text,
not just in tag attributes.

So you _have_ rewritten Java in an xml-like language. :) except that you
break xml rules by allowing things like jsp elements in tag attributes.

At the low level:  Given that you have to use *some* syntax for this
stuff, picking a syntax that lots of people are already familiar with
seems a lot smarter than making one up and having to teach it to all your
page authors :-).

I guess that's where we disagree. I don't think you have to have a
programming language for doing your view pages. I think you should keep the
programming logic back in your Java code where it belongs and the language
which does the transformation from model to view should not let you do
anything except transform input tree into output tree.

I guess what I'm trying to point out is this: it seems to me that with JSTL
and its friends, JSP pages now share the drawbacks of XSLT (namely verbose
syntax) without gaining any of its benefits (side-effect free processing
model forces logic to stay back in the controller, strict adherence to xml
syntax makes it easy to validate xslt stylesheets as well as their output).

- donald


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Craig R. McClanahan]

Personally, I like XSLT just fine (and the Stxx project lets you
integrate it with Struts as well, if you want).  But I'm wierd ... I don't
think SAX parsing is difficult to understand, either.

But there seem to be a very large number of people in the world who, even
if they take the time to look at XSLT, are totally mystified by the
declarative programming style (versus procedural logic).

If you're using high quality tools, it probably doesn't matter much.  If
you're writing your pages by hand, though, familiarity is important for
acceptance.  And I care about the folks who will never be able to
understand stylesheets just as much as I care for the folks that can write
and use them appropriately.

Craig

On Wed, 11 Sep 2002, Donald Ball wrote:

 Date: Wed, 11 Sep 2002 12:36:28 -0400
 From: Donald Ball [EMAIL PROTECTED]
 To: [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: RE: Additional logic:iterate helper tags wanted

 On 9/11/2002 at 9:17 AM Craig R. McClanahan wrote:

 At the high level:  The JSTL tags are nice.  The JSTL expression language
 (now adopted by JSP 2.0) is powerful enough to completely eliminate the
 need for scriptlets and runtime expressions in JSP pages.  JSP 2.0 page
 compilers will also let you use EL expressions directly in template text,
 not just in tag attributes.

 So you _have_ rewritten Java in an xml-like language. :) except that you
 break xml rules by allowing things like jsp elements in tag attributes.

 At the low level:  Given that you have to use *some* syntax for this
 stuff, picking a syntax that lots of people are already familiar with
 seems a lot smarter than making one up and having to teach it to all your
 page authors :-).

 I guess that's where we disagree. I don't think you have to have a
 programming language for doing your view pages. I think you should keep the
 programming logic back in your Java code where it belongs and the language
 which does the transformation from model to view should not let you do
 anything except transform input tree into output tree.

 I guess what I'm trying to point out is this: it seems to me that with JSTL
 and its friends, JSP pages now share the drawbacks of XSLT (namely verbose
 syntax) without gaining any of its benefits (side-effect free processing
 model forces logic to stay back in the controller, strict adherence to xml
 syntax makes it easy to validate xslt stylesheets as well as their output).

 - donald




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[JEWeaver]

Wow, good rhubarb here hiding under a misleading subject title ;-).

I think XSLT based presentation architecture vs. JSP is highly interesting,
Donald, but I don't agree with many of your points.

To me, the big strength of the XSLT approach would be the ability to
transform the model into a variety of views (not just one html view).  I
know that I can create a JSP application that is layered well, keeping only
things like variable output and iteration in the JSPs and all other data
preparation work back in other Java layers.  Believe me, programmers can
hash up any architecture.  I can make a mess with XSLT just as readily as I
can with JSP.

The strength of the JSP approach is it is faster to get going, particularly
if I'm starting with HTML prototypes of an application.  If I only have one
transform (model data to one html), why do a lot of extra work?

Jim Weaver
Software Developer - ThoughtWorks


   
   
  Donald Ball
   
  [EMAIL PROTECTED]To:   [EMAIL PROTECTED], 
[EMAIL PROTECTED]  
  om  cc: 
   
   Subject:  RE: Additional 
logic:iterate helper tags wanted
  09/11/2002 09:36 
   
  AM   
   
  Please respond to
   
  Struts Users
   
  Mailing List
   
   
   
   
   




On 9/11/2002 at 9:17 AM Craig R. McClanahan wrote:

At the high level:  The JSTL tags are nice.  The JSTL expression language
(now adopted by JSP 2.0) is powerful enough to completely eliminate the
need for scriptlets and runtime expressions in JSP pages.  JSP 2.0 page
compilers will also let you use EL expressions directly in template text,
not just in tag attributes.

So you _have_ rewritten Java in an xml-like language. :) except that you
break xml rules by allowing things like jsp elements in tag attributes.

At the low level:  Given that you have to use *some* syntax for this
stuff, picking a syntax that lots of people are already familiar with
seems a lot smarter than making one up and having to teach it to all your
page authors :-).

I guess that's where we disagree. I don't think you have to have a
programming language for doing your view pages. I think you should keep the
programming logic back in your Java code where it belongs and the language
which does the transformation from model to view should not let you do
anything except transform input tree into output tree.

I guess what I'm trying to point out is this: it seems to me that with JSTL
and its friends, JSP pages now share the drawbacks of XSLT (namely verbose
syntax) without gaining any of its benefits (side-effect free processing
model forces logic to stay back in the controller, strict adherence to xml
syntax makes it easy to validate xslt stylesheets as well as their output).

- donald


--
To unsubscribe, e-mail:   
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: 
mailto:[EMAIL PROTECTED]







--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Joe Barefoot]

+1

It's a lot easier to JSP-ify an html prototype page than it is to turn the same into 
an XSLT-driven presentation.  Now, if there were *good* high-level productivity tools 
to facilitate the conversion (HTML - XSLT), this might be a different story.  I don't 
have my crystal ball with me today though, so I can't speculate on that one. :)


peace,
Joe Barefoot

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, September 11, 2002 10:15 AM
 To: Struts Users Mailing List
 Subject: RE: Additional logic:iterate helper tags wanted
 
 
 
 Wow, good rhubarb here hiding under a misleading subject title ;-).
 
 I think XSLT based presentation architecture vs. JSP is 
 highly interesting,
 Donald, but I don't agree with many of your points.
 
 To me, the big strength of the XSLT approach would be the ability to
 transform the model into a variety of views (not just one 
 html view).  I
 know that I can create a JSP application that is layered 
 well, keeping only
 things like variable output and iteration in the JSPs and all 
 other data
 preparation work back in other Java layers.  Believe me, 
 programmers can
 hash up any architecture.  I can make a mess with XSLT just 
 as readily as I
 can with JSP.
 
 The strength of the JSP approach is it is faster to get 
 going, particularly
 if I'm starting with HTML prototypes of an application.  If I 
 only have one
 transform (model data to one html), why do a lot of extra work?
 
 Jim Weaver
 Software Developer - ThoughtWorks
 
 
   
 
   Donald Ball   
 
   [EMAIL PROTECTED]To:   
 [EMAIL PROTECTED], [EMAIL PROTECTED]  
   om  cc:
 
Subject:  RE: 
 Additional logic:iterate helper tags wanted 
   
   09/11/2002 09:36
 
   AM  
 
   Please respond to   
 
   Struts Users   
 
   Mailing List   
 
   
 
   
 
 
 
 
 
 On 9/11/2002 at 9:17 AM Craig R. McClanahan wrote:
 
 At the high level:  The JSTL tags are nice.  The JSTL 
 expression language
 (now adopted by JSP 2.0) is powerful enough to completely 
 eliminate the
 need for scriptlets and runtime expressions in JSP pages.  
 JSP 2.0 page
 compilers will also let you use EL expressions directly in 
 template text,
 not just in tag attributes.
 
 So you _have_ rewritten Java in an xml-like language. :) 
 except that you
 break xml rules by allowing things like jsp elements in tag 
 attributes.
 
 At the low level:  Given that you have to use *some* syntax for this
 stuff, picking a syntax that lots of people are already familiar with
 seems a lot smarter than making one up and having to teach 
 it to all your
 page authors :-).
 
 I guess that's where we disagree. I don't think you have to have a
 programming language for doing your view pages. I think you 
 should keep the
 programming logic back in your Java code where it belongs and 
 the language
 which does the transformation from model to view should not let you do
 anything except transform input tree into output tree.
 
 I guess what I'm trying to point out is this: it seems to me 
 that with JSTL
 and its friends, JSP pages now share the drawbacks of XSLT 
 (namely verbose
 syntax) without gaining any of its benefits (side-effect free 
 processing
 model forces logic to stay back in the controller, strict 
 adherence to xml
 syntax makes it easy to validate xslt stylesheets as well as 
 their output).
 
 - donald
 
 
 --
 To unsubscribe, e-mail:   
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: 
 mailto:[EMAIL PROTECTED]
 
 
 
 
 
 
 
 --
 To unsubscribe, e-mail:   
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: 
 mailto:[EMAIL PROTECTED]
 
 

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL

Re: Additional logic:iterate helper tags wanted

[Michael Lee]

We use it all here. We had a big meeting and all agreed on one thing.
Views tend not to be too reusable so...
Use whatever medium you can to get something up fast. That usually means it
depends on the type of data comming in.
Here we get some data as XML (we do digial receipts and there is an XML
standard).
That data, we use XSLT.
We have a lot of data also in a database.
It is much faster to just code up some jdbc, put it in a value object (to
allow for business processing) and then use struts tags to pump em out on
the JSP.
Basically how we got the data dictated the view. I've found XSLT to be
'wordy'. I think its just as easy to write another damned JSP and parse the
Java Objects up there as it is to create another XSL page and use the same
JSP.
I consider views to be relatively non-reusable so time to market is my big
concern.
(I use lots of JSP tags and programs like struts to create the reusable
aspects of the view).
My 5 c
Mike


- Original Message -
From: [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Wednesday, September 11, 2002 1:14 PM
Subject: RE: Additional logic:iterate helper tags wanted



 Wow, good rhubarb here hiding under a misleading subject title ;-).

 I think XSLT based presentation architecture vs. JSP is highly
interesting,
 Donald, but I don't agree with many of your points.

 To me, the big strength of the XSLT approach would be the ability to
 transform the model into a variety of views (not just one html view).  I
 know that I can create a JSP application that is layered well, keeping
only
 things like variable output and iteration in the JSPs and all other data
 preparation work back in other Java layers.  Believe me, programmers can
 hash up any architecture.  I can make a mess with XSLT just as readily as
I
 can with JSP.

 The strength of the JSP approach is it is faster to get going,
particularly
 if I'm starting with HTML prototypes of an application.  If I only have
one
 transform (model data to one html), why do a lot of extra work?

 Jim Weaver
 Software Developer - ThoughtWorks



   Donald Ball
   [EMAIL PROTECTED]To:
[EMAIL PROTECTED], [EMAIL PROTECTED]
   om  cc:
Subject:  RE: Additional
logic:iterate helper tags wanted
   09/11/2002 09:36
   AM
   Please respond to
   Struts Users
   Mailing List






 On 9/11/2002 at 9:17 AM Craig R. McClanahan wrote:

 At the high level:  The JSTL tags are nice.  The JSTL expression language
 (now adopted by JSP 2.0) is powerful enough to completely eliminate the
 need for scriptlets and runtime expressions in JSP pages.  JSP 2.0 page
 compilers will also let you use EL expressions directly in template text,
 not just in tag attributes.

 So you _have_ rewritten Java in an xml-like language. :) except that you
 break xml rules by allowing things like jsp elements in tag attributes.

 At the low level:  Given that you have to use *some* syntax for this
 stuff, picking a syntax that lots of people are already familiar with
 seems a lot smarter than making one up and having to teach it to all your
 page authors :-).

 I guess that's where we disagree. I don't think you have to have a
 programming language for doing your view pages. I think you should keep
the
 programming logic back in your Java code where it belongs and the language
 which does the transformation from model to view should not let you do
 anything except transform input tree into output tree.

 I guess what I'm trying to point out is this: it seems to me that with
JSTL
 and its friends, JSP pages now share the drawbacks of XSLT (namely verbose
 syntax) without gaining any of its benefits (side-effect free processing
 model forces logic to stay back in the controller, strict adherence to xml
 syntax makes it easy to validate xslt stylesheets as well as their
output).

 - donald


 --
 To unsubscribe, e-mail:   
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: 
 mailto:[EMAIL PROTECTED]







 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Donald Ball]

On 9/11/2002 at 10:14 AM [EMAIL PROTECTED] wrote:

Wow, good rhubarb here hiding under a misleading subject title ;-).

rhubarb? do you mean rhetoric? :)

To me, the big strength of the XSLT approach would be the ability to
transform the model into a variety of views (not just one html view).  I
know that I can create a JSP application that is layered well, keeping
only
things like variable output and iteration in the JSPs and all other data
preparation work back in other Java layers.  Believe me, programmers can
hash up any architecture.  I can make a mess with XSLT just as readily as
I
can with JSP.

While that's true to a certain extent, you can't make as much of a mess
with XSLT as you can with JSP. For one thing, without relying on XSLT
extensions, you _can't_ write an XSLT stylesheet which affects the Java
Model or Controller objects in any way. For another, you _can't_ generate
invalid output with XSLT (syntactically, anyway. you can check grammar if
you run the output through a validating SAX filter, but you _could_ do that
with your JSP pages if you wanted to.)

The strength of the JSP approach is it is faster to get going,
particularly
if I'm starting with HTML prototypes of an application.  If I only have
one
transform (model data to one html), why do a lot of extra work?

I find I can turn an HTML page into an XSLT stylesheet in a matter of a few
minutes (tidy -asxml, add xslt wrapper elements), but for the sake of
argument, I'll accept that you can get JSP's up and running faster. Even if
you only have one target output device (modern html), in addition to the
aforementioned pedantic benefits of XSLT, it also makes it easy to factor
common design elements into a central stylesheet. (I'm a huge fan of the
Don't Repeat Yourself principle.)

Sorry, I didn't mean to turn this into a defence of XSLT - I'm really
curious what JSP/JSTL developers think is superior about it. Thanks for
helping illuminate me.

- donald


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Additional logic:iterate helper tags wanted

[Donald Ball]

On 9/11/2002 at 2:02 PM Michael Lee wrote:

Basically how we got the data dictated the view. I've found XSLT to be
'wordy'. I think its just as easy to write another damned JSP and parse
the
Java Objects up there as it is to create another XSL page and use the same
JSP.
I consider views to be relatively non-reusable so time to market is my big
concern.

Makes sense given your constraints. So when you throw together these JSP's,
do you use struts/JSTL taglibs or do you let yourself write scriptlets?

- donald


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Joe Barefoot]

Great info. in these posts, Donald...don't let my (or anyone else's) repeated 
preferences for JSP-based views disuade you, XSLT has great promise (still wishing I 
had my crystal ball) and the comparisons to the JSP approach are quite useful no 
matter which side of the fence you fall on.  

peace,
Joe

 -Original Message-
 From: Donald Ball [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, September 11, 2002 3:04 PM
 To: [EMAIL PROTECTED]
 Subject: RE: Additional logic:iterate helper tags wanted
 
 
 On 9/11/2002 at 10:14 AM [EMAIL PROTECTED] wrote:
 
 Wow, good rhubarb here hiding under a misleading subject title ;-).
 
 rhubarb? do you mean rhetoric? :)
 
 To me, the big strength of the XSLT approach would be the ability to
 transform the model into a variety of views (not just one 
 html view).  I
 know that I can create a JSP application that is layered 
 well, keeping
 only
 things like variable output and iteration in the JSPs and 
 all other data
 preparation work back in other Java layers.  Believe me, 
 programmers can
 hash up any architecture.  I can make a mess with XSLT just 
 as readily as
 I
 can with JSP.
 
 While that's true to a certain extent, you can't make as much 
 of a mess
 with XSLT as you can with JSP. For one thing, without relying on XSLT
 extensions, you _can't_ write an XSLT stylesheet which 
 affects the Java
 Model or Controller objects in any way. For another, you 
 _can't_ generate
 invalid output with XSLT (syntactically, anyway. you can 
 check grammar if
 you run the output through a validating SAX filter, but you 
 _could_ do that
 with your JSP pages if you wanted to.)
 
 The strength of the JSP approach is it is faster to get going,
 particularly
 if I'm starting with HTML prototypes of an application.  If 
 I only have
 one
 transform (model data to one html), why do a lot of extra work?
 
 I find I can turn an HTML page into an XSLT stylesheet in a 
 matter of a few
 minutes (tidy -asxml, add xslt wrapper elements), but for the sake of
 argument, I'll accept that you can get JSP's up and running 
 faster. Even if
 you only have one target output device (modern html), in 
 addition to the
 aforementioned pedantic benefits of XSLT, it also makes it 
 easy to factor
 common design elements into a central stylesheet. (I'm a huge 
 fan of the
 Don't Repeat Yourself principle.)
 
 Sorry, I didn't mean to turn this into a defence of XSLT - I'm really
 curious what JSP/JSTL developers think is superior about it. 
 Thanks for
 helping illuminate me.
 
 - donald
 
 
 --
 To unsubscribe, e-mail:   
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Michaël]

 If you're using a JSP 1.2 container (e.g. Tomcat 4.x, Resin 2.x),
 you can do
 this (and many other cool things) using the JSTL c:forEach tag:

   c:forEach items=items var=item varStatus=status
 c:out value=${item}/
 c:if test=${!status.last}
   ...is followed by...
 /c:if
   /c:forEach

 This is a great reason to start getting familiar with JSTL. :-)

Does JSTL support nested collections?  I'm currently using the nested taglib
more than the logic taglib.

Michael


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Arron Bates]

On Sat, 2002-09-07 at 16:53, Michaël wrote:
  If you're using a JSP 1.2 container (e.g. Tomcat 4.x, Resin 2.x),
  you can do
  this (and many other cool things) using the JSTL c:forEach tag:
 
c:forEach items=items var=item varStatus=status
  c:out value=${item}/
  c:if test=${!status.last}
...is followed by...
  /c:if
/c:forEach
 
  This is a great reason to start getting familiar with JSTL. :-)
 
 Does JSTL support nested collections?  I'm currently using the nested taglib
 more than the logic taglib.

While I'm sure it will allow you to view the nested collection structure
as each bean is offered up by the last tag. updates from fields in a
nested structure is another deal, as the JSTL wont know how to assemble
the property strcture that Struts will correctly map through to the
right bean.

The JSTL tags don't relate to each other the way the nested tags do.
There's no obvious way to make the functionality handy to the JSTL or
I'd put it forward for a spec improvement. It's just that Struts had the
need to get the dot notation property under control.

Those people which take on that only JSTL is a good policy is simply
going to miss out on what the nested tags will dor for them. Shame, but
a reality.


Arron.




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Additional logic:iterate helper tags wanted

[David M. Karr]

 Martin == Martin Cooper [EMAIL PROTECTED] writes:

Martin Over time, you'll see Struts tags being deprecated in favour of their JSTL
Martin equivalents, and eventually being dropped. That won't happen any time soon,
Martin though, because we're still committed to supporting Servlets 2.2  JSP 1.1
Martin in Struts, for a while at least.

I recently submitted an enhancement recommendation, which is basically a
contrib library that I wrote, called Struts-EL.  It is basically the Struts
tag libraries, but with the attributes evaluated using the JSTL EL engine,
instead of rtexprvalues.  Due to the requirements of the JSTL, this could only
be used with a Servlet 2.3 and JSP 1.2 container.

While building this library, I had to evaluate which Struts tags could be
completely replaced by JSTL tags.  In those cases, I didn't port them to the
new library.  In some cases, I decided that even if a tag was similar between
the two libraries, the functionality available in Struts was important enough
to port.

 From the 'logic' taglib, I think these are the only ones which do not have
Martin JSTL equivalents:

Martin   logic:forward
Martin   logic:redirect
Martin   logic:messagesPresent
Martin   logic:messagesNotPresent

In particular, even though there is logic:iterate and c:forEach, I felt
there were features in logic:iterate that couldn't easily be provided by
c:forEach (even though c:forEach is still very convenient).

In addition, logic:match does not yet have an equivalent in the JSTL, as it
can't match on substrings yet.  My port of this tag (and notMatch) also added
an expr attribute, to allow arbitrary expressions, instead of just from
cookies, headers, parameters, or bean properties.

There is actually a c:redirect tag, but it's not as flexible as
logic:redirect, so that was also ported.

Martin and from the 'bean' library:

Martin   bean:resource
Martin   bean:size
Martin   bean:struts

Martin Actually, most of the bean:resource functionality is available in JSTL,
Martin but I think there are some corner cases which are not covered. I'm not sure
Martin if bean:cookie functionality is available in JSTL or not.

Using c:import instead of bean:resource only works if the resource is not
handled by a servlet.  The latter will give you the raw value of the resource,
the former will give you the output processed by a servlet.  If you really
EXPECT the output from a servlet, then c:import is perfectly fine (and more
flexible than bean:include, as it can specify URLs outside of your
application).

All of the set of bean:cookie, bean:header, and bean:parameter are
covered in JSTL, as references to objects of those types are directly available
in the EL, so you can just use c:set to get those values.

-- 
===
David M. Karr  ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Joe Barefoot]

That's a cool tag.  Another that I would be interested in is 
logic:doesNothaveSuccesor or  logic:isLast name=item, which will evaluate the 
tag body only if you've reached the last item in the Collection being processed by 
logic:iterate

 -Original Message-
 From: Christian Tschenett [mailto:[EMAIL PROTECTED]]
 Sent: Friday, September 06, 2002 4:32 PM
 To: Struts Users Mailing List
 Subject: Additional logic:iterate helper tags wanted
 
 
 Hi,
 
 I am new to this list and to struts and/but I miss an additional 
 logic:iterate helper tag. I think the following sample 
 describes what I 
 want:
 
 logic:iterate id=item name=items
  bean:write name=item/
  logic:hasSuccessor name=item %-- is item followed by 
 another item? --%
...is followed by...
  /logic:hasSuccessor
 /logic:iterate
 
 ...like...
 
 for (Iterator i = items.iterator(); i.hasNext(); ) {
   String item = (String)i.next;
   out.print(item);
   if (i.hasNext()) out.print(...is followed by...);
 }
 
 ...in java. Can this be done without additinal tags? I assume 
 other users are 
 also interested in a logic:hasSucceros-like tag and so I 
 implemented it. 
 You can download the patch from 
 http://www.tschenett.ch/~chrigi/iterate-helpers.tgz and add 
 it to the stuts 
 codebase if other users like this simple helper tag too.
 
 just my 2 cents,
 Chris
 
 
 --
 To unsubscribe, e-mail:   
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: 
 mailto:[EMAIL PROTECTED]
 
 

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Kenny Smith]

Hi,

I would suggest naming it logic:hasNext so that it follows the iterator
structure.

Kenny Smith

   logic:hasSuccessor name=item %-- is item followed
  for (Iterator i = items.iterator(); i.hasNext(); ) {
String item = (String)i.next;
out.print(item);
if (i.hasNext()) out.print(...is followed by...);
  }


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Martin Cooper]

If you're using a JSP 1.2 container (e.g. Tomcat 4.x, Resin 2.x), you can do
this (and many other cool things) using the JSTL c:forEach tag:

  c:forEach items=items var=item varStatus=status
c:out value=${item}/
c:if test=${!status.last}
  ...is followed by...
/c:if
  /c:forEach

This is a great reason to start getting familiar with JSTL. :-)

--
Martin Cooper


 -Original Message-
 From: Christian Tschenett [mailto:[EMAIL PROTECTED]]
 Sent: Friday, September 06, 2002 4:32 PM
 To: Struts Users Mailing List
 Subject: Additional logic:iterate helper tags wanted
 
 
 Hi,
 
 I am new to this list and to struts and/but I miss an additional 
 logic:iterate helper tag. I think the following sample 
 describes what I 
 want:
 
 logic:iterate id=item name=items
  bean:write name=item/
  logic:hasSuccessor name=item %-- is item followed by 
 another item? --%
...is followed by...
  /logic:hasSuccessor
 /logic:iterate
 
 ...like...
 
 for (Iterator i = items.iterator(); i.hasNext(); ) {
   String item = (String)i.next;
   out.print(item);
   if (i.hasNext()) out.print(...is followed by...);
 }
 
 ...in java. Can this be done without additinal tags? I assume 
 other users are 
 also interested in a logic:hasSucceros-like tag and so I 
 implemented it. 
 You can download the patch from 
 http://www.tschenett.ch/~chrigi/iterate-helpers.tgz and add 
 it to the stuts 
 codebase if other users like this simple helper tag too.
 
 just my 2 cents,
 Chris
 
 
 --
 To unsubscribe, e-mail:   
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: 
 mailto:[EMAIL PROTECTED]
 
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Additional logic:iterate helper tags wanted

[Christian Tschenett]

Hi,

logic:iterate id=item name=collection
...
logic:hasNext name=collection...
...or...
logic:hasSuccessor name=item...

...both variants are fine. But what about...

logic:iterate id=item name=aBean property=collection

...makes logic:hasNext name=aBean sense?

Chris

Am Samstag, 7. September 2002 01:38 schrieb Kenny Smith:
 I would suggest naming it logic:hasNext so that it follows the iterator
 structure.
logic:hasSuccessor name=item %-- is item followed
   for (Iterator i = items.iterator(); i.hasNext(); ) {
 String item = (String)i.next;
 out.print(item);
 if (i.hasNext()) out.print(...is followed by...);
   }


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Additional logic:iterate helper tags wanted

[Christian Tschenett]

Will the logic-taglib be deprecated in future? Which other struts tags can 
be considered as out of date?

Chris

Am Samstag, 7. September 2002 01:46 schrieb Martin Cooper:
 If you're using a JSP 1.2 container (e.g. Tomcat 4.x, Resin 2.x), you can
 do this (and many other cool things) using the JSTL c:forEach tag:


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: Additional logic:iterate helper tags wanted

[Martin Cooper]

When using a JSP 1.2 container, the functionality of most of the 'logic'
tags and some of the 'bean' tags is available using JSTL. Since JSTL is a
standard, containers will (and do) include optimised implementations of it
which will inherently be faster than the Struts tags.

Over time, you'll see Struts tags being deprecated in favour of their JSTL
equivalents, and eventually being dropped. That won't happen any time soon,
though, because we're still committed to supporting Servlets 2.2  JSP 1.1
in Struts, for a while at least.

From the 'logic' taglib, I think these are the only ones which do not have
JSTL equivalents:

  logic:forward
  logic:redirect
  logic:messagesPresent
  logic:messagesNotPresent

and from the 'bean' library:

  bean:resource
  bean:size
  bean:struts

Actually, most of the bean:resource functionality is available in JSTL,
but I think there are some corner cases which are not covered. I'm not sure
if bean:cookie functionality is available in JSTL or not.

One thing to bear in mind is that, in many cases, the JSTL tags that cover
Struts tags functionality actually expand on that, and give you more options
and greater flexibility. The c:forEach tag is a great example.

plug
  Buy Shawn Bayern's book, JSTL in Action.
  It's great for learning this newfangled JSTL stuff.
/plug

--
Martin Cooper


 -Original Message-
 From: Christian Tschenett [mailto:[EMAIL PROTECTED]]
 Sent: Friday, September 06, 2002 4:52 PM
 To: Struts Users Mailing List
 Subject: Re: Additional logic:iterate helper tags wanted
 
 
 Will the logic-taglib be deprecated in future? Which other 
 struts tags can 
 be considered as out of date?
 
 Chris
 
 Am Samstag, 7. September 2002 01:46 schrieb Martin Cooper:
  If you're using a JSP 1.2 container (e.g. Tomcat 4.x, Resin 
 2.x), you can
  do this (and many other cool things) using the JSTL c:forEach tag:
 
 
 --
 To unsubscribe, e-mail:   
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: 
 mailto:[EMAIL PROTECTED]
 
 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]