iBATIS (http://www.ibatis.com) has a similar concept already implemented
called com.ibatis.common.util.PaginatedArrayList. It implements
java.util.Collection and java.util.List as well as
com.ibatis.common.util.PaginatedList, which defines these methods:
nextPage(), previousPage(), gotoPage(), isFirstPage(), isMiddlePage(),
isLastPage(), etc.
You define the number of elements on a page and it will give you an
iterator which only iterates across the current page.
Also, if you'd prefer to get pages from the persistence layer as they are
requested (instead of returning all rows at once) you can use
com.ibatis.db.sqlmap.PaginatedDataList which implements the same
interfaces.
Not that displaytag should be tied to iBATIS, but on the other hand it
seems to me that the type of feature being requested is more of a
persistence layer issue than a display issue. In other words, by the time
the Collection gets exposed to displaytag, it should already be in a
manageable form. The business logic / objects which perform this
management, in my opinion, fall outside the scope of a tag library.
The tricky part is what to do about auto-sorting by column. Perhaps
displaytag could offer a stub interface method which gets called when the
user asks to sort by a different column (to override the internal sorting
logic), which developers could implement with calls into the persistence
layer. This would allow a well designed application to get only 1 page at
a time from the database, allowing the database to do the sorting and
cutting down on overhead in the middle tier.
So, in conclusion, I think iBATIS can already do alot of what is being
asked for.
Chris.
> This sounds like a good idea. I've been thinking about various ways to
> implement this as well. I think I agree with most of this. I think that if
> we made the DataSet object implement the Iterator interface, we could
> encapsulate all the database paging/sorting code in that object, and the
> TableTag still just treats it as an Iterator, which would mean very
> minimal changes to the existing code.
>
> The only problem I see with this approach is that the implementation will
> be tied to the database you are using. Each database may handle
> paging/sorting differently, so that will need to be taken into account.
> Maybe what you end up doing is creating a set of DatabaseDriver classes,
> that could control any of the per-database oddities. You could try
> sticking to the SQL spec, but there will always be more efficient ways to
> perform these operations with database-specific addons.
>
> I'd still like to split out the different functionalites of this tag into
> at least 3 or 4 groups:
>
> 1. displaying data
> 2. paging data
> 3. sorting data
> 4. decorating data
>
> If we could do this, then each piece could be extended for user-specific
> things, and we could provide all the common things with the binary
> distribution.
>
> Just my $.02 as always...
>
> John
>
>
> On Fri, 16 Apr 2004, Alex Burgel wrote:
>
>> ok, i see.
>>
>> this design makes it almost impossible to handle large data sets.
>> especially
>> things coming out of a database. i've been thinking about some ideas to
>> get
>> around this. i'll just throw them out here to get some comments. my
>> apologies if these have been brought up before, i'm new to the list.
>>
>> the trouble with dealing with large datasets is that many of the
>> features
>> that the tag provides are more efficiently handled outside. like sorting
>> and
>> paging are better handled inside a database. but thats only for things
>> that
>> comes from a database, for everything else, its useful that the tag does
>> it
>> for you. so any solution would mean that you have to support both ways,
>> having the db do these things and having the tag do it.
>>
>> the idea is to factor out all the handling of the data into a separate
>> interface, maybe called DataSet. users could provide different
>> implementations of the interface that could interact with their database
>> to
>> do the sorting, paging, etc.
>>
>> the TableTag would be modified to accept either a list or an object
>> implementing the above interface. if it gets a list, then the TableTag
>> would
>> use a default implemenation of the interface, otherwise it would just
>> use
>> the object. you would move all the TableModel stuff inside the default
>> implementation.
>>
>> so the TableTag methods would look something like this:
>>
>> doStartTag() {
>>
>> Object data = ... get from jsp tag attribute 'name'
>> dataSet = null;
>>
>> if (data instanceof DataSet)
>> dataSet = data
>> else if (data instanceof List)
>> dataSet = new DataSetListImpl(list)
>>
>> dataSet.setSort(sort)
>> dataSet.setPage(page)
>> dataSet.setPageSize(pagesize)
>>
>> return doIteration();
>> }
>>
>> doIteration() {
>> # very similar to current impl
>> # except it gets the next object from the dataSet
>> # but all the TableModel stuff is internal to DataSet
>>
>> # the dataSet can choose to have all the rows iterated over
>> # or it can have only the ones that i knows will be displayed
>> # since it already knows the paging information
>> }
>>
>> doEndTag() {
>> out.print(dataSet.getHtmlData())
>>
>> # or export it in another format
>> }
>>
>> since dataSet already knows what the page size and sorting, etc. is, it
>> knows which html data to display.
>>
>> i'm sure there are tons of things that i've missed. but my point is to
>> move
>> a lot of these things to a user provided object so people with larger
>> datasets can do optimizations, while providing a default implementation
>> for
>> people who just have a simple list.
>>
>>
>> btw, i'm happy to implement this, if people think it would be of some
>> use.
>>
>> --alex
>>
>> > Date: Thu, 15 Apr 2004 12:50:26 -0400 (EDT)
>> > From: John York <[EMAIL PROTECTED]>
>> > To: "[EMAIL PROTECTED]"
>> > <[EMAIL PROTECTED]>
>> > Subject: Re: [displaytag-devel] why iterator over undisplayed rows?
>> > Reply-To: [EMAIL PROTECTED]
>> >
>> > sorting. You need to look at all the data otherwise you can't sort the
>> > data or provide the sorting links in the table headers.
>> >
>> > We run into the problem all the time at my company, because we'd
>> really
>> > like a more efficient way to handle large sets of data. It may be
>> > possible
>> > to optimize the tag when sorting isn't used, Fabrizio, do you have any
>> > idea if that would work?
>> >
>> >
>> > On Thu, 15 Apr 2004, Alex Burgel wrote:
>> >
>> > > hi,
>> > >
>> > > i've been playing around with displaytag, trying to get it to
>> > work with my
>> > > set up. i have a question about its design.
>> > >
>> > > in TableTag, it seems to iterate over all the items in the list
>> > to populate
>> > > the TableModel. once its populated, in doEndTag() it finds out
>> > which ones
>> > > are being displayed and then writes them out.
>> > >
>> > > it seems a bit unnecessary to do all this extra processing for
>> > the rows that
>> > > won't be displayed, especially since at the point of doStartTag
>> > you already
>> > > know which rows will be displayed because you know the page
>> > size and which
>> > > page you're on.
>> > >
>> > > is there a reason for this that i'm not seeing?
>> > >
>> > > the reason i ask is because i'm trying to come up with a way to
>> > allow the
>> > > tag to accept partial lists but still provide all the features
>> > like paging,
>> > > etc.
>> > >
>> > > thanks.
>> > >
>> > > --alex
>> > >
>> > >
>> > >
>> > >
>> > > -------------------------------------------------------
>> > > This SF.Net email is sponsored by: IBM Linux Tutorials
>> > > Free Linux tutorial presented by Daniel Robbins, President and CEO
>> of
>> > > GenToo technologies. Learn everything from fundamentals to system
>> > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> > > _______________________________________________
>> > > displaytag-devel mailing list
>> > > [EMAIL PROTECTED]
>> > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel
>> > >
>> >
>> > --
>> > John York
>> > Software Engineer
>> > CareerSite Corporation
>> >
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> displaytag-devel mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/displaytag-devel
>>
>
> --
> John York
> Software Engineer
> CareerSite Corporation
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> displaytag-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/displaytag-devel
>
>
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
