Hi accidentally posted to wrong list i think (displaytag-devel which appears to be jira generated.) So this is a repost:
I been using display tag library for a while now. And its great for throwing together little tables and decorating them but no library is perfect. One thing has bothered me for long time: 1 Inability to export Totals. 2 Inability to decorate Totals using same decorator as the rows. So using svn trunk I wrote some code to get around that. The code is a bit hacky and I would like to be advised on how to do this better. But current implementation basically gets all the rows after it is sorted. It iterates over it and computes totals (on numbers as best it can) and append the row back into the row list. Then the table displayed properly with totals row appears just like data row because its now is a data row! And it exports properly too! The problem that I run into at this point is that data row can be all kinds of classes, hashtabes and what have you. The decorators expect a particular class/hashtabe to be given to them that matches exactly with the rows. So at this point I use the standard Bean API to create a class with the same type as one of the rows then I use the Bean API to populate the row real totals data. I am not exactly sure where the code should live for the last totals row in code. But i am pretty sure there is no other way around creating fake row wrapped as Beans that are passed to the decorators that expect them to be a particular type. I am not using the existing totals magic. I find it a bit more hacky then my method because its some thing at table level instead of row level and they don't export (because being footer HTML) and they don't decorate well (why wrote custom footer decorators when you already have one?) and then don't play nice if the number of columns vary in the table being "magically" named column#. If number of columns changes this just creates a mess. If some fields don't exist in the row but only in the decorator this creates a mess. All of this my code solves (or aims to solve). Dropping a huge patch into an open source project usually is not welcomed without some design decisions on the part of the community. Then lets talk and work together! I'll provide code to your spec while it solved my pains. Thanks, Treeform ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ displaytag-user mailing list displaytag-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/displaytag-user
