On Wednesday 05 July 2006 05:13 pm, Rick Herrick wrote:
> > I'm not trying to be a jerk,
but you did such a good job of it. <g>
> > 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.
Actually, having displaytag to indicate it's current state doesn't hinder
it's ability to display data. Making me toast, now there I can see where
things could go wrong there.
There seems to be a request on this list about once every other week
for some sort of persistance related issue. We can continue to say that
"sorry, that's beyond our scope" or realize that there is an unmet need
of the user community. These requests are not asking for displaytag
to manage the list {which would be out of scope of the of the library
and usually the line that's given}, but there is a real world requirement
to have some means of knowing what displaytag has done with the list.
It's sorting/paging state. And in the case of the original post here, a
list of entries currently being displayed.
<snip>
> > 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.
Yes...and no. I mean, I DO have a requirement to have sorting persist, BUT...
...as the original post indicated, the requirement we're really talking about
here is to be able to navigate the list of entries shown in the displaytag
table,
from another page {edit in this case I believe}. That post only talked about a
"next button", in my case I actually need previous & next buttons. The idea
being that we don't want to force the user to go to an update screen, make
their updates, return to the table, select another entry, go to the update
screen, make their updates...very tedious. However, if the update page had
navigation control, the user experience is greatly enhanced. And no, it's not
enough to just loop thru the entries. This isn't shlock.com, the entries need to
be presented in the same way that displaytag is displaying them.
So, the {IMHO} ostrich-head-in-the-sand philosophy of pretending that
displaying the table data is an island all to itself, hinders it's use...at
least
in cases like mine. And given that someone else within a month of my
requirement has the same basic need, I'd say it's not a totally atypical.
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
