You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Sam Gendler <sg...@ideasculptor.com> on 2006/11/13 09:03:15 UTC

tapestry live grid functionality announcement

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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org