Re: New interface for #foreach-able objects?

[Christoph Reck <Ch...@dlr.de>]

+1, Paulo has the right view. Either leave the current Iterator
usage or add some pluggable introspectors. If Geir agrees, then
whoever feels the itch can scatch it first! Geir if you give it
a +1, then you are allowing someone else to implement it - we
know you hane done *great* work with velocity and its support,
but we don't expect you to scratch everyones itches. Once 
someone has implemented it, you can review it and commit it.

Things like this could flow into the TODO list, if a consensus
has been reached trough voting.

:) Christoph

Paulo Gaspar wrote:
> 
> I use an Iterator wrapper just for the exact same end described in
> the initial post of this thread: rendering a large ResultSet.
> 
> I even use it for multi megabyte XML exports.
> 
> However, I also thing that what I did is a hack.
> 
> Having a magic interface is also quite shity, because it forces
> you to either:
>  a) Bind general use classes to the Template Engine by making
>     them implement that magic interface;
> 
>  b) Wrap the things you want to loop trough, which is not always
>     as trivial as it sounds when you use complex object models.
> 
> There is only a clean solution I am aware of: a customizable
> introspector that gets a "VelocityIterator" from any object used
> as target of a #foreach.
> 
> The default introspector would just implement the current
> #foreach behavior.
> 
> (I even think that introspectors should be customizable for
> everything.)
> 
> Have fun,
> Paulo Gaspar
> 
> > -----Original Message-----
> > From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> > Sent: Sunday, March 17, 2002 6:20 PM
> > To: velocity-user@jakarta.apache.org
> > Subject: Re: New interface for #foreach-able objects?
> >
> >
> > On 3/17/02 11:22 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> >
> > > On : Saturday, March 16, 2002 7:32 PM "Geir Magnusson Jr."
> > > <ge...@optonline.net> wrote:
> > >> On 3/15/02 8:17 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> > >>
> > >>> "Darren Gilroy" <DG...@CONSONUS.com>, Friday, March 15,
> > 2002 11:35 PM:
> > > [snip]
> > >>> I would like to emphasize that using the new interaface is absolutely
> > >>> optional. You can use Collection as earlyer, but when you "feel
> > > occasionally
> > >>> frustrated" you can use the new interface.
> > >>> Then, about extending AbstractCollection... The problem with
> > Collection
> > > is
> > >>> that the size method is not optional. Foreach inherently
> > don't need the
> > >>> size. Despite of that you are forced to implement it, and sometimes it
> > > can
> > >>> be hard if not even impossible.
> > >>
> > >> Why don't you just make one wrapper that behaves how you want
> > and be done
> > >> with it? I don't see why the core has to change to support
> > that wrapper.
> > >
> > > My wrapper must be an Iterator or Enumeration or some
> > collection framework
> > > class, or else foreach can't use it. The problem is exactly that I can't
> > > construct a suitable wrapper using there classes:
> > > a) I can write an abstract class (wrapper), which is an Enumeration, and
> > > calls beginLoop on the first nextElement call, and calls endLoop when
> > > hasMoreElements returns false. Thus, I can made an Enumeration
> > which reset
> > > itself automatically at the en of foreach loop. The problem
> > with it is that
> > > any code is right when it assumes that when hasMoreElements
> > returned false,
> > > no nextElement will ever return an element. So if  I write an
> > Enumertaion
> > > which does not behave as it should to (thus, violates Java API), I can't
> > > expect predictable behaviour from the code that uses it (in this case,
> > > Velocity).
> > > b) The other possibility is to use some short of collection as
> > base class of
> > > my wrapper. The problem here is the size() merhod, as it was
> > explained in
> > > details in another mail.
> > >
> > > So I can't find a way to write a *generic* wrapper that gives
> > the deisred
> > > functionality and ueses the interfaces/classes supported by #foreach.
> >
> > So the problem, which is specific to your use of Velocity, requires a
> > *generic* wrapper?
> >
> > Yet, you propose support of a non-generic interface as the solution?
> >
> > I don't quite get it.
> >
> > > Perhaps I miss something. But even if such a wrapper is
> > possible, the point
> > > is that an interface designed for #foreach would be still "nice". I hate
> > > awkward workarounds and hacks.
> >
> > I think "awkward workarounds and hacks", like beauty, justice, truth, and
> > quality, is mostly the eye of the beholder.
> >
> > --

-- 
:) Christoph Reck

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>