[albatross-users] pagination with al-for

[Andrew McNamara]

>This has come up a few times here as well.  The iterator class used
>doesn't have the methods needed for this.  We have talked about how we
>could add firstpage, lastpage, and gotopage methods into the class.

Yes - it needs this.

One complicating factor is that we really should make the ListIterator
work with python iterators in simple cases (no pagination, I guess).
I need to apply more thought to this problem.

>I would have had this in my Axe extensions already, but it's not as
>simple as adding an alx-for tag.  You would also have to do an
>alx-input, alx-img, and alx-a tag for the attributes to work.  That's
>getting messy.  It would be better to patch albatross to put in this
>support natively.

Indeed. BTW, I rarely use the alx- stuff, usually just overriding or
subclassing built in stuff where I need a feature that isn't in the core
for some project. I guess the two approaches solve different problems.

>It does highlight a design issue in albatross as well, since any other
>additions of this nature would also affect several tags.  We have talked
>about instead of using custom attributes for each method, i.e.
>nextpage="i", there would be a generic attribute "action", which could
>work like action="i.nextpage()" - which would allow custom tags an
>eassier time of adding features along these lines.

Yeah. I like that idea. Dave?

>Adding this is next on my list, just awaiting a response on the last
>patch I sent in (I don't want to get into a version nightmare of pending
>patches, lol).

Sigh - remind me what that patch was for? Sorry - been preoccupied with
other work. If we're talking about the page module loading stuff, I'm
still concerned that none of the proposed solutions are entirely "clean"
(backward compatible and tasteful).

I seem to remember that the thread started because someone discovered
that page modules didn't honour the usual python module heirarchy stuff
(so a page module couldn't be called "foo.bah"). The path of least
resistance might be to simply fix this?

>Actually, since we have standarized development on Albatross we have
>talked about going with our own "fork" of the project adding this and
>other items mentioned on the Wiki like added macro features.  Because
>we've standarized on it, I can put development time to it, and of cource
>would make all our changes available.  I do have a concern with this
>though, I don't want to "fragment" the project.  I'd have to do it with
>the catch that if the OC guys added a feature to albatross that I'd drop
>it from the fork and use the albatross version - even if it broke
>backwards compatibilty within the fork.  We already are setup to have each
>site with it's own albatross copy, so new version don't break old sites
>(*cough* files *cough*), so this is okay for us.

Working code (in the form of patches) always carries more weight than
proposals, even if the code needs cleanup before being applied.

We need a faster release cycle. It's actually not that hard for us to
bundle up a release - what takes time is updating the doco and tests.
Doco and test patches are certainly less glamerous, but they will be
received with enthusiasm from me, at least.

There was some suggestion of setting up a public CVS pserver - I'm a
little concerned about the security side of this. How useful would a
tarball containing a daily snapshot of the CVS tree be? Would it be
necessary to provide older snapshots, or just the latest?

Looking at it from a support point of view, it's actually better to
have explicit releases - if someone is running some arbitary snapshot,
all bets are off. It's fairly easy for us to manage the fuzz of applying
a patch made against, say, 1.11pre2 to the CVS head.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/