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

Reply via email to