[albatross-users] pagination with al-for

[Dave Cole]

On Tue, 2004-01-06 at 13:13, Andrew McNamara wrote:
> >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.

Greg (on holidays at the moment) has implememted this already using the
current capabilities of Albatross.  He gets back on Monday - I should
ask him to post the details of how he did this.

> >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?

Nice.  It would lead to simplification of the current codebase I
suspect.

> 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?

Andrew and I have discussed this a number of times.  I think that the
easiest and least disruptive thing is to require the page modules to
work as a standard Python module/package import.  This will stop the
sys.modules pollution that is currently happening.

Andrew pointed out that the execfile() method has the disadvantage of
breaking pickling/unpickling of classes defined in page modules.  I am
inclined to say "just don't do that then", but he is more conservative
regarding breakage.

> >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.

One thing that makes some changes hard for us is that we are concerned
about changing existing functionality in a way that breaks someones
code.  When you make a private fork you only need to concern yourself
with code you have control over.

- Dave

-- 
http://www.object-craft.com.au