From neel at mediapulse.com Thu Jan 1 03:25:04 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Wed, 31 Dec 2003 11:25:04 -0500 Subject: [albatross-users] pagination with al-for Message-ID: 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. 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. 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. 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). 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. I'm open to all thoughts on this, good and bad. Mike > -----Original Message----- > From: Sheila King [mailto:sheila at thinkspot.net] > Sent: Wednesday, December 31, 2003 3:15 AM > To: albatross-users at object-craft.com.au > Subject: [albatross-users] pagination with al-for > > > Hello, > > I've set up a portion of my app that displays some log results with > pagination (assuming that there are more log entries than the > page size > I've set). > > It wasn't too hard to get the prevpage/nextpage links > working, so that I > can page forward or backward through the entire sequence display. > > However, I like to be able to jump directly to a particular page. > > For example, if pagesize is 6, and there are 26 entries, and > thus 5 pages... > > How would I best display a list of page numbers so that I can click > directly on a given page number and go to that list of six items? > > I started to think maybe I need to go to trees for this? > > Well, hoping for tips or suggestions. > > Thanks, > > -- > Sheila King > http://www.thinkspot.net/sheila/ > http://www.k12groups.org > > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat ross-users From tchur at optushome.com.au Thu Jan 1 09:01:05 2004 From: tchur at optushome.com.au (Tim Churches) Date: 01 Jan 2004 09:01:05 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: References: Message-ID: <1072908065.2099.23.camel@emilio> On Thu, 2004-01-01 at 03:25, Michael C. Neel 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. Just to second (or third) Sheila's and Mike's wishes for more sophisticated pagination facilities. The next phase of our work with Albatross (the work is primarily on an epidemiological analysis and reporting facility) will require this. Since Andrew McNamara will be working on this (the analysis facility) under contract, starting very shortly, it seems like a good opportunity to get these features into the core Albatross distribution. Cheers, Tim C > > 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. > > 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. > > 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). 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. > > I'm open to all thoughts on this, good and bad. > > Mike > > > -----Original Message----- > > From: Sheila King [mailto:sheila at thinkspot.net] > > Sent: Wednesday, December 31, 2003 3:15 AM > > To: albatross-users at object-craft.com.au > > Subject: [albatross-users] pagination with al-for > > > > > > Hello, > > > > I've set up a portion of my app that displays some log results with > > pagination (assuming that there are more log entries than the > > page size > > I've set). > > > > It wasn't too hard to get the prevpage/nextpage links > > working, so that I > > can page forward or backward through the entire sequence display. > > > > However, I like to be able to jump directly to a particular page. > > > > For example, if pagesize is 6, and there are 26 entries, and > > thus 5 pages... > > > > How would I best display a list of page numbers so that I can click > > directly on a given page number and go to that list of six items? > > > > I started to think maybe I need to go to trees for this? > > > > Well, hoping for tips or suggestions. > > > > Thanks, > > > > -- > > Sheila King > > http://www.thinkspot.net/sheila/ > > http://www.k12groups.org > > > > _______________________________________________ > > Albatross-users mailing list > > Albatross-users at object-craft.com.au > > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat > ross-users > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sheila at thinkspot.net Fri Jan 2 15:02:13 2004 From: sheila at thinkspot.net (Sheila King) Date: Thu, 01 Jan 2004 20:02:13 -0800 Subject: [albatross-users] pagination with al-for In-Reply-To: <1072908065.2099.23.camel@emilio> References: <1072908065.2099.23.camel@emilio> Message-ID: <853719944.1072987333@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> --On Thursday, January 01, 2004 9:01 AM +1100 Tim Churches wrote: > On Thu, 2004-01-01 at 03:25, Michael C. Neel 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. > > Just to second (or third) Sheila's and Mike's wishes for more > sophisticated pagination facilities. The next phase of our work with > Albatross (the work is primarily on an epidemiological analysis and > reporting facility) will require this. Since Andrew McNamara will be > working on this (the analysis facility) under contract, starting very > shortly, it seems like a good opportunity to get these features into the > core Albatross distribution. > > Cheers, > > Tim C > >> >> 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. ...... >> I'm open to all thoughts on this, good and bad. >> >> Mike Well, I would very much look forward to seeing this functionality incorporated into Albatross, and I do agree that it should be included. However, I'm going to have to go ahead with my own solution in the meantime, as the project I'm working on can't wait for a "someday soon" solution. Gotta move on and do whatever I can to get my project going and done. So, either I will have to do some sort of extension with albatross tags, as Mike mentioned. However, I keep thinking that al-tree might do the trick for me here. I could take my sequence of log entries, and parse it up myself into pages and let each page of entries be a tree node and the list of entries on that page be the children? I haven't played with albatross tree objects yet, but unless I am totally off the mark here, it seems that this may be the easiest solution for me given the current albatross functionality? If I am totally off the mark, could someone please slap me quick and set me straight here? Thanks, -- Sheila King http://www.thinkspot.net/sheila/ http://www.k12groups.org >> > -----Original Message----- >> > From: Sheila King [mailto:sheila at thinkspot.net] >> > Sent: Wednesday, December 31, 2003 3:15 AM >> > To: albatross-users at object-craft.com.au >> > Subject: [albatross-users] pagination with al-for >> > >> > >> > Hello, >> > >> > I've set up a portion of my app that displays some log results with >> > pagination (assuming that there are more log entries than the >> > page size >> > I've set). >> > >> > It wasn't too hard to get the prevpage/nextpage links >> > working, so that I >> > can page forward or backward through the entire sequence display. >> > >> > However, I like to be able to jump directly to a particular page. >> > >> > For example, if pagesize is 6, and there are 26 entries, and >> > thus 5 pages... >> > >> > How would I best display a list of page numbers so that I can click >> > directly on a given page number and go to that list of six items? ...... From tchur at optushome.com.au Fri Jan 2 15:16:05 2004 From: tchur at optushome.com.au (Tim Churches) Date: Fri, 02 Jan 2004 15:16:05 +1100 Subject: [albatross-users] pagination with al-for Message-ID: <200401020416.i024G5Z21680@mail022.syd.optusnet.com.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From andrewm at object-craft.com.au Tue Jan 6 13:13:33 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 06 Jan 2004 13:13:33 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: Message from "Michael C. Neel" of "Wed, 31 Dec 2003 11:25:04 CDT." References: Message-ID: <20040106021333.BB0E53C131@coffee.object-craft.com.au> >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/ From andrewm at object-craft.com.au Tue Jan 6 13:27:16 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 06 Jan 2004 13:27:16 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: Message from Andrew McNamara of "Tue, 06 Jan 2004 13:13:33 +1100." <20040106021333.BB0E53C131@coffee.object-craft.com.au> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> Message-ID: <20040106022716.680353C131@coffee.object-craft.com.au> >>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? Oops - "action" is used in HTML, which could cause some confusion. I'd suggest something like "al-action", but I suspect that's not legal XML (I'll have to research it). It's actually considerably more complicated than the nextpage backdoor (which just relies on a specifically formatted input: nextpage, We're essentially talking about executing the code, not at template execution time as happens with things like valuexpr, but at form submission time. What we would probably need to do is save the value of the al-action attribute in __albform__. This really brings the security issuses of the hidden field mixins to a head - but in one sense we're already executing the __albform__ pickle (unpickling needs to be able to instanciate classes). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From matt at pollenation.net Tue Jan 6 20:42:49 2004 From: matt at pollenation.net (Matt Goodall) Date: Tue, 06 Jan 2004 09:42:49 +0000 Subject: [albatross-users] pagination with al-for In-Reply-To: <20040106021333.BB0E53C131@coffee.object-craft.com.au> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> Message-ID: <3FFA8319.4070609@pollenation.net> Andrew McNamara wrote: >>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? > That was me. Sorry I've been so quiet recently but I have also been really busy. To recap, the issue is that the current page module loading mechanism is broken for anything non-trivial. When a page module is imported it is registered in sys.modules under its module name. The absence of packages means that the page module name can easily clash with other modules and packages, overwriting entries in sys.modules. That causes all sorts of fun and games ;-). (Note that Albatross page modules are just Python modules in some directory on disk and that page modules in a directory structure are just Python modules scattered across are number of different directories on disk. There is no package structure.) There have been a couple of suggestions for how to fix the problem: 1. Hack the import machinery. Instead of importing page modules as is, concoct a package and module name to avoid clashes. I think I found a problem with this approach (something to do with importing builtin packages like os and os.path) but I can't remember the details now. I think I also found a way to avoid the problem. 2. Force the use of a proper package structure for page modules. Albatross could then import modules in the normal way; developers would have to scatter a page module directory structure with __init__.py files. This all sounds fine but I think it changes the concept of page modules a little. It would also break my code but I don't think it would be too difficult to fix that. 3. Use execfile() to "import" page modules. This avoids touching sys.modules at all which is great. However, there is a possible (i.e. no one has profiled it yet) performance hit for plain old CGI users because Albatross would no longer benefit from compiled page modules. There is also an issue with storing certain types of object is the session caused by the way the pickle machinery works. Just a couple more comments on the above and then I'll disappear back into the hole I've been living in recently ... On (1) ... personally, I don't like this approach. It's too hacky but it can probably be made to work. The benefit is that it has no effect on application code. On (2) ... this is probably the ideal solution, especially as it's probably only me it will affect. Hmm, in fact, it would allow be to clean up something that's been a slight irritation for me. However, it then seems wrong/silly to differentiate page modules from normal application modules. It might be best for Albatross to import modules using one of the application's packages as the "root", i.e. /one loads myapp.pages.one, /one/two load myapp.pages.one.two etc. On (3) ... I'm skeptical that the performance hit is at all significant. If you're using CGI then you've already got the overhead of loading the Python binary, loading Albatross packages and loading any additional packages your application uses. I can't imagine compiling a (hopefully) small page module is going to add much to all that. Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt at pollenation.net t: +44 (0)113 2252500 From matt at pollenation.net Tue Jan 6 20:47:16 2004 From: matt at pollenation.net (Matt Goodall) Date: Tue, 06 Jan 2004 09:47:16 +0000 Subject: [albatross-users] Summary of page module loading problem (was Re: [albatross-users] pagination with al-for) In-Reply-To: <3FFA8319.4070609@pollenation.net> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> <3FFA8319.4070609@pollenation.net> Message-ID: <3FFA8424.10109@pollenation.net> Uh, sorry - I forgot to change the subject. Hopefully this will help people find the previous message in the archives (hint: look up one message in the thread). Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt at pollenation.net From neel at mediapulse.com Wed Jan 7 02:55:28 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Tue, 6 Jan 2004 10:55:28 -0500 Subject: [albatross-users] pagination with al-for Message-ID: > 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). The patch I'm refering to was just a clean up patch of things in the TODO list with my name on them. I sent in two to the list with the subject "Patch to 1.11pre2", just make sure to grab the second one. > 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. Docs are all that are holing me up from releasing a 1.0 of Axe =) Currently I'm looking for a different solution than the standard python tex files, and looking into aurigadocs.sf.net, which at least I'll have docs in an XML format I can live with. I know Docbook is becoming more a standard, but I don't want to spend a lot of time working on parsers and having found any project with output in a format I like yet. From neel at mediapulse.com Wed Jan 7 03:07:38 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Tue, 6 Jan 2004 11:07:38 -0500 Subject: [albatross-users] pagination with al-for Message-ID: > Oops - "action" is used in HTML, which could cause some confusion. I'd > suggest something like "al-action", but I suspect that's not legal XML > (I'll have to research it). Perhaps we could go with "exec", though it might be confused with expr. Other options could be "run", "eval", or "method". > It's actually considerably more complicated than the nextpage backdoor > (which just relies on a specifically formatted input: > > nextpage, Yes, I've looked at the code and seen that sometimes it's <>,<> and sometimes it's <>,<>,<> so a generic solution would have to account for multiple arguments, and those may be coming from ctx.locals as well. > > We're essentially talking about executing the code, not at template > execution time as happens with things like valuexpr, but at form > submission time. What we would probably need to do is save > the value of > the al-action attribute in __albform__. This really brings > the security > issuses of the hidden field mixins to a head - but in one sense we're > already executing the __albform__ pickle (unpickling needs to be able > to instanciate classes). > Yes, there are some issues here. We could also have the tags register the "legal" methods exposed this way, and verify a match before execution. I don't know what you could do to the hidden field mixin to make it more secure that isn't already done. I'd also be interested to know about anyone who's spoofed a session without knowing the secret key =). Mike From andrewm at object-craft.com.au Wed Jan 7 12:01:09 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 07 Jan 2004 12:01:09 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: Message from Matt Goodall of "Tue, 06 Jan 2004 09:42:49 -0000." <3FFA8319.4070609@pollenation.net> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> <3FFA8319.4070609@pollenation.net> Message-ID: <20040107010109.37C613C131@coffee.object-craft.com.au> >To recap, the issue is that the current page module loading mechanism is >broken for anything non-trivial. When a page module is imported it is >registered in sys.modules under its module name. The absence of packages >means that the page module name can easily clash with other modules and >packages, overwriting entries in sys.modules. That causes all sorts of >fun and games ;-). > >(Note that Albatross page modules are just Python modules in some >directory on disk and that page modules in a directory structure are >just Python modules scattered across are number of different directories >on disk. There is no package structure.) Indeed. A page module is a regular python module, and occupies the same namespace as any other python module, hence the collisions. Arguably, they should live in their own namespace. >There have been a couple of suggestions for how to fix the problem: > > 1. Hack the import machinery. Instead of importing page modules as > is, concoct a package and module name to avoid clashes. I think I > found a problem with this approach (something to do with importing > builtin packages like os and os.path) but I can't remember the > details now. I think I also found a way to avoid the problem. I've done this before - I don't remember running into any real problems. I've discarded my earlier implementation, but here's something I just knocked up - it appears to work as desired: import imp, sys mod_holder_name = '__snot__' def load_page_module(path, name): try: mod_holder = sys.modules[mod_holder_name] except KeyError: mod_holder = imp.new_module(mod_holder_name) sys.modules[mod_holder_name] = mod_holder globals()[mod_holder_name] = mod_holder f, path, desc = imp.find_module(name, [path]) try: abs_name = mod_holder_name + '.' + name mod = imp.load_module(abs_name, f, path, desc) setattr(mod_holder, name, mod) finally: f.close() >>> load_page_module('.', 't') >>> __snot__.t.Sigh 'Hi' I've played around loading stuff from the "page" module t.py, and various other things, and it just seems to work. It's probably not necessary or desirable to poke everything back into globals() in the context of the Albatross machinery. Can anyone see any problems with this scheme? > 2. Force the use of a proper package structure for page modules. > Albatross could then import modules in the normal way; developers > would have to scatter a page module directory structure with > __init__.py files. This all sounds fine but I think it changes the > concept of page modules a little. It would also break my code but > I don't think it would be too difficult to fix that. The __init__.py problem only occurs for people who use the package structure - it should be backward compatible. The other virtue of this is that complex applications can implement a hierachy of page modules. > 3. Use execfile() to "import" page modules. This avoids touching > sys.modules at all which is great. However, there is a possible > (i.e. no one has profiled it yet) performance hit for plain old > CGI users because Albatross would no longer benefit from compiled > page modules. There is also an issue with storing certain types of > object is the session caused by the way the pickle machinery works. I've measured the hit in simple cases, but as you say, it's insignificant in the context of normal albatross cgi execution times. Still, it's a slippery slope... I think options 1 and 3 both suffer from the pickle problem, but I'd argue that it's a user application structure shortcoming and we should not be overly concerned about it. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From matt at pollenation.net Wed Jan 7 12:45:33 2004 From: matt at pollenation.net (Matt Goodall) Date: Wed, 07 Jan 2004 01:45:33 +0000 Subject: [albatross-users] pagination with al-for In-Reply-To: <20040107010109.37C613C131@coffee.object-craft.com.au> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> <3FFA8319.4070609@pollenation.net> <20040107010109.37C613C131@coffee.object-craft.com.au> Message-ID: <3FFB64BD.4090709@pollenation.net> Andrew McNamara wrote: [snip] >>There have been a couple of suggestions for how to fix the problem: >> >> 1. Hack the import machinery. Instead of importing page modules as >> is, concoct a package and module name to avoid clashes. I think I >> found a problem with this approach (something to do with importing >> builtin packages like os and os.path) but I can't remember the >> details now. I think I also found a way to avoid the problem. >> >> > >I've done this before - I don't remember running into any real problems. >I've discarded my earlier implementation, but here's something I just >knocked up - it appears to work as desired: > > import imp, sys > > mod_holder_name = '__snot__' > > def load_page_module(path, name): > try: > mod_holder = sys.modules[mod_holder_name] > except KeyError: > mod_holder = imp.new_module(mod_holder_name) > sys.modules[mod_holder_name] = mod_holder > globals()[mod_holder_name] = mod_holder > > f, path, desc = imp.find_module(name, [path]) > try: > abs_name = mod_holder_name + '.' + name > mod = imp.load_module(abs_name, f, path, desc) > setattr(mod_holder, name, mod) > finally: > f.close() > > >>> load_page_module('.', 't') > >>> __snot__.t.Sigh > 'Hi' > >I've played around loading stuff from the "page" module t.py, and various >other things, and it just seems to work. It's probably not necessary or >desirable to poke everything back into globals() in the context of the >Albatross machinery. > >Can anyone see any problems with this scheme? > > Ah yes, now I remember what the problem was. My initial experiment with this built a "flat" module name such as __albatross_pages__one_two. The fix was to create a holding module, __albatross_pages__, to hold the page modules ... just like you've done above. I don't think my code was as neat as yours though, and the name of your holding module is much better ;-). Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt at pollenation.net From andrewm at object-craft.com.au Wed Jan 7 13:10:36 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 07 Jan 2004 13:10:36 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: Message from Matt Goodall of "Wed, 07 Jan 2004 01:45:33 -0000." <3FFB64BD.4090709@pollenation.net> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> <3FFA8319.4070609@pollenation.net> <20040107010109.37C613C131@coffee.object-craft.com.au> <3FFB64BD.4090709@pollenation.net> Message-ID: <20040107021036.7E6893C131@coffee.object-craft.com.au> >Ah yes, now I remember what the problem was. > >My initial experiment with this built a "flat" module name such as >__albatross_pages__one_two. The fix was to create a holding module, >__albatross_pages__, to hold the page modules ... just like you've done >above. I'm running into a subtle problem with the naming of modules imported by the page module, which prevents any objects in the imported module being pickled - this is a show-stopper for this method if I can't find a solution. I can't yet duplicate the problem in a minimal way - it only occurs deep in a complex application. The imported modules end up with a name like "__alpage__.moduleA.moduleB", when they should be just "moduleA.moduleB". -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Wed Jan 7 14:51:42 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 07 Jan 2004 14:51:42 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: Message from Andrew McNamara of "Wed, 07 Jan 2004 13:10:36 +1100." <20040107021036.7E6893C131@coffee.object-craft.com.au> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> <3FFA8319.4070609@pollenation.net> <20040107010109.37C613C131@coffee.object-craft.com.au> <3FFB64BD.4090709@pollenation.net> <20040107021036.7E6893C131@coffee.object-craft.com.au> Message-ID: <20040107035142.EB2073C131@coffee.object-craft.com.au> >>Ah yes, now I remember what the problem was. >> >>My initial experiment with this built a "flat" module name such as >>__albatross_pages__one_two. The fix was to create a holding module, >>__albatross_pages__, to hold the page modules ... just like you've done >>above. > >I'm running into a subtle problem with the naming of modules imported >by the page module, which prevents any objects in the imported module >being pickled - this is a show-stopper for this method if I can't find >a solution. Actually, that was the problem you described - I failed to create the dummy holding module correctly (tried to take a shortcut). Obviously the existance of the parent module initiates deep magic in the python intepreter. I'm back to the problem I previously described as a "user application structure shortcoming" - having discovered one of these "shortcomings" in my own applications, I've changed my mind... it seems we have to allow page modules to define classes. I can't see any way to make the execfile() approach work with this requirement - essentially the page modules have to be real python modules. Even getting it to work with my "synthetic holding module" approach will not be straighforward - I'll have to somehow hook the unpickler's import requests. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Wed Jan 7 15:21:16 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 07 Jan 2004 15:21:16 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: Message from "Michael C. Neel" of "Tue, 06 Jan 2004 10:55:28 CDT." References: Message-ID: <20040107042116.9248C3C131@coffee.object-craft.com.au> >The patch I'm refering to was just a clean up patch of things in the TODO >list with my name on them. I sent in two to the list with the subject >"Patch to 1.11pre2", just make sure to grab the second one. Ah - yes - I had it marked for later attention... along with 300 other messages... 8-( Looking now. >Docs are all that are holing me up from releasing a 1.0 of Axe =) >Currently I'm looking for a different solution than the standard python >tex files, and looking into aurigadocs.sf.net, which at least I'll have >docs in an XML format I can live with. I know Docbook is becoming more a >standard, but I don't want to spend a lot of time working on parsers and >having found any project with output in a format I like yet. Dave looks at the "state of the art" from time to time, and I think he's still of the opinion that the python tex stuff is the best of a bad lot, although he mutters "restructured text... mmmm" from time to time. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Wed Jan 7 15:55:05 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 07 Jan 2004 15:55:05 +1100 Subject: [albatross-users] Patch to 1.11pre2 In-Reply-To: Message from "Michael C. Neel" of "Fri, 19 Dec 2003 17:40:40 CDT." References: Message-ID: <20040107045505.28D5A3C131@coffee.object-craft.com.au> >I went though the TODO list with 1.11pre2 and fixed the items I reported: > >* is confusing. Consider having ctx.req_equals() >check for "name.x" if "name" doesn't exist? Should at least mention it in >the section of the manual that talks about tags (Michael C. Neel). > >---> ctx.req_equals() will return true for input type=image with only the >name given We record the input type - it might be possible to avoid the second test. I'll have to look at the code. >* Allow multiple Cookie values to be set (Michael C. Neel). > >---> Biggest change made here. The headers mixin now keeps a list of >values for each header, which also means get_header returns a list. I >opted for get_headers to always return a list as it's consistent, but it >could be changed to only return a list on more than one value to remain >backwards compatible. Also, this does not work with the httpdapp.py >request class, as it keeps headers as a dict internally so doesn't handle >duplicate keys. the apacheapp.py was changed to use the add(key, val) >method of mod_python to handle the dupes. Does it look like httpdapp could be fixed easily enough? Other than that, this is a desirable change. >* ctx.add_session_vars() should create non-existent varaibles with value >of None (Michael C. Neel). > >---> Does just that now. I think I like the old behaviour better - raise an exception - it's saved my bacon on several occasions now, and makes debugging quicker. Setting to None feels too implicit/magical/perl-like. 8-) >* Second submission of form will return ctx.req_equals() TRUE for empty >fields (Michael C. Neel). > >---> I couldn't get this to occur on 1.11pre2, so I consider it fixed =) Yep... a year ago... 8-) 2002-12-05 14:45 andrewm * albatross/app.py: Make req_equals return true if the request evaluates true, rather than "not None" - this allows null strings to return false (found by Michael C. Neel). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Thu Jan 8 06:19:22 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Wed, 7 Jan 2004 14:19:22 -0500 Subject: [albatross-users] Patch to 1.11pre2 Message-ID: > >---> ctx.req_equals() will return true for input type=image > with only the > >name given > > We record the input type - it might be possible to avoid the > second test. > I'll have to look at the code. So the test would check the type is image, and look for name.x in that case? I'm not sure you can avoide a second test of some kind, but adding in the type makes this safer from weird names. > > >* Allow multiple Cookie values to be set (Michael C. Neel). > > > > Does it look like httpdapp could be fixed easily enough? It's not as easy as mod_python, which already supported duplicate headers. I could just alter the request object. httpdapp is using a dict for headers though out it's code, and since the keys are the header names you can have two the same. I hope you are looking at version two, which I reverted back set_header and added in add_header; I didn't like changing the expected behaviour of set_header. So since there is a seperat add_header function for the request object, you can set the httpdapp's request object to raise an error when add_header is called stating that method is not supported- until such time that the server code is revamped. > >* ctx.add_session_vars() should create non-existent > varaibles with value > >of None (Michael C. Neel). > > > >---> Does just that now. > > I think I like the old behaviour better - raise an exception > - it's saved > my bacon on several occasions now, and makes debugging > quicker. Setting > to None feels too implicit/magical/perl-like. 8-) When it was orgionally reported, it did nothing and raised no error. I didn't know if the exception was a quick work around and what was in the TODO for later, or if that was to be permant. Either way is better than nothing ;) > > >* Second submission of form will return ctx.req_equals() > TRUE for empty > >fields (Michael C. Neel). > > > >---> I couldn't get this to occur on 1.11pre2, so I consider > it fixed =) > > Yep... a year ago... 8-) You guys have to be the only people I know who don't love to cross things off a todo list =p From andrewm at object-craft.com.au Thu Jan 8 12:36:08 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 08 Jan 2004 12:36:08 +1100 Subject: [albatross-users] PATCH: page module loading changes (was: pagination with al-for) In-Reply-To: Message from Andrew McNamara of "Wed, 07 Jan 2004 14:51:42 +1100." <20040107035142.EB2073C131@coffee.object-craft.com.au> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> <3FFA8319.4070609@pollenation.net> <20040107010109.37C613C131@coffee.object-craft.com.au> <3FFB64BD.4090709@pollenation.net> <20040107021036.7E6893C131@coffee.object-craft.com.au> <20040107035142.EB2073C131@coffee.object-craft.com.au> Message-ID: <20040108013608.CA2263C159@coffee.object-craft.com.au> >Even getting it to work with my "synthetic holding module" approach >will not be straighforward - I'll have to somehow hook the unpickler's >import requests. Here's a patch that implements option 2 (loading page modules into a synthetic namespace). It's worked on the small number of (moderately complex) albatross apps I tried so far. In theory, you can now have a hierarchy of page modules ("admin.foo", "admin.bah"), although I haven't tested this yet. There are a number of changes from the old behaviour: * page module names were previously allowed to contain path components - now they are dot-delimited. So "admin/foo" becomes "admin.foo" (untested). * the page module cache implemented by the PageModuleMixin is gone - we now rely on sys.modules for caching. The magic to auto-reload when the module file was touched is also removed (it was broken anyway). * page modules are saved into sys.modules prepended with a synthetic __alpage__ module - so "login" becomes "__alpage__.login". Index: app.py =================================================================== RCS file: /usr/local/cvsroot/object-craft/albatross/albatross/app.py,v retrieving revision 1.84 diff -u -r1.84 app.py --- app.py 10 Nov 2003 00:35:04 -0000 1.84 +++ app.py 8 Jan 2004 01:23:53 -0000 @@ -7,7 +7,6 @@ import os import sys -import stat import imp import urlparse @@ -346,10 +345,17 @@ '''Caching module loader ''' + mod_holder_name = '__alpage__' + def __init__(self, base_dir, start_page): self.__base_dir = base_dir self.__start_page = start_page - self.__cache = {} + try: + self.__mod_holder = sys.modules[self.mod_holder_name] + except KeyError: + self.__mod_holder = imp.new_module(self.mod_holder_name) + sys.modules[self.mod_holder_name] = self.__mod_holder + globals()[self.mod_holder_name] = self.__mod_holder def module_path(self): return self.__base_dir @@ -365,35 +371,33 @@ ctx.set_page(name) self.load_page_module(ctx, name) + def is_page_module(self, name): + return name.startswith(self.mod_holder_name) + def load_page_module(self, ctx, name): - if self.__base_dir == '.': - path = name - else: - path = os.path.join(self.__base_dir, name) - page = self.__cache.get(path) - if page: - mtime = os.stat(page.__file__)[stat.ST_MTIME] - if mtime > page.__mtime__: - reload(page) - page.__mtime__ = mtime - if not page: - dirname, name = os.path.split(path) - file, filepath, desc = imp.find_module(name, [dirname]) - page = sys.modules.get(name) - if not page or not page.__file__.startswith(filepath): - try: - page = imp.load_module(name, file, filepath, desc) - finally: - if file: - file.close() - if not (hasattr(page, 'page_enter') or - hasattr(page, 'page_leave') or - hasattr(page, 'page_process') or - hasattr(page, 'page_display')): - raise ApplicationError('module "%s" does not define one of page_enter, page_leave, page_process or page_display' % (name)) - page.__mtime__ = os.stat(page.__file__)[stat.ST_MTIME] - self.__cache[path] = page + if name.startswith(self.mod_holder_name): + name = name[len(self.mod_holder_name)+1:] + filename = os.path.join(self.__base_dir, name.replace('.', os.path.sep)) + filename = os.path.normpath(filename) + dirname, filename = os.path.split(filename) + module_name = self.mod_holder_name + '.' + name + try: + page = sys.modules[module_name] + except KeyError: + f, filepath, desc = imp.find_module(name, [dirname]) + try: + page = imp.load_module(module_name, f, filepath, desc) + finally: + if f: + f.close() + if not (hasattr(page, 'page_enter') or + hasattr(page, 'page_leave') or + hasattr(page, 'page_process') or + hasattr(page, 'page_display')): + raise ApplicationError('module "%s" does not define one of page_enter, page_leave, page_process or page_display' % (name)) + setattr(self.__mod_holder, name, page) ctx.page = page + return page def page_enter(self, ctx, args): if hasattr(ctx.page, 'page_enter'): @@ -423,8 +427,8 @@ self.__start_page = start_page self.__page_objects = {} - def module_path(self): - pass + def is_page_module(self, name): + return False def start_page(self): return self.__start_page Index: context.py =================================================================== RCS file: /usr/local/cvsroot/object-craft/albatross/albatross/context.py,v retrieving revision 1.93 diff -u -r1.93 context.py --- context.py 21 Sep 2003 04:40:31 -0000 1.93 +++ context.py 8 Jan 2004 01:23:54 -0000 @@ -10,6 +10,7 @@ import stat import re import cPickle +import __builtin__ try: import zlib @@ -564,9 +565,13 @@ self.clear_locals() def decode_session(self, text): - module_path = self.app.module_path() - if module_path: - sys.path.insert(0, module_path) + def imp_hook(name, globals, locals, fromlist): + if self.app.is_page_module(name): + return self.app.load_page_module(self, name) + else: + return real_imp(name, globals, locals, fromlist) + + real_imp, __builtin__.__import__ = __builtin__.__import__, imp_hook try: try: vars = cPickle.loads(text) @@ -577,8 +582,7 @@ for name in vars.keys(): self.__vars[name] = 1 finally: - if module_path: - sys.path.remove(module_path) + __builtin__.__import__ = real_imp def encode_session(self): vars = {} -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Thu Jan 8 15:44:33 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 08 Jan 2004 15:44:33 +1100 Subject: [albatross-users] Patch to 1.11pre2 In-Reply-To: Message from "Michael C. Neel" of "Wed, 07 Jan 2004 14:19:22 CDT." References: Message-ID: <20040108044433.9CAE53C159@coffee.object-craft.com.au> >> We record the input type - it might be possible to avoid the second >> test. I'll have to look at the code. > >So the test would check the type is image, and look for name.x in that >case? I'm not sure you can avoide a second test of some kind, but adding >in the type makes this safer from weird names. I think the "weird names" bit was what I was trying to avoid. The performance cost for an added check is probably minor (although, in general, the checking and iterating of attributes and cgi inputs is probably an area ripe for optimisation). >> Does it look like httpdapp could be fixed easily enough? > >It's not as easy as mod_python, which already supported duplicate headers. >I could just alter the request object. httpdapp is using a dict for >headers though out it's code, and since the keys are the header names you >can have two the same. > >I hope you are looking at version two, which I reverted back set_header >and added in add_header; I didn't like changing the expected behaviour of >set_header. So since there is a seperat add_header function for the >request object, you can set the httpdapp's request object to raise an >error when add_header is called stating that method is not supported- >until such time that the server code is revamped. I think it's important that httpdapp be extended to support multiple instances of a given header, although it's somewhat of a catch-22 - without integrating your changes nobody will bother extending httpdapp. I guess the answer is to integrate your chances and put out a snapshot (we probably should stop calling them "release candidates"... 8-). Hopefully we can fix httpdapp before the next release. >> I think I like the old behaviour better - raise an exception - it's >> saved my bacon on several occasions now, and makes debugging quicker. >> Setting to None feels too implicit/magical/perl-like. 8-) > >When it was orgionally reported, it did nothing and raised no error. I >didn't know if the exception was a quick work around and what was in the >TODO for later, or if that was to be permant. Either way is better than >nothing ;) Indeed. I think I'll exercise my dictitorial rights and leave it as an exception (I think we discussed this at the time the exception went in, and while I wasn't convinced I've come to like it since). >> Yep... a year ago... 8-) > >You guys have to be the only people I know who don't love to cross things >off a todo list Yeah. I use my "albatross" mail folder as a "todo" list also, so it gets somewhat confusing. Feel free to throw things at us... 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From djc at object-craft.com.au Fri Jan 9 11:42:31 2004 From: djc at object-craft.com.au (Dave Cole) Date: Fri, 09 Jan 2004 11:42:31 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: <20040106021333.BB0E53C131@coffee.object-craft.com.au> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> Message-ID: <1073608951.26427.9.camel@echidna.object-craft.com.au> 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 From djc at object-craft.com.au Fri Jan 9 11:46:47 2004 From: djc at object-craft.com.au (Dave Cole) Date: Fri, 09 Jan 2004 11:46:47 +1100 Subject: [albatross-users] pagination with al-for In-Reply-To: <3FFA8319.4070609@pollenation.net> References: <20040106021333.BB0E53C131@coffee.object-craft.com.au> <3FFA8319.4070609@pollenation.net> Message-ID: <1073609206.26423.13.camel@echidna.object-craft.com.au> On Tue, 2004-01-06 at 20:42, Matt Goodall wrote: > There have been a couple of suggestions for how to fix the problem: > > 1. Hack the import machinery. Instead of importing page modules as > is, concoct a package and module name to avoid clashes. I think I > found a problem with this approach (something to do with importing > builtin packages like os and os.path) but I can't remember the > details now. I think I also found a way to avoid the problem. > 2. Force the use of a proper package structure for page modules. > Albatross could then import modules in the normal way; developers > would have to scatter a page module directory structure with > __init__.py files. This all sounds fine but I think it changes the > concept of page modules a little. It would also break my code but > I don't think it would be too difficult to fix that. I prefer this solution. > 3. Use execfile() to "import" page modules. This avoids touching > sys.modules at all which is great. However, there is a possible > (i.e. no one has profiled it yet) performance hit for plain old > CGI users because Albatross would no longer benefit from compiled > page modules. There is also an issue with storing certain types of > object is the session caused by the way the pickle machinery works. - Dave -- http://www.object-craft.com.au From andrewm at object-craft.com.au Fri Jan 9 15:40:56 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 09 Jan 2004 15:40:56 +1100 Subject: [albatross-users] Patch to 1.11pre2 In-Reply-To: Message from "Michael C. Neel" of "Fri, 19 Dec 2003 17:40:40 CDT." References: Message-ID: <20040109044056.2AA833C1F1@coffee.object-craft.com.au> >* is confusing. Consider having ctx.req_equals() >check for "name.x" if "name" doesn't exist? Applied and doco updated (mainly consisted of removing things though). >* Allow multiple Cookie values to be set (Michael C. Neel). > >---> Biggest change made here. The headers mixin now keeps a list of >values for each header, which also means get_header returns a list. I >opted for get_headers to always return a list as it's consistent, but it >could be changed to only return a list on more than one value to remain >backwards compatible. Also, this does not work with the httpdapp.py >request class, as it keeps headers as a dict internally so doesn't handle >duplicate keys. the apacheapp.py was changed to use the add(key, val) >method of mod_python to handle the dupes. A slight variation of your patch was applied. I realised that the header matching should be case insensitive, so I restructured ResponseMixin somewhat. I've also fixed httpdapp.py (I think!), Doco updated. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Fri Jan 9 23:54:35 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 09 Jan 2004 23:54:35 +1100 Subject: [albatross-users] HTTP Status handling fixes Message-ID: <20040109125435.F08A73C1F1@coffee.object-craft.com.au> I've just checked in a bunch of fixes to the handling of HTTP Status codes within Albatross. Among other things, the cgiapp deployment method was not emiting a "Status:" header, and the exception code was not setting the status to "500 Internal Server Error". I've also added a bunch of symbolic names for the HTTP/1.0 status codes. While I was looking at the status code, I "accidently" refactored the httpdapp module - any breakage, let me know. We should release a preview snapshot early next week (I want to get some fixes to the page module import machine in place first). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Sat Jan 10 02:47:05 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Fri, 9 Jan 2004 10:47:05 -0500 Subject: [albatross-users] HTTP Status handling fixes Message-ID: This is a problem I just had to address on our systems, because the traceback being a 200 OK page led search engines to (rightfuly) index the page. I set template load errors to 404 and all others to 500 it a cusomt app class we use. A problem did arise relating to mod_python. If the return value of the mod_python handler is other than 200 OK, apache takes over and does it's own error page, (or does the redirect to a ErrorDocument if one is setup). This however prevent you from ever seeing traceback or traceback.html. I brought this issue up on the mod_python list, and it seems that version 3.x has a member req.status you can use to set the correct status and still return apache.OK; but this doesn't seem to be in 2.x mod_python (1.3x Apaches), leaving those of us not running Apache 2.x on every system left to work around the missing piece. Grisha hasn't hid the fact he no longer wishes to maintain mod_python for apache 1.3; so barring any major security problems I don't see changes coming for a while to mod_python 2.x. Sine your in the handle_execption ( =D )... the custom app we have allows us to define the name of the traceback.html file so that it doesn't have to be called traceback.html. Still same logic, spew on no file, so tis allows us to toggle traceback errors through httpd.conf options, so that our beta server spews while live has a pretty error message - without the need for us to remember to mv traceback.html into the templates folder after we sync to live (because we forget, lol). Also, it has a toggle for a formatted email to be sent of the spew that would have occurred, plus headers, request connection details, and field values. So on live we get emails of errors, but we don't enable this on beta. Like I said, since you were already in there... =) Mike Actually, when you get to a point of putting up a rc you think will be up for a bit, I'll work on some of this myself, so don't feel pressured to do so. I've got no problems with some one tweaking my patch later, the goal was to get the feature in there =) From tchur at optushome.com.au Sat Jan 10 13:02:48 2004 From: tchur at optushome.com.au (Tim Churches) Date: 10 Jan 2004 13:02:48 +1100 Subject: [albatross-users] Albatross and MozPython Message-ID: <1073700168.1186.126.camel@emilio> Is there utility to be had be running Albatross apps under MozPython - see http://www.thomas-schilz.de/MozPython/ ? I notice that it (MozPython) doesn't yet support response header processing, and thus cookies can't be set. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sheila at thinkspot.net Sun Jan 11 06:29:45 2004 From: sheila at thinkspot.net (Sheila King) Date: Sat, 10 Jan 2004 11:29:45 -0800 Subject: [albatross-users] Minor Doc Error Message-ID: <257295691.1073734184@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> OK, it is a minor doc error, but on the theory that even details should be correct if possible... On 5.2.2.1 alias="..." attribute http://www.object-craft.com.au/projects/albatross/albatross/tag-input-alias .html near the bottom of the page, it makes reference to samples/tree/tree1.py Should that not be samples/tree1/tree.py ??? I noticed this only because I'm trying to figure out how to use al-tree tags to good effect and am going through the docs. Anyhow, having minor successes and major frustrations... Back to the docs for me! -- Sheila King http://www.thinkspot.net/sheila/ http://www.k12groups.org From sheila at thinkspot.net Sun Jan 11 19:30:31 2004 From: sheila at thinkspot.net (Sheila King) Date: Sun, 11 Jan 2004 00:30:31 -0800 Subject: [albatross-users] Minor Doc Error In-Reply-To: <257295691.1073734184@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> References: <257295691.1073734184@lsanca1-ar1-4-62-158-245.lsanca1.dsl-veriz on.net> Message-ID: <304142553.1073781031@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> Here's another one that I *think* is an error, and IIRC occurs in a few places in the documentation, in conjuction al-input tags that have type image. For example, see this page: 5.2.2.7 node="..." attribute http://www.object-craft.com.au/projects/albatross/albatross/tag-input-node. html This tag (as an example) appears near the bottom: Shouldn't that be...instead? after the 'src' shouldn't there be an equal sign and an opening quote? At one point I was looking at the docs (a while back) and could not figure out why there was this one quote symbol that appeared to be unmatched, and it was confusing to me. (OK, so I'm easily confused...) -- Sheila King http://www.thinkspot.net/sheila/ http://www.k12groups.org --On Saturday, January 10, 2004 11:29 AM -0800 Sheila King wrote: > OK, it is a minor doc error, but on the theory that even details should be > correct if possible... > > On 5.2.2.1 alias="..." attribute > http://www.object-craft.com.au/projects/albatross/albatross/tag-input-ali > as .html > > near the bottom of the page, it makes reference to > > samples/tree/tree1.py > > Should that not be > samples/tree1/tree.py > > ??? > > I noticed this only because I'm trying to figure out how to use al-tree > tags to good effect and am going through the docs. Anyhow, having minor > successes and major frustrations... > > Back to the docs for me! > > -- > Sheila King > http://www.thinkspot.net/sheila/ > http://www.k12groups.org > > > > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users > From sheila at thinkspot.net Sun Jan 11 19:51:39 2004 From: sheila at thinkspot.net (Sheila King) Date: Sun, 11 Jan 2004 00:51:39 -0800 Subject: [albatross-users] Help with al-trees Message-ID: <305409996.1073782299@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> Hello, Having some major difficulties "zen"-ing the Lazy Iterator Albatross tree thingies. I have been able to create a simple al-tree that displays all nodes by copying somewhat from the tree1 example in the albatross samples directory. However, making the leap to Lazy trees is proving difficult. I'm still going through the mailing list archives, but I have some nagging questions that I hope someone will be able to answer... (1) What is the difference between "selected" nodes and "open" nodes? If selected, but not open, a node would be shown but it's children would not be shown? Doesn't this imply that all open nodes must necessarily be selected? (2) The examples (tree1, tree2, tree3) included in the samples directory do not show in any way subclassing or instantiating any of the albatross TreeIterator object classes. My understanding, is that one defines a node-type object class of their own, builds their own tree using the node-type class they have defined, and then in the HTML template file, where the iter attribute is specified, albatross creates an appropriate instance of a TreeIterator class? So I'm a bit confused by this message from the mailing list archives: http://www.object-craft.com.au/pipermail/albatross-users/2002-December/0002 57.html where it is shown to create an instance of a LazyTreeIterator object? I'm not grokking the relationship between ctx.locals.root and ctx.locals.hn in that example? Does this mean that in the HTML template file, one would set the iter attribute in the al-tree tag to be hn ? (3) I wrote some code that used just regular Tree object (ok, I realize there is not tree class, only a TreeIterator class, but you know what I mean...). It worked fine to display the whole tree. Then I tried to switch to a lazy tree and display only nodes that I want to see (not the whole tree). But I'm apparently totally misunderstanding the open_aliases and selected_aliases thing. I've tried to write my own definitions for those functions, and then set them in my page_display code, but to no effect. Only the root node, and with no children, was displayed on my page. Then I tried subclassing the LazyTreeIterator for my node object class, since (from viewing albatross source code) I see that the LazyTreeIterator already has set_open_aliases and set_selected_aliases defined. But I got the same results as before, just only displaying the root node of my tree, with no children. Any tips, suggestions or clues appreciated. -- Sheila King http://www.thinkspot.net/sheila/ http://www.k12groups.org From andrewm at object-craft.com.au Mon Jan 12 09:32:10 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 12 Jan 2004 09:32:10 +1100 Subject: [albatross-users] Minor Doc Error In-Reply-To: Message from Sheila King of "Sun, 11 Jan 2004 00:30:31 -0800." <304142553.1073781031@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> References: <257295691.1073734184@lsanca1-ar1-4-62-158-245.lsanca1.dsl-veriz on.net> <304142553.1073781031@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> Message-ID: <20040111223210.AC9D13C1F1@coffee.object-craft.com.au> >Here's another one that I *think* is an error, and IIRC occurs in a few >places in the documentation, in conjuction al-input tags that have type >image. > >For example, see this page: >5.2.2.7 node="..." attribute >http://www.object-craft.com.au/projects/albatross/albatross/tag-input-node. >html > >This tag (as an example) appears near the bottom: > >border="0" whitespace> > >Shouldn't that be...instead? >border="0" whitespace> This is something that gets reported repeatedly - it seems to be a bug in the latex2html script (a horrifying 17400 line Perl script), rather than our markup - the problem doesn't appear in the pdf output. We keep hoping that new versions of latex2html will fix the problem, but no luck so far (it's probably unmaintainable even for the author 8-). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Mon Jan 12 23:07:05 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 12 Jan 2004 23:07:05 +1100 Subject: [albatross-users] page module import magic Message-ID: <20040112120706.180113C517@coffee.object-craft.com.au> Is this getting too ugly? Much of the messiness comes from supporting hierarchies of page modules (app.login.help, etc) - dummy parent modules have to be created. I've written a bunch of tests, and it looks like the modification works well, but maybe we should only support a flat page module namespace? Index: app.py =================================================================== RCS file: /usr/local/cvsroot/object-craft/albatross/albatross/app.py,v retrieving revision 1.87 diff -u -r1.87 app.py --- app.py 9 Jan 2004 12:38:27 -0000 1.87 +++ app.py 12 Jan 2004 12:02:26 -0000 @@ -7,7 +7,6 @@ import os import sys -import stat import imp import urlparse @@ -374,10 +373,13 @@ '''Caching module loader ''' + mod_holder_name = '__alpage__' + def __init__(self, base_dir, start_page): self.__base_dir = base_dir self.__start_page = start_page - self.__cache = {} + if not sys.modules.has_key(self.mod_holder_name): + self.create_module_holder(self.mod_holder_name) def module_path(self): return self.__base_dir @@ -393,35 +395,49 @@ ctx.set_page(name) self.load_page_module(ctx, name) + def is_page_module(self, name): + return name.startswith(self.mod_holder_name) + + def create_module_holder(self, name): + sys.modules[name] = module = imp.new_module(name) + return module + + def get_module_holder(self, name): + path = name.split('.')[:-1] + parent_name = '.'.join(path) + try: + return sys.modules[parent_name] + except KeyError: + parent_parent = self.get_module_holder(parent_name) + module = self.create_module_holder(parent_name) + setattr(parent_parent, path[-1], module) + return module + def load_page_module(self, ctx, name): - if self.__base_dir == '.': - path = name - else: - path = os.path.join(self.__base_dir, name) - page = self.__cache.get(path) - if page: - mtime = os.stat(page.__file__)[stat.ST_MTIME] - if mtime > page.__mtime__: - reload(page) - page.__mtime__ = mtime - if not page: - dirname, name = os.path.split(path) - file, filepath, desc = imp.find_module(name, [dirname]) - page = sys.modules.get(name) - if not page or not page.__file__.startswith(filepath): - try: - page = imp.load_module(name, file, filepath, desc) - finally: - if file: - file.close() + if not name.startswith(self.mod_holder_name): + name = self.mod_holder_name + '.' + name + try: + page = sys.modules[name] + except KeyError: + modpath = os.path.join(self.__base_dir, *name.split('.')[1:]) + modpath, modname = os.path.split(os.path.normpath(modpath)) + try: + f, filepath, desc = imp.find_module(modname, [modpath]) + except ImportError, e: + raise ApplicationError('%s (in %s)' % (e, modpath)) + try: + page = imp.load_module(name, f, filepath, desc) + finally: + if f: + f.close() if not (hasattr(page, 'page_enter') or hasattr(page, 'page_leave') or hasattr(page, 'page_process') or hasattr(page, 'page_display')): raise ApplicationError('module "%s" does not define one of page_enter, page_leave, page_process or page_display' % (name)) - page.__mtime__ = os.stat(page.__file__)[stat.ST_MTIME] - self.__cache[path] = page + setattr(self.get_module_holder(name), modname, page) ctx.page = page + return ctx.page def page_enter(self, ctx, args): if hasattr(ctx.page, 'page_enter'): @@ -451,8 +467,8 @@ self.__start_page = start_page self.__page_objects = {} - def module_path(self): - pass + def is_page_module(self, name): + return False def start_page(self): return self.__start_page Index: context.py =================================================================== RCS file: /usr/local/cvsroot/object-craft/albatross/albatross/context.py,v retrieving revision 1.93 diff -u -r1.93 context.py --- context.py 21 Sep 2003 04:40:31 -0000 1.93 +++ context.py 12 Jan 2004 12:02:28 -0000 @@ -10,6 +10,7 @@ import stat import re import cPickle +import __builtin__ try: import zlib @@ -564,9 +565,13 @@ self.clear_locals() def decode_session(self, text): - module_path = self.app.module_path() - if module_path: - sys.path.insert(0, module_path) + def imp_hook(name, globals, locals, fromlist): + if self.app.is_page_module(name): + return self.app.load_page_module(self, name) + else: + return real_imp(name, globals, locals, fromlist) + + real_imp, __builtin__.__import__ = __builtin__.__import__, imp_hook try: try: vars = cPickle.loads(text) @@ -577,8 +582,7 @@ for name in vars.keys(): self.__vars[name] = 1 finally: - if module_path: - sys.path.remove(module_path) + __builtin__.__import__ = real_imp def encode_session(self): vars = {} -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From matt at pollenation.net Mon Jan 12 23:42:29 2004 From: matt at pollenation.net (Matt Goodall) Date: Mon, 12 Jan 2004 12:42:29 +0000 Subject: [albatross-users] page module import magic In-Reply-To: <20040112120706.180113C517@coffee.object-craft.com.au> References: <20040112120706.180113C517@coffee.object-craft.com.au> Message-ID: <40029635.6000909@pollenation.net> Andrew McNamara wrote: >Is this getting too ugly? Much of the messiness comes from supporting >hierarchies of page modules (app.login.help, etc) - dummy parent modules >have to be created. I've written a bunch of tests, and it looks like >the modification works well, but maybe we should only support a flat page >module namespace? > > [snip the patch] Yes, it's getting a bit ugly. It's certainly not particularly straightforward. When you say, "maybe we should only support a flat page module namspace", what do you mean? Do you mean that Albatross should not support URLs like /login/help , requiring something like /login_help instead, or something else? Also, I'm not sure what you mean by "dummy parent modules have to be created". Is this referring to the create_module_holder() magic or modules that an Albatross user would need to create? Sorry if I'm being dumb here, I'm having one of those slow Mondays :(. Thanks, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenationinternet.com e: matt at pollenation.net From andrewm at object-craft.com.au Tue Jan 13 00:04:24 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 13 Jan 2004 00:04:24 +1100 Subject: [albatross-users] page module import magic In-Reply-To: Message from Matt Goodall of "Mon, 12 Jan 2004 12:42:29 -0000." <40029635.6000909@pollenation.net> References: <20040112120706.180113C517@coffee.object-craft.com.au> <40029635.6000909@pollenation.net> Message-ID: <20040112130424.D2F073C517@coffee.object-craft.com.au> >Yes, it's getting a bit ugly. It's certainly not particularly >straightforward. > >When you say, "maybe we should only support a flat page module >namspace", what do you mean? Do you mean that Albatross should not >support URLs like /login/help , requiring something like /login_help >instead, or something else? I'm referring to the page names - with this scheme, you can do things like ctx.set_page('preferences.simple') and ctx.set_page('preferences.advanced') The separator is the normal python namespace separate (dot) - previously, the filesystem separator was used, although I'm not convinced hierarchies of pages would have worked correctly. I can imagine an app where you'd want to map the url to page name - maybe it was a mistake to change it (I was assuming that the old code was broken, and nobody would have been using hierarchies)? Dots seem more natural in the context (and it means the import hook can call the function directly). >Also, I'm not sure what you mean by "dummy parent modules have to be >created". Is this referring to the create_module_holder() magic or >modules that an Albatross user would need to create? In the flat case, we create a dummy module at the root, called '__alpage__', and we load the page modules into that. If a hierarchy of page modules is used, dummy modules have to be created to represent the intervening directories. So... if you have the following: login.py preferences/simple.py preferences/advanced.py they would be loaded as: __alpage__ (dummy) __alpage__.login.py __alpage__.preferences (dummy) __alpage__.preferences.simple __alpage__.preferences.advanced get_module_holder() just makes sure the dummies are created (recursively) and returns the parent of the module to be loaded. In decode_session(), I've replaced a sys.path fiddle with an import hook. On import, if the name starts with __alpage__, the load_page_module() method is called instead of the system import code. That pretty much describes the changes - does it make more sense now? I'm reasonably happy with the result - certainly no less happy that I was with the original implementation. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From matt at pollenation.net Tue Jan 13 01:33:24 2004 From: matt at pollenation.net (Matt Goodall) Date: Mon, 12 Jan 2004 14:33:24 +0000 Subject: [albatross-users] page module import magic In-Reply-To: <20040112130424.D2F073C517@coffee.object-craft.com.au> References: <20040112120706.180113C517@coffee.object-craft.com.au> <40029635.6000909@pollenation.net> <20040112130424.D2F073C517@coffee.object-craft.com.au> Message-ID: <4002B034.40400@pollenation.net> Andrew McNamara wrote: >>Yes, it's getting a bit ugly. It's certainly not particularly >>straightforward. >> >>When you say, "maybe we should only support a flat page module >>namspace", what do you mean? Do you mean that Albatross should not >>support URLs like /login/help , requiring something like /login_help >>instead, or something else? >> >> > >I'm referring to the page names - with this scheme, you can do things like >ctx.set_page('preferences.simple') and ctx.set_page('preferences.advanced') > >The separator is the normal python namespace separate (dot) - previously, >the filesystem separator was used, although I'm not convinced hierarchies >of pages would have worked correctly. > > Hierarchies of pages do work but not quite correctly in the released code base, hence my original bug report. The only problem with them is the corruption of sys.modules. Perhaps Albatross was never really meant to be used like this? >I can imagine an app where you'd want to map the url to page name - maybe >it was a mistake to change it (I was assuming that the old code was broken, >and nobody would have been using hierarchies)? Dots seem more natural in >the context (and it means the import hook can call the function directly). > > For me, using a '.' for this purpose in a URL is odd. URLs are designed to map to resources (real or virtual) so using a '.' is creating your own URL scheme when a normal URL would have been good enough. Hmm ... is there a problem with simply converting a URL of preferences/simple to a module called preferences.simple? Albatross already has a simple mechanism for dynamic URL mapping. There's an example in the Wiki, http://www.object-craft.com.au/projects/albatross/wiki/get_5fpage_5ffrom_5furi_28_29_20example. > > >>Also, I'm not sure what you mean by "dummy parent modules have to be >>created". Is this referring to the create_module_holder() magic or >>modules that an Albatross user would need to create? >> >> > >In the flat case, we create a dummy module at the root, called >'__alpage__', and we load the page modules into that. If a hierarchy >of page modules is used, dummy modules have to be created to represent >the intervening directories. So... if you have the following: > > login.py > preferences/simple.py > preferences/advanced.py > >they would be loaded as: > > __alpage__ (dummy) > __alpage__.login.py > __alpage__.preferences (dummy) > __alpage__.preferences.simple > __alpage__.preferences.advanced > >get_module_holder() just makes sure the dummies are created (recursively) >and returns the parent of the module to be loaded. > > Ah, ok. I understand now. Would this work if I wanted the URL "preferences" *and* "preferences/simple" to work correctly or would the dummy __alpage__.preferences module get in the way? I actually thought your preferred solution was to use *real* application packages and modules (which I guess is why I was a little confused about your "dummy parent modules" comment) but I've reread the thread and found mention of a "synthetic namespace". >In decode_session(), I've replaced a sys.path fiddle with an import hook. >On import, if the name starts with __alpage__, the load_page_module() >method is called instead of the system import code. > >That pretty much describes the changes - does it make more sense now? > Yes, that's great. Thanks. >I'm reasonably happy with the result - certainly no less happy that I was >with the original implementation. > > I would be grateful if you could keep me updated on the solution you choose. I would need to change my code in a number of places to use a '.' in the URL but it's probably not too big a problem and I would rather use an official Albatross release than my patched version. However, nice URLs will be important to me for some future projects. Thanks for the detailed explanation. If I get time I will try your patch to see what happens here. Sadly, I'm not finding much time for anything but payed coding at the moment :(. Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenationinternet.com e: matt at pollenation.net t: +44 (0)113 2252500 From neel at mediapulse.com Tue Jan 13 03:36:46 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Mon, 12 Jan 2004 11:36:46 -0500 Subject: [albatross-users] page module import magic Message-ID: > I can imagine an app where you'd want to map the url to page > name - maybe > it was a mistake to change it (I was assuming that the old > code was broken, > and nobody would have been using hierarchies)? Dots seem more > natural in > the context (and it means the import hook can call the > function directly). Having done a good number of deep sites, I've never needed the page modules to be in a hierarchy. Templates yes, and this works fine. I break out page modules based on "feature" of the site, for example I may have www_forms.py for generic handling and a few form to emails or site search, member_forms.py to handle user logins and data, store_forms.py to handle the ecommerce related pages, and search_forms.py to handle a custom database search of say company locations. With the templates in a hierarchy, it's east to register the right template for with the right module. I also sub class each page module from a master, in which the master defines the page_display (so all templaes see the same macros for layout) and the page modules handle page_enter and page_process. Then again, I've also never gone beyone the SimpleApp module for anything I've done either =p Mike From sheila at thinkspot.net Tue Jan 13 08:43:51 2004 From: sheila at thinkspot.net (Sheila King) Date: Mon, 12 Jan 2004 13:43:51 -0800 Subject: [albatross-users] How to get https protocol from al-a tags? Message-ID: <72588106.1073915031@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> OK, I'm moving an albatross app I've been using under http for a while to https. And I had hoped this would simply require moving the appropriate files to the proper directory on my web server and adjusting a path or two. However, it does appear that the al-a tags always produce links to http and not to https even if the referring/current page is https. How to fix this? Is there an easy/quick thing I can do to my albatross files? I'm looking at tags.py and it is not clear to me what code I could/should change there for this effect? I'm kinda bummed, cuz I already paid to have SSL set up on my web site, and now it appears that it may not work with albatross. :/ suggestions? -- Sheila King http://www.thinkspot.net/sheila/ http://www.k12groups.org From neel at mediapulse.com Tue Jan 13 09:16:43 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Mon, 12 Jan 2004 17:16:43 -0500 Subject: [albatross-users] How to get https protocol from al-a tags? Message-ID: In the app.py is the lines: def redirect_url(self, loc): new_base = self.absolute_base_url() return urlparse.urlunparse(('http', self.request.get_servername(), new_base + loc, '', '', '')) where it's going on. You could change the http to https, but really IMHO albatross shouldn't be putting http(s) and servername into a url, prefixing with '/' at the beginning is a lot easier to move between sites. I've also done sites with wildcards for dns and servername, and this would be a problem here too. I don't know what the gain is for building the full url, so there maybe a reason to have it, but changing it to: def redirect_url(self, loc): return self.absolute_base_url() + loc should solve your problem, but that's untested so you may need to test it a bit. Also if you add a ?dummy=1 to the end of your href, I think albatross won't try to put in the full url - that or use expr instead as I don't think it will do the full url either. I'm not 100% because I rarely use this tag. Mike > -----Original Message----- > From: Sheila King [mailto:sheila at thinkspot.net] > Sent: Monday, January 12, 2004 4:44 PM > To: albatross-users at object-craft.com.au > Subject: [albatross-users] How to get https protocol from al-a tags? > > > OK, I'm moving an albatross app I've been using under http > for a while to > https. And I had hoped this would simply require moving the > appropriate > files to the proper directory on my web server and adjusting > a path or two. > > However, it does appear that the al-a tags always produce > links to http and > not to https even if the referring/current page is https. > > How to fix this? > > Is there an easy/quick thing I can do to my albatross files? > I'm looking at > tags.py and it is not clear to me what code I could/should > change there for > this effect? > > I'm kinda bummed, cuz I already paid to have SSL set up on my > web site, and > now it appears that it may not work with albatross. > :/ > > suggestions? > > -- > Sheila King > http://www.thinkspot.net/sheila/ > http://www.k12groups.org > > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat ross-users From sheila at thinkspot.net Tue Jan 13 10:14:16 2004 From: sheila at thinkspot.net (Sheila King) Date: Mon, 12 Jan 2004 15:14:16 -0800 Subject: [albatross-users] How to get https protocol from al-a tags? In-Reply-To: References: Message-ID: <78012976.1073920456@lsanca1-ar1-4-62-158-245.lsanca1.dsl-verizon.net> --On Monday, January 12, 2004 5:16 PM -0500 "Michael C. Neel" wrote: > In the app.py is the lines: > > def redirect_url(self, loc): > new_base = self.absolute_base_url() > return urlparse.urlunparse(('http', > self.request.get_servername(), > new_base + loc, '', '', '')) > > where it's going on. You could change the http to https, but really > IMHO albatross shouldn't be putting http(s) and servername into a url, > prefixing with '/' at the beginning is a lot easier to move between > sites. I've also done sites with wildcards for dns and servername, and > this would be a problem here too. I don't know what the gain is for > building the full url, so there maybe a reason to have it, but changing > it to: > > def redirect_url(self, loc): > return self.absolute_base_url() + loc > > should solve your problem, but that's untested so you may need to test > it a bit. Also if you add a ?dummy=1 to the end of your href, I think > albatross won't try to put in the full url - that or use expr instead as > I don't think it will do the full url either. I'm not 100% because I > rarely use this tag. > > Mike Thanks, heaps, Mike. I quickly patched this change in, and it seems to be working as desired. And yes, I do want to be able to switch between sites, some of which have http and some of which have https, so flexibility is important. I sure would like to see this flexibility incorporated into the next Albatross patch/version. -- Sheila King http://www.thinkspot.net/sheila/ http://www.k12groups.org >> -----Original Message----- >> From: Sheila King [mailto:sheila at thinkspot.net] >> Sent: Monday, January 12, 2004 4:44 PM >> To: albatross-users at object-craft.com.au >> Subject: [albatross-users] How to get https protocol from al-a tags? >> >> >> OK, I'm moving an albatross app I've been using under http >> for a while to >> https. And I had hoped this would simply require moving the >> appropriate >> files to the proper directory on my web server and adjusting >> a path or two. >> >> However, it does appear that the al-a tags always produce >> links to http and >> not to https even if the referring/current page is https. >> >> How to fix this? >> >> Is there an easy/quick thing I can do to my albatross files? >> I'm looking at >> tags.py and it is not clear to me what code I could/should >> change there for >> this effect? >> >> I'm kinda bummed, cuz I already paid to have SSL set up on my >> web site, and >> now it appears that it may not work with albatross. >> :/ >> >> suggestions? >> >> -- >> Sheila King >> http://www.thinkspot.net/sheila/ >> http://www.k12groups.org From djc at object-craft.com.au Tue Jan 13 12:25:53 2004 From: djc at object-craft.com.au (Dave Cole) Date: Tue, 13 Jan 2004 12:25:53 +1100 Subject: [albatross-users] page module import magic In-Reply-To: <4002B034.40400@pollenation.net> References: <20040112120706.180113C517@coffee.object-craft.com.au> <40029635.6000909@pollenation.net> <20040112130424.D2F073C517@coffee.object-craft.com.au> <4002B034.40400@pollenation.net> Message-ID: <1073957153.574.32.camel@echidna.object-craft.com.au> On Tue, 2004-01-13 at 01:33, Matt Goodall wrote: > Andrew McNamara wrote: > > Hierarchies of pages do work but not quite correctly in the released > code base, hence my original bug report. The only problem with them is > the corruption of sys.modules. Perhaps Albatross was never really meant > to be used like this? The current behaviour is a bug. I think we all agree it should be fixed. :-) > I actually thought your preferred solution was to use *real* application > packages and modules (which I guess is why I was a little confused about > your "dummy parent modules" comment) but I've reread the thread and > found mention of a "synthetic namespace". My preference is to just use Python packages, but as Andrew points out, this will probably break some current code. The fix is probably fairly easy, just place __init__.py in page module parent directories. > I would be grateful if you could keep me updated on the solution you > choose. I would need to change my code in a number of places to use a > '.' in the URL but it's probably not too big a problem and I would > rather use an official Albatross release than my patched version. > However, nice URLs will be important to me for some future projects. Is there any reason we couldn't simply url.replace('/', '.')? > Thanks for the detailed explanation. If I get time I will try your patch > to see what happens here. Sadly, I'm not finding much time for anything > but payed coding at the moment :(. I know what you mean. - Dave -- http://www.object-craft.com.au From andrewm at object-craft.com.au Tue Jan 13 13:17:57 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 13 Jan 2004 13:17:57 +1100 Subject: [albatross-users] page module import magic In-Reply-To: Message from Matt Goodall of "Mon, 12 Jan 2004 14:33:24 -0000." <4002B034.40400@pollenation.net> References: <20040112120706.180113C517@coffee.object-craft.com.au> <40029635.6000909@pollenation.net> <20040112130424.D2F073C517@coffee.object-craft.com.au> <4002B034.40400@pollenation.net> Message-ID: <20040113021757.56C3A3C517@coffee.object-craft.com.au> >>I can imagine an app where you'd want to map the url to page name - maybe >>it was a mistake to change it (I was assuming that the old code was broken, >>and nobody would have been using hierarchies)? Dots seem more natural in >>the context (and it means the import hook can call the function directly). > >For me, using a '.' for this purpose in a URL is odd. URLs are designed >to map to resources (real or virtual) so using a '.' is creating your >own URL scheme when a normal URL would have been good enough. Hmm ... is >there a problem with simply converting a URL of preferences/simple to a >module called preferences.simple? My rational is that it's a module name, not a URL, so it should follow the python module naming rules. >>In the flat case, we create a dummy module at the root, called >>'__alpage__', and we load the page modules into that. If a hierarchy >>of page modules is used, dummy modules have to be created to represent >>the intervening directories. So... if you have the following: >> >> login.py >> preferences/simple.py >> preferences/advanced.py >> >>they would be loaded as: >> >> __alpage__ (dummy) >> __alpage__.login.py >> __alpage__.preferences (dummy) >> __alpage__.preferences.simple >> __alpage__.preferences.advanced >> >>get_module_holder() just makes sure the dummies are created (recursively) >>and returns the parent of the module to be loaded. > >Ah, ok. I understand now. Would this work if I wanted the URL >"preferences" *and* "preferences/simple" to work correctly or would the >dummy __alpage__.preferences module get in the way? No, the dummy will get in the way (and in some obscure ways). >I actually thought your preferred solution was to use *real* application >packages and modules (which I guess is why I was a little confused about >your "dummy parent modules" comment) but I've reread the thread and >found mention of a "synthetic namespace". The problem with this is backward compatibility. I'm also not sure how to make the imp module work sensibly with __init__.py - I'm reading the source now. We can't just use __import__ as that does a lot of stuff we don't want. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Tue Jan 13 20:24:04 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 13 Jan 2004 20:24:04 +1100 Subject: [albatross-users] page module import magic [PATCH included] In-Reply-To: Message from Matt Goodall of "Mon, 12 Jan 2004 14:33:24 -0000." <4002B034.40400@pollenation.net> References: <20040112120706.180113C517@coffee.object-craft.com.au> <40029635.6000909@pollenation.net> <20040112130424.D2F073C517@coffee.object-craft.com.au> <4002B034.40400@pollenation.net> Message-ID: <20040113092404.18F8C3C517@coffee.object-craft.com.au> >Hierarchies of pages do work but not quite correctly in the released >code base, hence my original bug report. The only problem with them is >the corruption of sys.modules. Perhaps Albatross was never really meant >to be used like this? There was code to explicitly support pages with names like "foo/bah", so I think Dave's intention was to support them. I think Dave's implementation would have failed when a sub-page module contained a class definition, an instance of which appeared in the context (did that make sense? The module path was wrong, so it couldn't restore the class definition on unpickle). >For me, using a '.' for this purpose in a URL is odd. URLs are designed >to map to resources (real or virtual) so using a '.' is creating your >own URL scheme when a normal URL would have been good enough. Hmm ... is >there a problem with simply converting a URL of preferences/simple to a >module called preferences.simple? I replied to this earlier in the day (to me it's a module name, rather than a URL) - but in the latest version of the patch (attached), I do replace('/', '.'), so either will work. >>get_module_holder() just makes sure the dummies are created (recursively) >>and returns the parent of the module to be loaded. > >Ah, ok. I understand now. Would this work if I wanted the URL >"preferences" *and* "preferences/simple" to work correctly or would the >dummy __alpage__.preferences module get in the way? The latest version of the patch copes with this also. >I actually thought your preferred solution was to use *real* application >packages and modules (which I guess is why I was a little confused about >your "dummy parent modules" comment) but I've reread the thread and >found mention of a "synthetic namespace". My feeling is that there are fundemental differences between python packages and directories containing page modules - in particular, the coupling between modules in a python package is tighter, whereas a directory full of page modules is just an organisational thing. I also don't like the fact that existing users will have to go around dropping useless __init__.py files everywhere. There are additional issues caused by the package namespace rules... so if you have a module A.B.C, then getattr(A.B, 'C') should return module C by normal python rules. It seems wrong that page module A.B should "contain" page module A.B.C. It also seems wrong that loading page module A.B.C should load A and A.B as well. >>That pretty much describes the changes - does it make more sense now? >> >Yes, that's great. Thanks. As always, if what I say doesn't make sense, tell me. 8-) >I would be grateful if you could keep me updated on the solution you >choose. I would need to change my code in a number of places to use a >'.' in the URL but it's probably not too big a problem and I would >rather use an official Albatross release than my patched version. >However, nice URLs will be important to me for some future projects. Try this version if you do... Index: app.py =================================================================== RCS file: /usr/local/cvsroot/object-craft/albatross/albatross/app.py,v retrieving revision 1.87 diff -u -d -r1.87 app.py --- app.py 9 Jan 2004 12:38:27 -0000 1.87 +++ app.py 13 Jan 2004 09:07:59 -0000 @@ -7,7 +7,6 @@ import os import sys -import stat import imp import urlparse @@ -374,10 +373,11 @@ '''Caching module loader ''' + mod_holder_name = '__alpage__' + def __init__(self, base_dir, start_page): self.__base_dir = base_dir self.__start_page = start_page - self.__cache = {} def module_path(self): return self.__base_dir @@ -393,35 +393,52 @@ ctx.set_page(name) self.load_page_module(ctx, name) + def is_page_module(self, name): + return name.startswith(self.mod_holder_name) + def load_page_module(self, ctx, name): - if self.__base_dir == '.': - path = name + mod_path = name.replace('/', '.').split('.') + if mod_path[0] != self.mod_holder_name: + mod_path.insert(0, self.mod_holder_name) + # Create module path out of dummy modules, if needed + for i in range(len(mod_path) - 1, 0, -1): + mod_name = '.'.join(mod_path[:i]) + try: + sys.modules[mod_name] + break + except KeyError: + sys.modules[mod_name] = imp.new_module(mod_name) + # Now see if it's already loaded + mod_name = '.'.join(mod_path) + try: + module = sys.modules[mod_name] + except KeyError: + # Nope + pass else: - path = os.path.join(self.__base_dir, name) - page = self.__cache.get(path) - if page: - mtime = os.stat(page.__file__)[stat.ST_MTIME] - if mtime > page.__mtime__: - reload(page) - page.__mtime__ = mtime - if not page: - dirname, name = os.path.split(path) - file, filepath, desc = imp.find_module(name, [dirname]) - page = sys.modules.get(name) - if not page or not page.__file__.startswith(filepath): - try: - page = imp.load_module(name, file, filepath, desc) - finally: - if file: - file.close() - if not (hasattr(page, 'page_enter') or - hasattr(page, 'page_leave') or - hasattr(page, 'page_process') or - hasattr(page, 'page_display')): - raise ApplicationError('module "%s" does not define one of page_enter, page_leave, page_process or page_display' % (name)) - page.__mtime__ = os.stat(page.__file__)[stat.ST_MTIME] - self.__cache[path] = page - ctx.page = page + # The name exists, but is it a dummy or the real thing? + if hasattr(module, '__file__'): + # Real? Then return it + ctx.page = module + return module + # Dummy? but we want the real thing... so continue + mod_dir = os.path.join(self.__base_dir, *mod_path[1:-1]) + try: + f, filepath, desc = imp.find_module(mod_path[-1], [mod_dir]) + except ImportError, e: + raise ApplicationError('%s (in %s)' % (e, mod_dir)) + try: + module = imp.load_module(mod_name, f, filepath, desc) + finally: + if f: + f.close() + if not (hasattr(module, 'page_enter') or + hasattr(module, 'page_leave') or + hasattr(module, 'page_process') or + hasattr(module, 'page_display')): + raise ApplicationError('module "%s" does not define one of page_enter, page_leave, page_process or page_display' % (name)) + sys.modules[mod_name] = ctx.page = module + return module def page_enter(self, ctx, args): if hasattr(ctx.page, 'page_enter'): @@ -451,8 +468,8 @@ self.__start_page = start_page self.__page_objects = {} - def module_path(self): - pass + def is_page_module(self, name): + return False def start_page(self): return self.__start_page Index: context.py =================================================================== RCS file: /usr/local/cvsroot/object-craft/albatross/albatross/context.py,v retrieving revision 1.93 diff -u -d -r1.93 context.py --- context.py 21 Sep 2003 04:40:31 -0000 1.93 +++ context.py 13 Jan 2004 09:08:00 -0000 @@ -10,6 +10,7 @@ import stat import re import cPickle +import __builtin__ try: import zlib @@ -564,9 +565,13 @@ self.clear_locals() def decode_session(self, text): - module_path = self.app.module_path() - if module_path: - sys.path.insert(0, module_path) + def imp_hook(name, globals, locals, fromlist): + if self.app.is_page_module(name): + return self.app.load_page_module(self, name) + else: + return real_imp(name, globals, locals, fromlist) + + real_imp, __builtin__.__import__ = __builtin__.__import__, imp_hook try: try: vars = cPickle.loads(text) @@ -577,8 +582,7 @@ for name in vars.keys(): self.__vars[name] = 1 finally: - if module_path: - sys.path.remove(module_path) + __builtin__.__import__ = real_imp def encode_session(self): vars = {} -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Wed Jan 14 04:33:49 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Tue, 13 Jan 2004 12:33:49 -0500 Subject: [albatross-users] HTTP Status handling fixes Message-ID: > I've just checked in a bunch of fixes to the handling of HTTP > Status codes > within Albatross. Are we closer to having nightly snapshots of CVS? Mike From andrewm at object-craft.com.au Wed Jan 14 09:43:16 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 14 Jan 2004 09:43:16 +1100 Subject: [albatross-users] HTTP Status handling fixes In-Reply-To: Message from "Michael C. Neel" of "Tue, 13 Jan 2004 12:33:49 CDT." References: Message-ID: <20040113224316.629283C517@coffee.object-craft.com.au> >> I've just checked in a bunch of fixes to the handling of HTTP=20 >> Status codes >> within Albatross.=20 > >Are we closer to having nightly snapshots of CVS? Sorry - I changed my mind. I think nightly snapshots would create chaos - we'd never quite be sure what code someone was running or was being discussed on the list. We just need to try harder to get snapshots out there (and calling them "snapshots" rather than "release candidates" might help that... what did happen to that release, anyway? 8-) 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Wed Jan 14 15:19:15 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 14 Jan 2004 15:19:15 +1100 Subject: [albatross-users] How to get https protocol from al-a tags? In-Reply-To: Message from "Michael C. Neel" of "Mon, 12 Jan 2004 17:16:43 CDT." References: Message-ID: <20040114041915.091DA3C89A@coffee.object-craft.com.au> >where it's going on. You could change the http to https, but really IMHO >albatross shouldn't be putting http(s) and servername into a url, I agree. >prefixing with '/' at the beginning is a lot easier to move between sites. >I've also done sites with wildcards for dns and servername, and this would >be a problem here too. I don't know what the gain is for building the >full url, so there maybe a reason to have it, but changing it to: That's a good question - I don't know the answer, which it makes me nervous to change it. > def redirect_url(self, loc): return self.absolute_base_url() + loc > >should solve your problem, but that's untested so you may need to test it >a bit. The following is more complex, but I think the result is more consistent (certainly than the original implementation): def redirect_url(self, loc): scheme, netloc, path = urlparse.urlparse(loc)[:3] if scheme or netloc: return loc # Already absolute scheme, netloc, path = self._parse_current_uri() if loc.startswith('/'): return urlparse.urlunparse((scheme, netloc, loc, '', '', '')) new_base = self.absolute_base_url() if new_base[-1] != '/': new_base = new_base + '/' return urlparse.urlunparse((scheme, netloc, new_base + loc, '', '', '')) I'll include this in the next snapshot, as well as some tests for it. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Wed Jan 14 19:05:33 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 14 Jan 2004 19:05:33 +1100 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 Message-ID: <20040114080533.9D3703C89A@coffee.object-craft.com.au> A development preview snapshot is now available: http://www.object-craft.com.au/projects/albatross/download/albatross-1.2-dev-20040114.tar.gz New since 1.11pre2: 2004-01-14 15:36 andrewm * doc/doctest/: tags-for7, tags-form-action, tags-form-file, tags-input-checkbox, tags-input-file, tags-input-generic, tags-input-image, tags-input-radio1, tags-input-radio2, tags-input-radio3: Updated examples to python 2.3 2004-01-14 15:22 andrewm * albatross/app.py, test/misc/__init__.py: Fixes to redirect_url() suggested by Sheila King and Michael Neel, and some associated tests. 2004-01-14 13:57 andrewm * albatross/app.py, albatross/context.py, doc/.cvsignore, doc/mixins.tex, test/all.py, test/misc/.cvsignore, test/misc/__init__.py, test/misc/pagemodule.py, test/misc/modules/.cvsignore, test/misc/modules/missing_methods.py, test/misc/modules/run_template.py, test/misc/modules/simple.html, test/misc/modules/simple_module.py, test/misc/modules/submod.py, test/misc/modules/submod/.cvsignore, test/misc/modules/submod/module_decode.py, test/misc/modules/submod/module_hierarchy.py: Import page modules into a dummy module to prevent them from poluting the python module namespace. Use an import hook to load page modules, rather than prefixing sys.path around the cPickle.loads in decode_session(). Added tests for the new page module loader. 2004-01-14 11:19 andrewm * albatross/tags.py: - minor rationalisation of attribute handling. 2004-01-09 23:38 andrewm * albatross/apacheapp.py, albatross/app.py, albatross/cgiapp.py, albatross/common.py, albatross/httpdapp.py, standalone-server/al-httpd: * added HTTP/1.0 status header definitions from RFC1945 as well as some helper methods to classify status codes and a method to convert a status code into a string. Converted all hard coded status codes to use the new symbolic HTTP_* names. * in cgiapp.Request, if status is not "200 OK", then emit a "Status:" header. * when an exception occurs, set status to HTTP_INTERNAL_SERVER_ERROR * refactored httpdapp - it's Request class now proxies requests directly to the handler - previously it saved the data and the handler pulled it out and called methods on the base. * httpdapp status_resources is now a list of tuples, although a dictionary will still be accepted. This allows the resources to be ordered by priority. * httpdapp: output content even when status != 200 (otherwise no tracebacks!) * changed al-httpd's argument parsing to give the usage message when the status resources aren't paired. 2004-01-09 15:34 andrewm * TODO, albatross/apacheapp.py, albatross/app.py, albatross/httpdapp.py, doc/mixins.tex: * bugfix - response header handling should not have been case sensitive. * enhancement - allow multiple headers with the same name (Cookies, in particular). NOTE: that ResponseMixin.get_header() now returns a list. * Changed httpdapp to store headers in a list, rather than a dictionary (allows multiple headers of the same name). 2004-01-09 11:32 andrewm * TODO, albatross/app.py, doc/appuser.tex, doc/tags.tex, samples/popview1/popview.py, samples/popview2/popview.py: * Fixed: is confusing. Consider having ctx.req_equals() check for "name.x" if "name" doesn't exist? (Michael C. Neel) 2003-11-10 11:35 djc * albatross/app.py: Fix Cookie path bug noticed in Safari where absolute_base_url() was generating /path/app.cgi/ instead of /path/app.cgi. This was causing problems for requests like /path/app.cgi?blah in that Safari did not send the cookie (probably correctly). 2003-10-03 13:56 djc * dist/dist-albatross.sh, doc/Makefile, doc/albatross.tex, doc/installation.tex, doc/pstumble: Remove the PostScript booklet from the distribution - acroread 5 doesn't like the PDF created by pdflatex while converting to PS. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Thu Jan 15 02:36:20 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Wed, 14 Jan 2004 10:36:20 -0500 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 Message-ID: Did you check those things off the TODO list? =p I'll try to get this soon and check it out/test the changes. Mike > -----Original Message----- > From: Andrew McNamara [mailto:andrewm at object-craft.com.au] > Sent: Wednesday, January 14, 2004 3:06 AM > To: albatross-users at object-craft.com.au > Subject: [albatross-users] Albatross development preview > 1.2-dev-20040114 > > > A development preview snapshot is now available: > > > http://www.object-craft.com.au/projects/albatross/download/alb > atross-1.2-dev-20040114.tar.gz > > New since 1.11pre2: > > 2004-01-14 15:36 andrewm > > * doc/doctest/: tags-for7, tags-form-action, tags-form-file, > tags-input-checkbox, tags-input-file, tags-input-generic, > tags-input-image, tags-input-radio1, tags-input-radio2, > tags-input-radio3: Updated examples to python 2.3 > > 2004-01-14 15:22 andrewm > > * albatross/app.py, test/misc/__init__.py: Fixes to > redirect_url() > suggested by Sheila King and Michael Neel, and some associated > tests. > > 2004-01-14 13:57 andrewm > > * albatross/app.py, albatross/context.py, doc/.cvsignore, > doc/mixins.tex, test/all.py, test/misc/.cvsignore, > test/misc/__init__.py, test/misc/pagemodule.py, > test/misc/modules/.cvsignore, > test/misc/modules/missing_methods.py, > test/misc/modules/run_template.py, > test/misc/modules/simple.html, > test/misc/modules/simple_module.py, test/misc/modules/submod.py, > test/misc/modules/submod/.cvsignore, > test/misc/modules/submod/module_decode.py, > test/misc/modules/submod/module_hierarchy.py: Import > page modules > into a dummy module to prevent them from poluting the > python module > namespace. Use an import hook to load page modules, rather than > prefixing sys.path around the cPickle.loads in > decode_session(). > Added tests for the new page module loader. > > 2004-01-14 11:19 andrewm > > * albatross/tags.py: > - minor rationalisation of attribute handling. > > 2004-01-09 23:38 andrewm > > * albatross/apacheapp.py, albatross/app.py, albatross/cgiapp.py, > albatross/common.py, albatross/httpdapp.py, > standalone-server/al-httpd: > * added HTTP/1.0 status header definitions from RFC1945 > as well as > some helper methods to classify status codes and a > method to convert > a status code into a string. Converted all hard coded > status codes > to use the new symbolic HTTP_* names. > * in cgiapp.Request, if status is not "200 OK", then emit a > "Status:" header. > * when an exception occurs, set status to > HTTP_INTERNAL_SERVER_ERROR > * refactored httpdapp - it's Request class now proxies requests > directly to the handler - previously it saved the data and the > handler pulled it out and called methods on the base. > * httpdapp status_resources is now a list of tuples, although a > dictionary will still be accepted. This allows the > resources to be > ordered by priority. > * httpdapp: output content even when status != 200 (otherwise no > tracebacks!) > * changed al-httpd's argument parsing to give the usage > message when > the status resources aren't paired. > > 2004-01-09 15:34 andrewm > > * TODO, albatross/apacheapp.py, albatross/app.py, > albatross/httpdapp.py, doc/mixins.tex: > * bugfix - response header handling should not have been case > sensitive. > * enhancement - allow multiple headers with the same > name (Cookies, > in particular). NOTE: that ResponseMixin.get_header() > now returns a > list. > * Changed httpdapp to store headers in a list, rather than a > dictionary (allows multiple headers of the same name). > > 2004-01-09 11:32 andrewm > > * TODO, albatross/app.py, doc/appuser.tex, doc/tags.tex, > samples/popview1/popview.py, samples/popview2/popview.py: > * Fixed: is confusing. Consider having > ctx.req_equals() check for "name.x" if "name" doesn't exist? > (Michael C. Neel) > > 2003-11-10 11:35 djc > > * albatross/app.py: Fix Cookie path bug noticed in Safari where > absolute_base_url() was generating /path/app.cgi/ instead of > /path/app.cgi. This was causing problems for requests like > /path/app.cgi?blah in that Safari did not send the > cookie (probably > correctly). > > 2003-10-03 13:56 djc > > * dist/dist-albatross.sh, doc/Makefile, doc/albatross.tex, > doc/installation.tex, doc/pstumble: Remove the > PostScript booklet > from the distribution - acroread 5 doesn't like the PDF > created by > pdflatex while converting to PS. > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat ross-users From neel at mediapulse.com Thu Jan 15 04:53:13 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Wed, 14 Jan 2004 12:53:13 -0500 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 Message-ID: The status update isn't working correctly on mod_python (I have tried other request interfaces). On an error it's returning a double set of 200 OK pages. If traceback.html is present, it is displayed first, then a second set of headers and the apache generated OK page. If there is no traceback.html, traceback is displayed, again followed by a second set of headers and the apache OK page. In both cases the status of the page is 200, and an error log entry for a 500 requesst is not entered. I'm looking around to see why this isn't working. Mike From andrewm at object-craft.com.au Thu Jan 15 13:33:02 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 15 Jan 2004 13:33:02 +1100 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 In-Reply-To: Message from "Michael C. Neel" of "Wed, 14 Jan 2004 12:53:13 CDT." References: Message-ID: <20040115023302.B07173C8A0@coffee.object-craft.com.au> >The status update isn't working correctly on mod_python (I have tried >other request interfaces). You've tried *every* other request interface? Or did you mean you haven't tried any other request interfaces? >On an error it's returning a double set of 200 OK pages. If >traceback.html is present, it is displayed first, then a second set of >headers and the apache generated OK page. If there is no traceback.html, >traceback is displayed, again followed by a second set of headers and the >apache OK page. In both cases the status of the page is 200, and an error >log entry for a 500 requesst is not entered. Albatross never before attempted to set any status other than 200 - the changes are tickling behaviour that hasn't been used before. It turns out that, with mod_python, if you want to generate your own error page, you need to return apache.OK, and set the mod_python req.status attribute. Because there are deployed apps out there, I'm thinking of making Application.run() return 0 unconditionally, and applying a patch like this to apacheapp.py: --- apacheapp.py 9 Jan 2004 12:38:27 -0000 1.25 +++ apacheapp.py 15 Jan 2004 02:31:44 -0000 @@ -48,10 +48,8 @@ self.__req.write(data) def set_status(self, status): + self.__req.status = status self.__status = status def status(self): - if self.__status == HTTP_OK: - return apache.OK - else: - return self.__status + return self.__status -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Fri Jan 16 08:54:50 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Thu, 15 Jan 2004 16:54:50 -0500 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 Message-ID: > You've tried *every* other request interface? Or did you mean > you haven't > tried any other request interfaces? Sorry, I meant to say I haven't tried. I did check multiple headers in mod_python, and that is working ok. Soon we will have a server dedicated to developer testing. When that gets going, I'll be able to quickly test new snapshots against Apache 1.3, 2 worker and prefork with mod_python. So I'll be your mod_python clearing house tester =p. From neel at mediapulse.com Fri Jan 16 10:54:32 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Thu, 15 Jan 2004 18:54:32 -0500 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 Message-ID: > Because there are deployed apps out there, I'm thinking of making > Application.run() return 0 unconditionally, and applying a patch like > this to apacheapp.py: > This only has an effect in mod_python 3.x, 2.x ignores this and I've been unable to come up with a solution for traceback errors to be status 500 on Apache 1.3. We are okay atm, because on a live site we'd never show that information anyway, and use a traceback.html. So for now we use apache ErrorDocument directives on the live side of things, and even has the upshot of having al- tags in the error page, which you can't do for traceback.html (which is to be expected). One small plus is setting req.status in 2.x has zero effect, so need to have code to check versions before applying. Just for fun and thoughts, here is the current class we use for the cusomt error handling. It's a little tied to the way we pass in some extra members to req, such as req.debug and req.config. Also, I wasn't able to get everything I wanted out of req itself, so it's also mod_python centric. Mike class MPErrorHandlingApp(albatross.SimpleApp): '''App class to control traceback error messages. If req.debug is true, display the normal traceback information. If req.debug is false, it will set the status to 404 or 500 which is returned to apache If req.config has a key 'developer_email' it will email the traceback and other details to the developer on an error. Currently this class relies on the mod_python request class.''' email_template='''To: %(dev_email)s From: Traceback Subject: [TRACEBACK] - %(website)s %(error)s Connection Details: Server: %(website)s:%(port)s Request: %(request)s Client IP/DNS: %(client_dns)s Date/Time: %(timestamp)s Client Headers: %(headers)s %(htmlexc)s %(pyexc)s Form Data: %(data)s ''' def handle_exception(self, ctx, req): etype, value, tb = sys.exc_info() pyexc = traceback.format_exception(etype, value, tb) htmlexc = [] htmlexc.append('Template traceback (most recent call last):\n') for tup in self.template_traceback(tb): htmlexc.append(' File "%s", line %s, in %s\n' % tup) line = string.rstrip(linecache.getline(tup[0], tup[1])) if line: htmlexc.append(line + '\n') if req.debug: req.write_header('Content-Type', 'text/html') req.end_headers() req.write_content('
')
            req.write_content(''.join(map(lambda x:
albatross.tags.escape(x), htmlexc)))
            req.write_content('\n\n')
            req.write_content(''.join(map(lambda x:
albatross.tags.escape(x), pyexc)))
            req.write_content('
') else: if pyexc[-1].find("TemplateLoadError:") >= 0: req.set_status(404) else: req.set_status(500) if req.config.has_key('developer_email') and pyexc[-1].find("TemplateLoadError:") == -1: details = { 'dev_email': req.config['developer_email'], 'website': req.get_servername(), 'htmlexc': ''.join(htmlexc), 'pyexc': ''.join(pyexc), 'headers': '', 'data': '', 'request': req._Request__req.unparsed_uri, 'client_dns': req._Request__req.get_remote_host(), 'timestamp': time.asctime(), 'port': req._Request__req.server.port, 'error': pyexc[-1] } for field in req.field_names(): details['data'] = details['data'] + ' %s: %s\n' % (field, req.field_value(field)) for header in req._Request__req.headers_in.keys(): details['headers'] = details['headers'] + ' %s: %s\n' % (header, req._Request__req.headers_in[header]) mailserver = smtplib.SMTP("localhost") mailserver.sendmail(details['dev_email'], [details['dev_email'],], self.email_template % details) mailserver.quit() From andrewm at object-craft.com.au Fri Jan 16 11:46:45 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 16 Jan 2004 11:46:45 +1100 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 In-Reply-To: Message from "Michael C. Neel" of "Thu, 15 Jan 2004 18:54:32 CDT." References: Message-ID: <20040116004645.6EF383C89A@coffee.object-craft.com.au> >This only has an effect in mod_python 3.x, 2.x ignores this and I've >been unable to come up with a solution for traceback errors to be status >500 on Apache 1.3. We are okay atm, because on a live site we'd never >show that information anyway, and use a traceback.html. So for now we >use apache ErrorDocument directives on the live side of things, and even >has the upshot of having al- tags in the error page, which you can't do >for traceback.html (which is to be expected). > >One small plus is setting req.status in 2.x has zero effect, so need to >have code to check versions before applying. I've been testing with mod_python 2.7.10 and apache 1.3.29 - setting req.status to 500 (for example) is working fine here: $ telnet localhost 80 GET http://localhost/cgi-bin/modpytest/modpytest.py HTTP/1.0 HTTP/1.1 500 Internal Server Error Date: Fri, 16 Jan 2004 00:45:47 GMT Server: Apache/1.3.29 (Debian GNU/Linux) mod_python/2.7.10 Python/2.3.2 DAV/1.0.3 Connection: close Content-Type: text/html; charset=iso-8859-1 
Template traceback (most recent call last):

    Traceback (most recent call last):
      File "/usr/lib/python2.3/site-packages/albatross/app.py", line 283, in run
        self.display_response(ctx)
      File "/usr/lib/python2.3/site-packages/albatross/app.py", line 516, in display_response
        func(ctx)
      File "/usr/lib/cgi-bin/modpytest/modpytest.py", line 17, in page_display
        ctx.run_template('foo.html')
      File "/usr/lib/python2.3/site-packages/albatross/app.py", line 158, in run_template
        templ = self.app.load_template(name)
      File "/usr/lib/python2.3/site-packages/albatross/context.py", line 181, in load_template
        raise TemplateLoadError("%s: %s" % (path, e.strerror))
    TemplateLoadError: /usr/lib/cgi-bin/modpytestx/foo.html: No such file or directory
Connection closed by foreign host. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Sat Jan 17 02:08:41 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Fri, 16 Jan 2004 10:08:41 -0500 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 Message-ID: > I've been testing with mod_python 2.7.10 and apache 1.3.29 - setting > req.status to 500 (for example) is working fine here: Where are you snagging 2.7.10 from? Latest release is 2.7.9, and I didn't see any mention on the mailing lists of a 2.7.10 in progress. If someone went and fixed this after I mentioned this on the mp list, I'd love to know who and thank them! Mike From andrewm at object-craft.com.au Mon Jan 19 09:48:13 2004 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 19 Jan 2004 09:48:13 +1100 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 In-Reply-To: Message from "Michael C. Neel" of "Fri, 16 Jan 2004 10:08:41 CDT." References: Message-ID: <20040118224813.6CBE43C89A@coffee.object-craft.com.au> >> I've been testing with mod_python 2.7.10 and apache 1.3.29 - setting >> req.status to 500 (for example) is working fine here: > >Where are you snagging 2.7.10 from? Latest release is 2.7.9, and I >didn't see any mention on the mailing lists of a 2.7.10 in progress. If >someone went and fixed this after I mentioned this on the mp list, I'd >love to know who and thank them! Ha - I'm using Debian's "testing" package of mod-python - possibly it's been extracted from CVS? -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Wed Jan 21 06:52:15 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Tue, 20 Jan 2004 14:52:15 -0500 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 Message-ID: I apperently was missing some emails from the mod python lists, and didn't see a 2.7.10 up to test. I just went though and testing it and gave grisha a +1, so hopefully it's out as stable soon. Also req.status was working correctly, and your proposed patch (always return apache.OK and set req.status with the real status) should work without issue. Mike From matt at pollenation.net Sun Jan 25 10:30:40 2004 From: matt at pollenation.net (Matt Goodall) Date: Sat, 24 Jan 2004 23:30:40 +0000 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 In-Reply-To: <20040114080533.9D3703C89A@coffee.object-craft.com.au> References: <20040114080533.9D3703C89A@coffee.object-craft.com.au> Message-ID: <1074987040.5970.70.camel@debian> On Wed, 2004-01-14 at 08:05, Andrew McNamara wrote: > A development preview snapshot is now available: > > http://www.object-craft.com.au/projects/albatross/download/albatross-1.2-dev-20040114.tar.gz Thanks Andrew. It's great to have the list of changes too. [snip] > 2004-01-14 15:22 andrewm > > * albatross/app.py, test/misc/__init__.py: Fixes to redirect_url() > suggested by Sheila King and Michael Neel, and some associated > tests. I reread the thread this change came from, and I should probably have picked up on this sooner, but the Location HTTP response header should be a *full* URL, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. I think there are some browsers that have difficulty with partial URLs and I also understand that Apache can "intercept" a partial URL and do an internal redirect which is probably not a good idea. I can't find proof for either of those statements but the partial URL certainly breaks my app's redirects (using SCGI). I guess the fix is to add a get_scheme() (protocol?) method to the Request classes to find out whether it's HTTP or HTTPS. That way we have get_scheme(), get_servername(), get_uri() and the absolute URL which should make it possible to build a full URL from just about anything. I've got a workaround for the redirect problem so I will run with this release and see what happens. Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt at pollenation.net Any views expressed are my own and do not necessarily reflect the views of my employer. From matt at pollenation.net Sun Jan 25 10:36:51 2004 From: matt at pollenation.net (Matt Goodall) Date: Sat, 24 Jan 2004 23:36:51 +0000 Subject: [albatross-users] [patch] set ctx.locals.__page for random apps In-Reply-To: <20040114080533.9D3703C89A@coffee.object-craft.com.au> References: <20040114080533.9D3703C89A@coffee.object-craft.com.au> Message-ID: <1074987411.5972.74.camel@debian> Any chance of sneaking the attached patch into the next release? Thanks, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt at pollenation.net Any views expressed are my own and do not necessarily reflect the views of my employer. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 506 bytes Desc: not available URL: From matt at pollenation.net Sun Jan 25 10:38:35 2004 From: matt at pollenation.net (Matt Goodall) Date: Sat, 24 Jan 2004 23:38:35 +0000 Subject: [albatross-users] Albatross development preview 1.2-dev-20040114 In-Reply-To: <20040114080533.9D3703C89A@coffee.object-craft.com.au> References: <20040114080533.9D3703C89A@coffee.object-craft.com.au> Message-ID: <1074987515.5972.77.camel@debian> Andrew, Just to let you know that your new random module loader /seems/ to be working just fine. I haven't done extensive tests yet but things look good. Thanks! I can now use the release version of Albatross again. :) Cheers, Matt -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt at pollenation.net Any views expressed are my own and do not necessarily reflect the views of my employer. From neel at mediapulse.com Sun Jan 25 14:56:29 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Sat, 24 Jan 2004 22:56:29 -0500 Subject: [albatross-users] Albatross development preview1.2-dev-20040114 In-Reply-To: <1074987040.5970.70.camel@debian> Message-ID: <007c01c3e2f7$3681c6a0$0200a8c0@CLAPTON> The URL issue was not in relation to redirect_url, but the processing of the al-a and similar tags which were building links with the protocol and servername. This isn't needed in al-a, since a prefix of '/' will do nicely and not care about protocol, servername, port, etc. > -----Original Message----- > From: albatross-users-admin at object-craft.com.au > [mailto:albatross-users-admin at object-craft.com.au] On Behalf > Of Matt Goodall > Sent: Saturday, January 24, 2004 6:31 PM > To: Andrew McNamara > Cc: albatross-users > Subject: Re: [albatross-users] Albatross development > preview1.2-dev-20040114 > > > On Wed, 2004-01-14 at 08:05, Andrew McNamara wrote: > > A development preview snapshot is now available: > > > > > http://www.object-craft.com.au/projects/albatross/download/alb > atross-1.2-dev-20040114.tar.gz > > Thanks Andrew. It's great to have the list of changes too. > > [snip] > > 2004-01-14 15:22 andrewm > > > > * albatross/app.py, test/misc/__init__.py: Fixes to > redirect_url() > > suggested by Sheila King and Michael Neel, and some associated > > tests. > > I reread the thread this change came from, and I should probably have > picked up on this sooner, but the Location HTTP response header should > be a *full* URL, see > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. > > I think there are some browsers that have difficulty with partial URLs > and I also understand that Apache can "intercept" a partial URL and do > an internal redirect which is probably not a good idea. I can't find > proof for either of those statements but the partial URL certainly > breaks my app's redirects (using SCGI). > > I guess the fix is to add a get_scheme() (protocol?) method to the > Request classes to find out whether it's HTTP or HTTPS. That > way we have > get_scheme(), get_servername(), get_uri() and the absolute URL which > should make it possible to build a full URL from just about anything. > > I've got a workaround for the redirect problem so I will run with this > release and see what happens. > > Cheers, Matt > > -- > Matt Goodall, Pollenation Internet Ltd > w: http://www.pollenation.net > e: matt at pollenation.net > > Any views expressed are my own and do not necessarily reflect > the views of my employer. > > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat ross-users From matt at pollenation.net Sun Jan 25 22:07:25 2004 From: matt at pollenation.net (Matt Goodall) Date: Sun, 25 Jan 2004 11:07:25 +0000 Subject: [albatross-users] Albatross development preview1.2-dev-20040114 In-Reply-To: <007c01c3e2f7$3681c6a0$0200a8c0@CLAPTON> References: <007c01c3e2f7$3681c6a0$0200a8c0@CLAPTON> Message-ID: <1075028844.6165.125.camel@debian> On Sun, 2004-01-25 at 03:56, Michael C. Neel wrote: > The URL issue was not in relation to redirect_url, but the processing of > the al-a and similar tags which were building links with the protocol > and servername. This isn't needed in al-a, since a prefix of '/' will > do nicely and not care about protocol, servername, port, etc. Yes, that is true but the result of the thread was that redirect_url() was changed ... which is used to build a Location URL as well as an URL. To be honest, I was really commenting on my being slow at not spotting the issue earlier. Is there actually a problem with making a link a full (correctly generated) URL? I can't see why that would be the case but I haven't thought about it much. Cheers, Matt > > > -----Original Message----- > > From: albatross-users-admin at object-craft.com.au > > [mailto:albatross-users-admin at object-craft.com.au] On Behalf > > Of Matt Goodall > > Sent: Saturday, January 24, 2004 6:31 PM > > To: Andrew McNamara > > Cc: albatross-users > > Subject: Re: [albatross-users] Albatross development > > preview1.2-dev-20040114 > > > > > > On Wed, 2004-01-14 at 08:05, Andrew McNamara wrote: > > > A development preview snapshot is now available: > > > > > > > > http://www.object-craft.com.au/projects/albatross/download/alb > > atross-1.2-dev-20040114.tar.gz > > > > Thanks Andrew. It's great to have the list of changes too. > > > > [snip] > > > 2004-01-14 15:22 andrewm > > > > > > * albatross/app.py, test/misc/__init__.py: Fixes to > > redirect_url() > > > suggested by Sheila King and Michael Neel, and some associated > > > tests. > > > > I reread the thread this change came from, and I should probably have > > picked up on this sooner, but the Location HTTP response header should > > be a *full* URL, see > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30. > > > > I think there are some browsers that have difficulty with partial URLs > > and I also understand that Apache can "intercept" a partial URL and do > > an internal redirect which is probably not a good idea. I can't find > > proof for either of those statements but the partial URL certainly > > breaks my app's redirects (using SCGI). > > > > I guess the fix is to add a get_scheme() (protocol?) method to the > > Request classes to find out whether it's HTTP or HTTPS. That > > way we have > > get_scheme(), get_servername(), get_uri() and the absolute URL which > > should make it possible to build a full URL from just about anything. > > > > I've got a workaround for the redirect problem so I will run with this > > release and see what happens. > > > > Cheers, Matt > > > > -- > > Matt Goodall, Pollenation Internet Ltd > > w: http://www.pollenation.net > > e: matt at pollenation.net > > > > Any views expressed are my own and do not necessarily reflect > > the views of my employer. > > > > _______________________________________________ > > Albatross-users mailing list > > Albatross-users at object-craft.com.au > > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat > ross-users -- Matt Goodall, Pollenation Internet Ltd w: http://www.pollenation.net e: matt at pollenation.net Any views expressed are my own and do not necessarily reflect the views of my employer. From neel at mediapulse.com Mon Jan 26 00:59:47 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Sun, 25 Jan 2004 08:59:47 -0500 Subject: [albatross-users] Albatross development preview1.2-dev-20040114 Message-ID: > Is there actually a problem with making a link a full > (correctly > generated) URL? I can't see why that would be the case but I haven't > thought about it much. I think the better question is what the need would be? Often the reason I'm building a full link is because I need to change the protocol, servername, or port - most commonly to send someone to a secure section. I also have pages that are sometimes available under both http/https and several server names, not all of the same domain. If al-a and ctx.request.redirect are sharing the same method, then I think best would be to decouple al-a from redirect, and let al-a really be a shorthand for ">, which is hard on the eyes =p Mike From neel at mediapulse.com Mon Jan 26 06:05:01 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Sun, 25 Jan 2004 14:05:01 -0500 Subject: [albatross-users] nameexpr with dicts with str keys Message-ID: Currently, doing a nameexpr="'''mydict['%s']''' % something" will cause an exception at request merge time. The reason for this is it is being assumed that only lists or dicts with numeric keys are used. The offending code is around line 390 (in 1.12 dev): elif state == INDEX: index = int(elem) state = CLOSE Which I changed to this for a work around: elif state == INDEX: try: index = int(elem) except ValueError: index = elem[1:-1] state = CLOSE Some thoughts. This would still cause problems for a dict whose keys were strings, but could be converted to ints, such as zipcodes. Given the "every things is a string" motto on external input, this would be tricky to solve. I guess you could do some recording at the time of encoding the session and look at that later, but until I really *need* this I'm not going there =P Next is it's not exactly straight forward. You could avoid the whole mess with an eval(), but an eval on the tokens of the name of a field seems like a nice way to let hackers play on your server. So I resorted to [1:-1] to srtip off the quotes (otherwise you'll get a mydict[''value''] error). Note going to work on triple quotes, but if you need those inside of an index, share what you're smoking with the rest of the class. Unrelated note: In dumping locals() from the templates I noticed ctx.locals gained a new member, __ctx__. ctx/__ctx__ has quite a few functions in it I'd rather not be in the locals namespace, even if the calling them from the outside would be challenging. Also it's common for our request object to contain usernames/passwords (i.e. for the database), and since ctx.request._Request__ can give you access to the raw mod_python req object, well you see where I'm going. If the __ctx__ member isn't providing the greatest thing since sliced bread, can we put him back in his box? Mike From carl at thereinc.com Thu Jan 29 09:09:10 2004 From: carl at thereinc.com (Carl Higashionna) Date: Wed, 28 Jan 2004 14:09:10 -0800 Subject: [albatross-users] need help: file upload example? Message-ID: Hello All, I'm new to this list and to Albatross. So far I like what I see. The small project I'm working on requires that the user be able to upload an image file to the server. Does anybody have a simple example of how to do this in Albatross? I've searched through the documentation and the email archives but haven't been able to find anything. Thanks, Carl From neel at mediapulse.com Thu Jan 29 09:14:26 2004 From: neel at mediapulse.com (Michael C. Neel) Date: Wed, 28 Jan 2004 17:14:26 -0500 Subject: [albatross-users] need help: file upload example? Message-ID: http://www.object-craft.com.au/projects/albatross/albatross/tag-input-fi le.html It's at the bottom of the page, there by my request ages ago =p Mike > -----Original Message----- > From: Carl Higashionna [mailto:carl at thereinc.com] > Sent: Wednesday, January 28, 2004 5:09 PM > To: albatross-users at object-craft.com.au > Subject: [albatross-users] need help: file upload example? > > > Hello All, > > I'm new to this list and to Albatross. So far I like what I > see. The small > project I'm working on requires that the user be able to > upload an image file to > the server. > > Does anybody have a simple example of how to do this in > Albatross? I've searched > through the documentation and the email archives but haven't > been able to find > anything. > > Thanks, > Carl > > > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albat ross-users From carl at thereinc.com Thu Jan 29 09:44:39 2004 From: carl at thereinc.com (Carl Higashionna) Date: Wed, 28 Jan 2004 14:44:39 -0800 Subject: [albatross-users] need help: file upload example? In-Reply-To: Message-ID: Mike, Thank you so much for the quick reply! I guess I didn't really search the documentation as well as I had thought. This is exactly what I was looking for! Best Regards, Carl