(1) This would be fine with me. Given that there seem to be as many opinions
on this subject as people expressing them, perhaps this would be the
expedient choice for 1.0.
(2) I don't like this because of the disparity between the number of
iterations and the size of the collection. The <bean:size> tag becomes
somewhat less useful.
(3) I believe this is the best of the "do something" options. It effectively
documents the issue and provides a simple way of handling it.
(4) This sounds like a pretty bad idea. :-}
(5) I really don't like this. It makes me think of Perl's "There's More Than
One Way To Do It" slogan. IMHO, having more options is not always better.
--
Martin Cooper
----- Original Message -----
From: "Nick Pellow" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 04, 2001 7:50 PM
Subject: Re: Iterating over collections with null values
>
>
> "Craig R. McClanahan" wrote:
> >
> > Bugzilla bug report #706 reports that you will get a JSP page exception
> > when you try to iterate over collection that contains null values. This
> > is caused by the fact that the JSP page context refuses to allow null
> > attributes. The bug report suggests one alternative (although the
> > proposed implementation has problems), but I would like to solicit
> > suggestions and thoughts on what the correct behavior should be.
> >
> > Here are the alternatives that I can think of:
> >
> > (1) No change -- document a restriction in the usage notes
> > on the <logic:iterate> tag.
> >
> > (2) Silently skip this element of the iteration, with no notice
> > to the surrounding page. The total number of times through
> > the loop, from the perspective of the page, will be less than
> > the size of the underlying collection.
> >
> > (3) Do not skip this element, but don't add it to the page context
> > either. The page can then use <logic:notPresent> to test for
> > whether the item is actually there or not.
> >
> > (4) Do not skip this element, but insert a reference to a dummy
> > object instead of the null. This is likely to cause class cast
> > exceptions, and is unlikely to be practical when the iteration
> > explicitly includes a "type" attribute.
> >
> > (5) Other alternatives I have not thought of?
>
> (5) Add an attribute(s) on the iterate tag that allows the user to
> decide between (1), (2) and (3). Defaulting to (1).
>
> >
> > All of the listed alternatives have their problems, but I am currently
> > leaning towards (1). Comments? Suggestions?
> >
> > Craig McClanahan
