> > It also occurs to me that the decorator-based pagination only supports
> > the notion of a page where you have one bit of pagination going on and
> > nothing else really happening (unless you use ajax).
>
> Yep.  It only paginates. :-)  It doesn't sort, etc.
>

It does sort when using the provided PaginateDataGrid, there's an
example on the demo project.

Somewere it was mentioned that it does 2 queries, the first is a count
used to build the page list. If it's needed it would be easy to add an
option to just display a "prev | next" button so we only need 1 query.
This would be necesary, for example, when paginating a ResultSet from a
big InnoDB table (sloooow counting).

As for SQLAlchemy, never worked with it, but it shouldn't be difficult
to implement, just adding a new "isinstance" to do the ordering,
reversing and limiting would do the work. Var_data isn't touched
anymore after that, so we can even move that into the SO/list()
condition if SA doesn't support silicing.

It's also possible to make the decorator stackable by adding some
prefix to the variable it uses (from the paginated var) and making
tg.paginate a dictionary (or maybe tg.paginate.foo). It would be
possible to have 2 or more sortable/paginated lists on the same view
that don't reset each other. (ex: you can be viewing page 5 from the
list A and clicking page 10 on the list B would still display the list
A at page 5).

--
Claudio


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---

Reply via email to