well, the way i invision it is that for each type of table, you'd implement
a DataSet. obviously, if the data is coming out of a database, it will be
entirely dependent on what db you're using and what your table structure is.
think of it like this (i use struts, so this will be in struts terminology,
but the idea applies for any MVC framework).
in your action, you find out which type of data the user wants, say they're
looking for red widgets. you instantiate a object that implements DataSet.
you can construct it in some way that it knows to search for red widgets,
for examples DataSet ds = new MyDataSet(ProductType.WIDGET,
ProductVariant.RED);
then you stick that object in the request scope [ request.setAttribute("ds",
ds); ], and forward to your view. then in the view you have your displaytag:
<display:table name="ds"> ... </display:table>
in the TableTag class, it would tell the DataSet what the sort and paging
is. then it calls DataSet.getHtmlData(), and then at that point, the DataSet
will go out to the database and fetch the data.
so you'd have different DataSets for different tables, all they would know
how to do is fetch some data that they were told to fetch given a sort and
page.
--alex
> Date: Fri, 16 Apr 2004 12:09:55 -0400 (EDT)
> From: John York <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]>
> Subject: Re: [displaytag-devel] Accepting large datasets (was:
> why iterator
> over undisplayed rows?)
> Reply-To: [EMAIL PROTECTED]
>
> 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
>
-------------------------------------------------------
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
