I prefer (3) because it makes the loop behave in exactly the same way as it
would in any other language.
I don't like (2) at all because it removes information (the null values)
that is likely to have been included in the collection for a reason. Also,
if the iterate tag is ever extended to support ResultSets it is almost
inevitably going to have to handle null values.
> -----Original Message-----
> From: Nick Pellow [mailto:[EMAIL PROTECTED]]
> Sent: 05 March 2001 03:50
> To: [EMAIL PROTECTED]
> 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
>
