Scott Russell wrote: > On Wednesday 05 July 2006 01:28 pm, Rick Herrick wrote: > <snip> >> As far as displaytag goes, though, it has no inherent ability to do >> this. >> Its job is to display the list, not manage the list through a user >> session. > > I understand this philosophy but it seems really limit the usefulness > of the library.
You're right. For example, the fact that the developers have not added the ability to make me some toast has really limited the usefulness of displaytag for me. I mean, I could have it display my data AND bring me some toast! I'm not trying to be a jerk, just making the point that, yes, it does limit the usefulness of the library, but for a very good reason: to focus on performing the display task well, reliably, and without a lot of ways in which things can go wrong. > The philosophy works if you can say that I'm going to > display data that is an island unto itself. But once you place it into > a working site where users expect interaction between pages, not > knowing the last state of things as seen by displaytag case be > problematic. In this case (and I've run into a similar situation) having > to mimic the UI's paging & sorting mitigates the benefits that drew > me to using the tag library in the first place. In other words, if I have > to sort and page the data so I know the list that the user last saw, for > processing on another page (in this case an update page...which > must be somewhat common item since it's the same issue I've run > into), then I've lost some of the benefit of using displaytag. But you don't have to do that stuff. I've created displaytag tables that include nested tables, drill-down links, item edit pages (an update page like you're referring to), and all kinds of stuff. When you say "I've lost some of the benefit of using displaytag," I think what you're really saying is "I've lost the benefit of stuff that I wish was in displaytag." Cache the display attributes, go off to your edit page, and have your return link go back to the table with the cached display attributes. If you add the ability to do all kinds of state management to displaytag, then you're talking about a data management framework. I don't remember when/where I read it, but one of the creators of displaytag explicitly said that they didn't want to create that sort of thing. It's simply out of the scope of what displaytag is. > As I was rewriting and editing that last paragraph it hit me that maybe > the best way to deal with this situation is to write a table decorator > that > "records" into the session the list of items currently displayed. > > table decorator: > constructor(): > clear/create session array/list variable with the required > number > of entries per row. Looks like that can be obtained via > tableModel -> getProperties() -> getPagingGroupSize() > startRow(): > use getViewIndex() to know the row and getCurrentRowObject() > to get the data for that row. save in the list saved in the > session. > > a list of hashCode's should be workable I should think. The same technique > may also be useful in tracking sorting/paging. I'm not really sure what you're trying to do with this. I thought you wanted a drill-down to an edit page and return to the table in the state that it was in before drill-down. You really don't need something as complicated as a table decorator for that. -- Rick Herrick [EMAIL PROTECTED] I haven't got time for inner peace. "No reasonable definition of reality could be expected to permit this."--Albert Einstein, Boris Podolsky and Nathan Rosen in 1935 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ displaytag-user mailing list displaytag-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/displaytag-user
