I've built a nifty component which uses a vertical scrollbar to transition between pages on a table which is then updated asynchronously to show the new page. It looks something like the liveGrid thing from Rico, although mine still needs a lot of polish before it works quite as well.
It still needs to do things like row level scrolling instead of just transitioning between entire pages, but to do that will also likely require some amount of caching in the client and possibly a modification to the ITableModel interface. It also needs general look and feel touches like giving indication that work is occuring, updating an element with the current page number during the scroll, various and sundry other little details. But the core functionality is there. Currently, it is only verified to work on Firefox. My test app doesn't work in IE for reasons that aren't related to the grid (IE and Safari aren't doing async updates correctly in the version of tap 4.1 I'm using, which is a couple of weeks old), but it probably needs some tweaking to work everywhere. It uses the native scrollbar of the browser by just setting up a tall div inside a height constrained div, so there will probably be look and feel issues, initially. I'm still just starting to play around with Tap 4.1, so if there is someone else out there who would like to help me with this thing, I'd sure appreciate it. I'll get it posted to sourceforge or somewhere in the next day or two. It is surprisingly little code, currently. A tiny dojo widget, a wrapper component similar to contrib:table, which wraps TableView, TableColumns, etc, and a Scrolling component which replaces the TablePages component. Currently, it is only about 300 lines of code for everything. And Jesse, Tap 4.1 really is an enormous leap forward for Tapestry's usability in a (forgive me for saying it) 'web 2.0'/rich-client environment. I'm not finding a lot lacking in functionality, but there is still some work necessary getting some things documented and providing simpler api access to some things (I'll be writing up some docs on adding an external dojo module sometime this week). The biggest difficulty, for me, seems to be when dealing with components that have a client id that doesn't match the component id. I am still not quite sure how to go about setting things up correctly when that circumstance occurs. I usually just wind up wrapping the misbehaving component in an @Any div and using the id of that div, but if that were in a loop, I'm still not sure how it would work. Some mechanism for specifying a different client id for the javascript side of the update would be really handy. Maybe its there and I didn't spot it. The other question that I haven't answered for myself yet is how to go about instantiating dojo widgets correctly in the Tapestry way. I usually just put a div in the html body, then use dojo.widget.createWidget to replace that div with the widget. Unfortunately, using tapestry.synchronizeWidgetState doesn't seem to make this possible. I don't want to do the node replacement after the create, since then any dynamically sized components won't be the correct size when postCreate() or fillInTemplate() are called. Oh, and it sure would be cool to be able to pass parameters to an EventListener, but I'm pretty sure I'm not going to be the first person to say that ;-) Then I'd be able to attach an EventListener directly to the onPageChange event of my dojo widget, rather than having to falsify a DirectLink. --sam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]