Albatross Popview

From rbb at techgame.net Wed Feb 5 02:53:11 2003 From: rbb at techgame.net (Brian Brown) Date: Tue, 4 Feb 2003 08:53:11 -0700 Subject: [albatross-users] mod_python/ apache2 Message-ID: I'm transferring site from an OpenBSD box using apache 1.3/mod_python 2.7.8 to one using FreeBSD/apache 2.0.44/mod_python 3.0.1. I'm getting some awfully strange behavior... I implemented the ctx.redirect patch that was posted to the newsgroup, and have followed the discussion about the ctx.locals and globals, but am not sure if that is my issue. I have verified that mod_python is working correctly and I get log messages stating that mod_python has imported my handler code. I wasn't getting anything in the browser, so I fired up Lynx and this is what I saw: Looking up dev.norwood.org first Looking up dev.norwood.org dev.norwood.org Making HTTP connection to dev.norwood.org Sending HTTP request. HTTP request sent; waiting for response. HTTP/1.1 301 Moved Permanently Data transfer complete HTTP/1.1 301 Moved Permanently lynx: Start file could not be found or is not text/html or text/plain That's with my handler like this: def handler(req): return app.run(Request(req)) If I have the handler looking like this: def handler(req): app.run(Request(req)) return apache.OK Then it returns nothing whatsoever. Anyone have any ideas? thanks! Brian From gnb at itga.com.au Wed Feb 5 09:53:49 2003 From: gnb at itga.com.au (Gregory Bond) Date: Wed, 05 Feb 2003 09:53:49 +1100 Subject: [albatross-users] mod_python/ apache2 In-Reply-To: Your message of Tue, 04 Feb 2003 08:53:11 -0700. Message-ID: <200302042253.JAA03813@lightning.itga.com.au> I've used mod_python 3.0.1 and albatross on the same FreeBSD setup. It works fine for me, tho I'm using page objects and File-based sessions, and not doing random access (so not using redirects much). From andrewm at object-craft.com.au Tue Feb 11 11:38:57 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 11 Feb 2003 11:38:57 +1100 Subject: [albatross-users] mod_python/ apache2 In-Reply-To: Message from Brian Brown of "Tue, 04 Feb 2003 08:53:11 PDT." References: Message-ID: <20030211003857.104E83CB83@coffee.object-craft.com.au> >I'm transferring site from an OpenBSD box using apache 1.3/mod_python >2.7.8 to one using FreeBSD/apache 2.0.44/mod_python 3.0.1. I'm getting >some awfully strange behavior... I implemented the ctx.redirect patch >that was posted to the newsgroup, and have followed the discussion >about the ctx.locals and globals, but am not sure if that is my issue. > >I have verified that mod_python is working correctly and I get log >messages stating that mod_python has imported my handler code. I wasn't >getting anything in the browser, so I fired up Lynx and this is what I >saw: I'm afraid we haven't had time to look into your problem - there could be a bug in the header handling, but the header handling has been completely re-written in the upcoming Albatross releases to make it more flexible (we haven't had time to finalise this release... 8-) One technique I find useful is using telnet to port 80 - this way you get to see the raw headers before the browser plays with them - you might do: $ telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /cgi-bin/popview/popview.py HTTP/1.0 HTTP/1.1 200 OK Date: Tue, 11 Feb 2003 00:37:29 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_python/2.7.8 Python/2.2.1 DAV/1.0.3 Pragma: no-cache Set-Cookie: popview=e0e901c9c26d791f; Connection: close Content-Type: text/html; charset=iso-8859-1 Albatross Popview

Albatross Popview
Username
Password
POP host
Your session is not encrypted - please log in via HTTPS

Connection closed by foreign host. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Tue Feb 11 11:51:01 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 11 Feb 2003 11:51:01 +1100 Subject: [albatross-users] Unicode and Albatross Message-ID: <20030211005101.081C23CB83@coffee.object-craft.com.au> I'd like to invite list members to post to the list their experiences developing Unicode-aware web applications. Albatross was written before Python supported unicode, and if it works at all in the face of unicode that's more good luck than good management. We need to rectify this, and your input will be appreciated. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From houston at mediapulse.com Thu Feb 13 07:18:21 2003 From: houston at mediapulse.com (Daryl Houston) Date: Wed, 12 Feb 2003 15:18:21 -0500 Subject: [albatross-users] Select tag Message-ID: While working on an extension of the select tag, I noted that if I passed a nameexpr attribute, it was bombing at lines 293-4 of tags.py and raising the error reflected in the source code below: if not self.has_attrib('name') and not self.has_attrib('alias'): self.raise_error('missing "name", "nameexpr", or "alias" attribute') I changed the block to: if not self.has_attrib('name') and not self.has_attrib('nameexpr') and not self.has_attrib('alias'): self.raise_error('missing "name", "nameexpr", or "alias" attribute') Now my code works like a charm. I just wanted to verify that nameexpr was left out unintentionally and that I hadn't tried to correct something that was left out with good reason. Perhaps the issue is that since select boxes pass arrays, one shouldn't be able to loop through values to produce select boxes whose names are arrays (resulting in arrays of arrays passed to the Web server). Or can Albatross/standard Web servers handle that? If nameexpr is not an allowed param here, I wonder if it might be a good idea to add a brief explanation to the error, such as "nameexpr attribute not allowed in al-select tag." I also noted that the code in question bombed even though it was listed between tags. I had the code on one system that didn't try to parse what was between the comment tags. This behavior began when I moved the code to another system. The first was running python 2.2.1 and the second 2.2.2. Consider the following two nearly identical chunks of code:

The first raises: File "/usr/local/lib/python2.2/site-packages/albatross/template.py", line 63, in raise_error raise TemplateError('%s:%s: %s' % (self.filename, self.line_num, msg)) TemplateError: /path/to/stuff/templates/ballot.html:14: missing "name", "nameexpr", or "alias" attribute The second works like a charm. Is this possibly a python version issue? Thanks, D ===================== Daryl L. L. Houston Software Developer/E-commerce Specialist Mediapulse, Inc. 800.380.4514 865-482-4455 ext. 21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewm at object-craft.com.au Fri Feb 14 14:50:55 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 14 Feb 2003 14:50:55 +1100 Subject: [albatross-users] Select tag In-Reply-To: Message from "Daryl Houston" of "Wed, 12 Feb 2003 15:18:21 CDT." References: Message-ID: <20030214035055.73FD03CC5D@coffee.object-craft.com.au> >While working on an extension of the select tag, I noted that if I >passed a nameexpr attribute, it was bombing at lines 293-4 of tags.py >and raising the error reflected in the source code below: > > if not self.has_attrib('name') and not self.has_attrib('alias'): > self.raise_error('missing "name", "nameexpr", or "alias" >attribute') > >I changed the block to: > > if not self.has_attrib('name') and not >self.has_attrib('nameexpr') and not self.has_attrib('alias'): > self.raise_error('missing "name", "nameexpr", or "alias" >attribute') Looks like you're using an old version of Albatross - version 1.01 fixed this bug. >I also noted that the code in question bombed even though it was listed >between tags. Yep - is a tag like any other, and parsing continues inside the tag, but no output is generated. So it's not really a "comment" tag, but I needed something that prevented enclosed text being output (the HTML comment stuff appears in the output). I guess the doco needs to be updated... 8-) >I had the code on one system that didn't try to parse what was between the >comment tags. This behavior began when I moved the code to another >system. The first was running python 2.2.1 and the second 2.2.2. >Consider the following two nearly identical chunks of code: [...] >File "/usr/local/lib/python2.2/site-packages/albatross/template.py", >line 63, in raise_error raise TemplateError('%s:%s: %s' % >(self.filename, self.line_num, msg)) TemplateError: >/path/to/stuff/templates/ballot.html:14: missing "name", "nameexpr", or >"alias" attribute=20 >The second works like a charm. Is this possibly a python version issue? I'm guessing the second has Albatross 1.01 installed... -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Mon Feb 17 17:22:33 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Mon, 17 Feb 2003 01:22:33 -0500 Subject: [albatross-users] ctx.request.write_header, AppContext, and Content-Types Oh my! Message-ID: <000001c2d64c$f547d7e0$af00a8c0@CLAPTON> I've found that there are a few headers that the AppContext's set, and these will overwrite those set by the page object. I needed to set the Content-Type in text/csv in my app, and to do this I had to comment out the offending write_header line in the SimpleAppContext. I did notice that leaving the line commented out, all the other html pages were getting a Content-Type header of text/html, as they should. If this is apache doing this, or Albatross I don't know, but sometimes you don't questing working code too much. I'd like to request that the AppContext's check for any existing header before replacing that header in the next version, or if it is truly safe to pull out the Content-Type header as I have done to just do that. The other header I saw being set was the no-cache header, which right now I can't see a reason I'd wanna change that, but better safe than sorry and allow the app to decide if it need to change the default. Thanks, Mike From andrewm at object-craft.com.au Mon Feb 17 18:14:07 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 17 Feb 2003 18:14:07 +1100 Subject: [albatross-users] ctx.request.write_header, AppContext, and Content-Types Oh my! In-Reply-To: Message from "Michael C. Neel" of "Mon, 17 Feb 2003 01:22:33 CDT." <000001c2d64c$f547d7e0$af00a8c0@CLAPTON> References: <000001c2d64c$f547d7e0$af00a8c0@CLAPTON> Message-ID: <20030217071407.50AC83CC5C@coffee.object-craft.com.au> >I did notice that leaving the line commented out, all the other html >pages were getting a Content-Type header of text/html, as they should. >If this is apache doing this, or Albatross I don't know, but sometimes >you don't questing working code too much. I'd guess it's the web server - strange though. >I'd like to request that the AppContext's check for any existing header >before replacing that header in the next version, or if it is truly safe >to pull out the Content-Type header as I have done to just do that. The >other header I saw being set was the no-cache header, which right now I >can't see a reason I'd wanna change that, but better safe than sorry and >allow the app to decide if it need to change the default. The header stuff has been completely replaced for the next Albatross release (we needed to be able to set Content-Type also... 8-). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From matt at pollenation.net Tue Feb 18 06:44:40 2003 From: matt at pollenation.net (Matt Goodall) Date: 17 Feb 2003 19:44:40 +0000 Subject: [albatross-users] availability of code for next version Message-ID: <1045511079.31571.22.camel@localhost> Hi, I've only recently "discovered" Albatross and, so far, I'm very impressed. So far, it seems to have almost everything I want for web development. Congratulations to the developers! In the mailing list I've noticed a couple of mentions of the next release. Is the development code available to the world, perhaps via anonymous CVS? If not, is there any documentation available on what we can expect? Thanks in advance, Matt -- Matt Goodall, Technical Director Pollenation Internet Ltd, http://www.pollenation.net e: matt at pollenation.net From neel at mediapulse.com Tue Feb 18 07:30:36 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Mon, 17 Feb 2003 15:30:36 -0500 Subject: [albatross-users] ctx.request.write_header, AppContext, and Content-Types Oh my! Message-ID: I should have questioned the code, it wasn't working this morning (the not setting any content-type). I changed the line in the SimpleSessionApp to: def write_headers(self): self.request.write_header('Pragma', 'no-cache') if not self.request.get_header('Content-Type'): self.request.write_header('Content-Type', 'text/html') And it works great. I guess technically I should have created a new class and redifined that one method, but I was lazy ;) BTW, when can we expect the next version? We've deployed 3 sites in Albatross so far, I have a hobby site in Albatross, and we have another 2 projects nearing release in Albtross, so it's an understament to say I'm excited about the next release. Mike -----Original Message----- From: Andrew McNamara [mailto:andrewm at object-craft.com.au] Sent: Monday, February 17, 2003 2:14 AM To: Michael C. Neel Cc: albatross-users at object-craft.com.au Subject: Re: [albatross-users] ctx.request.write_header, AppContext, and Content-Types Oh my! >I did notice that leaving the line commented out, all the other html >pages were getting a Content-Type header of text/html, as they should. >If this is apache doing this, or Albatross I don't know, but sometimes >you don't questing working code too much. I'd guess it's the web server - strange though. >I'd like to request that the AppContext's check for any existing header >before replacing that header in the next version, or if it is truly >safe to pull out the Content-Type header as I have done to just do >that. The other header I saw being set was the no-cache header, which >right now I can't see a reason I'd wanna change that, but better safe >than sorry and allow the app to decide if it need to change the >default. The header stuff has been completely replaced for the next Albatross release (we needed to be able to set Content-Type also... 8-). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From neel at mediapulse.com Tue Feb 18 08:15:39 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Mon, 17 Feb 2003 16:15:39 -0500 Subject: [albatross-users] Axe - Albatross Extensions Message-ID: Fans of Albatross, A co-worker (Daryl) and I have created a library of custom tags to albatross, and created a sourceforge project to house it. It has some tags to help working with albatross and an SQL database, as well as a few tags that will generate Javascript to validate a form. We have some basic documentation done, and a tarball release over at the SF site, http://axe.sourceforge.net At some point it may make sense to merge these tags into Albatross itself, however I feel at this time it does not. Big reason is the object craft guys don't need more work as they are working on Albatross itself, and the second reason is I'm not convinced these highly tailored tag. should be part of the set of standard tags. Of course if the community sees it differently, I'm not going to stand in the way . This is Daryl's and my first venture into creating a python module for distribution, so we are welcome to any input. We've tried to follow what I've seen to be the norm so far, but I'm sure there are areas we can improve upon, and welcome all feedback. Thanks, Mike From andrewm at object-craft.com.au Thu Feb 20 13:52:49 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 20 Feb 2003 13:52:49 +1100 Subject: [albatross-users] availability of code for next version In-Reply-To: Message from Matt Goodall of "17 Feb 2003 19:44:40 -0000." <1045511079.31571.22.camel@localhost> References: <1045511079.31571.22.camel@localhost> Message-ID: <20030220025249.1362F3CC5E@coffee.object-craft.com.au> >I've only recently "discovered" Albatross and, so far, I'm very >impressed. So far, it seems to have almost everything I want for web >development. Congratulations to the developers! Whoohoo! Thanks. 8-) The intention is to give most people what they want most of the time, and stop short of giving everybody everything, which would make Albatross into an unintelligible soup. >In the mailing list I've noticed a couple of mentions of the next >release. Is the development code available to the world, perhaps via >anonymous CVS? If not, is there any documentation available on what we >can expect? We haven't had time to set up a public repository (and nobody has asked for it until now). The simplest answer might be to nightly tar up the CVS tree. One of the things that needs to be done before the next release is to go through the CVS change log and extract important details to form the release notes. Here's the raw change log (you may have to take some of the comments with a grain of salt, particularly the "option tag was never being closed" one - Dave reminded me that HTML permits this): 2003-02-14 15:08 andrewm * albatross/tags.py, doc/doctest/tags-input-select1, doc/doctest/tags-input-select2, test/templates/form.py: Missed another instance of this bug: The option tag was never being closed - remarkably the tests were also expecting this erroneous result. 2003-02-14 14:54 andrewm * doc/tags.tex: Added note to tag about enclosed content needing to be syntactically correct. 2003-02-14 14:43 andrewm * albatross/tags.py, doc/doctest/tags-input-select3, doc/doctest/tags-input-select4, test/templates/form.py: Bugfix - The option tag was never being closed - remarkably the tests were also expecting this erroneous result. 2003-01-28 16:17 andrewm * albatross/cgiapp.py: Use the dict get method to fetch REQUEST_URI and SERVER_NAME, which allows scripts to be run from the command line - suggested by Greg Bond. 2003-01-27 21:23 djc * albatross/apacheapp.py, albatross/app.py, albatross/cgiapp.py, albatross/randompage.py, doc/albatross.tex, test/sessions/request.py, test/sessions/ses_file.py, test/sessions/ses_server.py: Moved all header management into HeadersMixin which was renamed as ResponseMixin. Application send_content() method moved into ResponseMixin so end of headers can be detected automatically. Now raises exception if application attempts to set headers after they have been sent. Headers automatically sent when the application sends content. __sent_headers removed from cgiapp and apacheapp. 2003-01-24 23:45 andrewm * albatross/context.py: When encoding session, don't silently discard unpickleable elements (raise ApplicationError instead, including the name of the offending element). cPickle will raise all sorts of garbage exceptions - make sure we catch the common ones. 2003-01-24 23:35 andrewm * albatross/common.py: Forgot the most important bit - the exception definitions! 2003-01-24 22:34 andrewm * TODO, albatross/__init__.py, albatross/app.py, albatross/context.py, albatross/randompage.py, albatross/session.py, albatross/sessionfile.py, albatross/simpleserver.py, albatross/tags.py, albatross/template.py, test/namespace/request.py, test/templates/basic.py, test/templates/control_flow.py, test/templates/form.py, test/templates/include.py, test/templates/iterator.py, test/templates/lookup.py, test/templates/macro.py, test/templates/whitespace.py: Rationalised Albatross's use of exceptions, all exceptions are now subclasses of AlbatrossError, moved all exceptions to a "common" module. Also fixed a minor glitch in the tests where template execution output needed to be suppressed. 2003-01-24 22:24 andrewm * albatross/tags.py: Make single_select on the LazyTreeIterator an optional argument (defaults to "no"). 2003-01-24 14:48 andrewm * doc/appuser.tex: Added a little more information about setting up mod_python. 2002-12-28 16:47 djc * albatross/: app.py, randompage.py: Move call to ctx.flush_content() into Application.run() to allow session to be saved back at server before the HTML is sent to the browser. This allows applications to embed image tags for dynamically generated images. 2002-12-27 16:40 djc * albatross/tags.py: Added load_children() method to LazyTreeIterator so applications can stop abusing the node_is_open() method. 2002-12-27 12:34 djc * albatross/app.py: Create exception formatting context using different name so the we remove the original session when we call ctx.remove_session. Derrr. 2002-12-24 21:02 djc * albatross/app.py: Move escaping into formatted exception user. 2002-12-24 20:53 djc * albatross/app.py: Move exception formatting into separate method to allow subclasses to make use of formatting without needing to roll it themselves. 2002-12-23 16:48 djc * albatross/: app.py, context.py, randompage.py: Patches for problems reported by Greg Bond. Changed the way that _caller_globals() locates the desired stack frame it now searches by function name. run_template_once() now generates the same exception message as run_template(). 2002-12-23 12:07 djc * albatross/tags.py: Added NODE attribute to and tags which perform tree navigation. This allows tree navigation requests to be generated outside of the tag. Something like this:

2002-12-23 12:04 djc * albatross/context.py: Place the execution context into the execution context for the duration of expression evaluation under the name __ctx__. This allows you to do things like: 2002-12-18 17:06 andrewm * albatross/tags.py: * Added select_alias and open_alias to TreeIterators. * Move Lookup registration into object initialisation, lazy evaluation of item_dict (defered until first lookup_html) - to_html() method of Lookup becomes a NOOP. 2002-12-17 12:21 gregh * albatross/app.py: handle_exception now gets 'ctx' aswell as 'req' 2002-12-17 11:28 andrewm * albatross/context.py: Bugfix - If a user's session expires at the server side but not at the client, method="get" is being used, and the form contains a iterator, a traceback would result (attempt to call set_backdoor() on None). 2002-12-15 19:32 djc * albatross/tags.py: Implemented a single select option on LazyTreeIterator which is activated via the SINGLE attribute on the tag. 2002-12-11 19:36 andrewm * test/namespace/request.py: Added tests for file input handling (single field single file, multiple field, single field multiple file, __albform__, etc). 2002-12-11 16:08 andrewm * albatross/cgiapp.py, test/Makefile, test/namespace/__init__.py, test/namespace/request.py: Added first cut at request merging tests (tests for GET and POST exist cgi methods exist, although __albform__ functionality isn't being exercised yet). 2002-12-11 15:10 andrewm * albatross/: cgiapp.py, context.py, tags.py: Added support for . For inputs of this sort, the local context now gets a list of FileField instances. The FileField class contains attributes for filename (filename), open file object (file), and mime type (type). The NameRecorder Mixin tracks whether a type="file" input has been seen, and the to_html method of the Form class generates the appropriate enctype attribute if seen (otherwise file inputs simply pass back the filename). On type="file" inputs, "value" attributes are now ignored. Currently this is only supported on the cgiapp request class, and no documentation or tests have been written. 2002-12-11 12:23 djc * albatross/tags.py: Included explanation of why the content trap is needed for the tag. 2002-12-06 18:06 andrewm * albatross/context.py, doc/mixins.tex: - Raise an exception (SessionError) if add_session_vars is called when the named variable isn't in the local namespace (minor compatibility breakage). - New method on SessionBase, default_session_var, which adds a variable to the local namespace if it isn't already defined, and registers the variable in the session dictionary. - Update doco for the above changes. 2002-12-06 18:01 andrewm * doc/doctest/tags-input-text: Doco example fix for this bugfix: - was not generating a value attribute when the value evaluated to 0 (zero) - fixed and added test. Bug discovered by Michael Neel (thanks). 2002-12-05 15:11 andrewm * albatross/app.py: New improved version of req_equals (one less hash lookup!) 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). 2002-12-05 11:26 djc * albatross/randompage.py, test/templates/basic.py, test/templates/include.py: Ran tabnanny and noticed some problems. 2002-12-05 11:17 djc * TODO: Added some suggestions from Michael C. Neel. 2002-11-29 21:12 djc * albatross/: apacheapp.py, app.py, cgiapp.py: Apply proposed changes for altering the status returned to the browser. 2002-11-29 14:58 andrewm * TODO: Added a couple of items from the albatross-users list to the TODO list. 2002-11-28 16:35 andrewm * albatross/context.py: NamespaceMixin.set_value() now has a funky exception handler. This method is responsible for parsing form elements (a somewhat critical task) and it was possible to cause it to throw an exception that was completely lacking in any useful information. The exception handler now identifies the field by name, attempts to identify where in the field name the exception occured, and includes the current "index" where an IndexError is raised, and re-raises the original exception (in case it really is a bug in set_value()). 2002-11-28 15:40 djc * albatross/app.py, albatross/session.py, albatross/sessionfile.py, doc/albatross.tex, test/sessions/ses_file.py, test/sessions/ses_server.py: Change the way that response headers are managed to allow applications to do things like: ctx.set_header('Content-Type', 'image/gif') if ctx.get_header('Pragma') == 'no-cache': ctx.del_header('Pragma') The defaults are established in HeadersMixin.__init__() so the application is free to alter them at any point during processing. 2002-11-21 13:49 andrewm * albatross/sessionfile.py: - SessionFileContextMixin._get_sesid_from_cookie was not coping with cookies other than the one we wanted being in the Cookie header sent by the browser (it was catching the wrong exception). Found by Greg Bond. 2002-11-19 10:18 andrewm * albatross/tags.py, test/templates/form.py: - was not generating a value attribute when the value evaluated to 0 (zero) - fixed and added test. Bug discovered by Michael Neel (thanks). 2002-11-10 12:24 djc * albatross/randompage.py: Fixed import error problem reported by Brian Brown. 2002-10-28 22:51 djc * dist/release-checklist: Documented in the OcWiki. 2002-10-28 12:41 djc * dist/dist-albatross.sh: Fix up script which moves files to web server. 2002-10-28 12:16 djc * albatross/__init__.py: Fixed up release numbers. 2002-10-28 12:15 djc * setup.py, dist/dist-albatross.sh: Fix release numbers. 2002-10-28 11:55 djc * ChangeLog, dist/release-1.01, doc/albatross.tex, doc/installation.tex, doc/mixins.tex, doc/tags.tex: Release 1.01. 2002-10-28 10:43 djc * dist/: dist-albatross.sh, index.ahtml, make_webpage.py: Release process does not alter web page any more. 2002-10-28 10:40 djc * dist/release-1.01: All changes for 1.0.1 -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Thu Feb 20 13:55:11 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 20 Feb 2003 13:55:11 +1100 Subject: [albatross-users] Axe - Albatross Extensions In-Reply-To: Message from "Michael C. Neel" of "Mon, 17 Feb 2003 16:15:39 CDT." References: Message-ID: <20030220025511.DF7C03CC5E@coffee.object-craft.com.au> > At some point it may make sense to merge these tags into >Albatross itself, however I feel at this time it does not. Big reason >is the object craft guys don't need more work as they are working on >Albatross itself, and the second reason is I'm not convinced these >highly tailored tag. should be part of the set of standard tags. Of >course if the community sees it differently, I'm not going to stand in >the way . We probably should put a link on the albatross page - maybe we need a new "Contrib" section? -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From djc at object-craft.com.au Thu Feb 20 14:52:00 2003 From: djc at object-craft.com.au (Dave Cole) Date: 20 Feb 2003 14:52:00 +1100 Subject: [albatross-users] ctx.request.write_header, AppContext, and Content-Types Oh my! In-Reply-To: References: Message-ID: > BTW, when can we expect the next version? We've deployed 3 sites in > Albatross so far, I have a hobby site in Albatross, and we have another > 2 projects nearing release in Albtross, so it's an understament to say > I'm excited about the next release. The only obstacle is getting the documentation up to date again. The probably is not too much to do (famous last words). - Dave -- http://www.object-craft.com.au From neel at mediapulse.com Fri Feb 21 01:50:44 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Thu, 20 Feb 2003 09:50:44 -0500 Subject: [albatross-users] ctx.request.write_header, AppContext, and Content-Types Oh my! Message-ID: Don't you long for the days in college when the prof. told you that documentation would be handeled by another dept? Mike -----Original Message----- From: Dave Cole [mailto:djc at object-craft.com.au] Sent: Wednesday, February 19, 2003 10:52 PM To: Michael C. Neel Cc: Andrew McNamara; albatross-users at object-craft.com.au Subject: Re: [albatross-users] ctx.request.write_header, AppContext, and Content-Types Oh my! > BTW, when can we expect the next version? We've deployed 3 sites in > Albatross so far, I have a hobby site in Albatross, and we have > another 2 projects nearing release in Albtross, so it's an > understament to say I'm excited about the next release. The only obstacle is getting the documentation up to date again. The probably is not too much to do (famous last words). - Dave -- http://www.object-craft.com.au From matt at pollenation.net Fri Feb 21 12:43:29 2003 From: matt at pollenation.net (Matt Goodall) Date: 21 Feb 2003 01:43:29 +0000 Subject: [albatross-users] Random pages and application model Message-ID: <1045791809.15828.62.camel@localhost> Hi, There's a nice description of how the application model relates to the page_xxx() methods for 'stateful' applications in the mailing list archive but I've not come across an equivalent explanation for 'random' applications. >From debug traces I see the following sequence whenever the page is requested: page_enter(ctx) page_process(ctx) page_display(ctx) I have no problems with page_process() and page_display() but I don't quite understand what use page_enter() has? It seems a bit redundant to me since the request parameters are not merged into ctx.locals until **after** page_enter() is called. It's probably worth explaining that what I expected to be able to do is something like this (not tested): page1.py -------- def page_process(ctx): if ctx.req_equals('edit'): ctx.redirect('page2?objid=%s' % ctx.locals.objid) page2.py -------- def page_enter(ctx): ctx.locals.obj = get_obj_from_somewhere(ctx.locals.objid) def page_process(ctx): if ctx.req_equals('submit'): # save data ctx.redirect('page1') elif ctx.req_equals('cancel'): ctx.redirect('page1') def page_display(ctx): ctx.locals.attr1 = ctx.locals.obj.attr1 ctx.locals.attr2 = ctx.locals.obj.attr2 ctx.run_template('page2.html') The problem is that, as mentioned above, the request parameter, objid, is not available during page_enter(), it's only there for page_process(). One workaround is to put the object loading code in an else block in page_process which doesn't feel like the right place for it. The alternative is to transfer objid using a session var but I prefer not to use the session where possible - it's just something else that needs managing. Oh yeah, my app class extends RandomModularSessionApp and I'm running the application in mod_python on Linux if that makes any difference. Thanks for any help. Cheers, Matt -- Matt Goodall, Technical Director Pollenation Internet Ltd, http://www.pollenation.net e: matt at pollenation.net t: 0113 2252500 From gnb at itga.com.au Fri Feb 21 13:08:52 2003 From: gnb at itga.com.au (Gregory Bond) Date: Fri, 21 Feb 2003 13:08:52 +1100 Subject: [albatross-users] Random pages and application model In-Reply-To: Your message of 21 Feb 2003 01:43:29 -0000. Message-ID: <200302210208.NAA23715@lightning.itga.com.au> matt at pollenation.net said: > >From debug traces I see the following sequence whenever the page is > requested: > page_enter(ctx) > page_process(ctx) > page_display(ctx) It's a bit more subtle than that. Each albatross app has a concept of the "current page" (which is available in ctx.locals.__page__). When a session is initiated, the current page is set to the start page specified in the application object. When the current page is moved (either by a redirect or a set_page()), then page_leave() is called for the old page, and then page_enter() is called for the new page. Page_display() is called to display a page (der!) and may not necessarily be called in conjunction with anything else (e.g. if the user hits "refresh"). When the user submits a form, then page_proces() is called. If page_process() calls set_page(), then page_leave() and page_enter() will be called. But it is perfectly valid for page_process() not to change the current page, in which case page_leave() and page_enter() will not be called. One subtlety is that the page_enter() may be called from within the page_process() routine. I.e. the call graph might look like: application.run() application.process_request() old.page_process() ctx.set_page('new') old.page_leave() new.page_enter() application.display_response() new.page_display() IIUC, the Random mixins work the same way as the non-Random versions as far as all this is concerned. I hope that makes it clearer! From matt at pollenation.net Fri Feb 21 13:50:26 2003 From: matt at pollenation.net (Matt Goodall) Date: 21 Feb 2003 02:50:26 +0000 Subject: [albatross-users] Random pages and application model In-Reply-To: <200302210208.NAA23715@lightning.itga.com.au> References: <200302210208.NAA23715@lightning.itga.com.au> Message-ID: <1045795825.15828.129.camel@localhost> Gregory, thanks for the quick response. I may be wrong but I'm fairly sure random pages **are** processed differently. The docs certainly imply this. The interface of pages handled by RandomPageModuleMixin has no page_leave() method and the example (4.8 Random Access Applications) uses ctx.redirect() rather than ctx.set_page() to transfer to another page. In fact, if I use set_page() in a random app I get an exception. The lifecycle of a 'normal' page is really nice - great for clearing up session data - but I'm guessing that's hard to achieve for random pages. It's worth noting that an tag on random pages is rendered as so Albatross is making no attempt to "get in the way" of the request. Cheers, Matt On Fri, 2003-02-21 at 02:08, Gregory Bond wrote: > matt at pollenation.net said: > > >From debug traces I see the following sequence whenever the page is > > requested: > > page_enter(ctx) > > page_process(ctx) > > page_display(ctx) > > It's a bit more subtle than that. > > Each albatross app has a concept of the "current page" (which is available in > ctx.locals.__page__). When a session is initiated, the current page is set to > the start page specified in the application object. > > When the current page is moved (either by a redirect or a set_page()), then > page_leave() is called for the old page, and then page_enter() is called for > the new page. > > Page_display() is called to display a page (der!) and may not necessarily be > called in conjunction with anything else (e.g. if the user hits "refresh"). > > When the user submits a form, then page_proces() is called. If page_process() > calls set_page(), then page_leave() and page_enter() will be called. But it > is perfectly valid for page_process() not to change the current page, in which > case page_leave() and page_enter() will not be called. > > One subtlety is that the page_enter() may be called from within the > page_process() routine. I.e. the call graph might look like: > > application.run() > application.process_request() > old.page_process() > ctx.set_page('new') > old.page_leave() > new.page_enter() > application.display_response() > new.page_display() > > IIUC, the Random mixins work the same way as the non-Random versions as far as > all this is concerned. I hope that makes it clearer! > > > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- Matt Goodall, Technical Director Pollenation Internet Ltd, http://www.pollenation.net e: matt at pollenation.net t: 0113 2252500 From djc at object-craft.com.au Fri Feb 21 15:08:59 2003 From: djc at object-craft.com.au (Dave Cole) Date: 21 Feb 2003 15:08:59 +1100 Subject: [albatross-users] Random pages and application model In-Reply-To: <1045795825.15828.129.camel@localhost> References: <200302210208.NAA23715@lightning.itga.com.au> <1045795825.15828.129.camel@localhost> Message-ID: >>>>> "Matt" == Matt Goodall writes: Matt> Gregory, thanks for the quick response. I may be wrong but I'm Matt> fairly sure random pages **are** processed differently. The docs Matt> certainly imply this. The interface of pages handled by Matt> RandomPageModuleMixin has no page_leave() method and the example Matt> (4.8 Random Access Applications) uses ctx.redirect() rather than Matt> ctx.set_page() to transfer to another page. In fact, if I use Matt> set_page() in a random app I get an exception. The RandomPage stuff is there to allow you to build bookmarkable applications. This means that the application is not really in control of the sequence of pages requested by the browser. You are right, as a consequence of the random nature the application does not have the concept of "current page" when a new request comes in. If there is no current page then you cannot leave it. Every request enters the page requested in the URL. Matt> The lifecycle of a 'normal' page is really nice - great for Matt> clearing up session data - but I'm guessing that's hard to Matt> achieve for random pages. It's worth noting that an href="page2"> tag on random pages is rendered as href="/path/to/app.py/page2"> so Albatross is making no attempt Matt> to "get in the way" of the request. I am not sure I like the way Albatross does this. It is really useful for some things, but a pain for others. The code is pretty hard to follow too. - Dave -- http://www.object-craft.com.au From djc at object-craft.com.au Fri Feb 21 15:39:01 2003 From: djc at object-craft.com.au (Dave Cole) Date: 21 Feb 2003 15:39:01 +1100 Subject: [albatross-users] Random pages and application model In-Reply-To: <1045791809.15828.62.camel@localhost> References: <1045791809.15828.62.camel@localhost> Message-ID: > There's a nice description of how the application model relates to > the page_xxx() methods for 'stateful' applications in the mailing > list archive but I've not come across an equivalent explanation for > 'random' applications. > > >From debug traces I see the following sequence whenever the page is > requested: > > page_enter(ctx) > page_process(ctx) > page_display(ctx) > > I have no problems with page_process() and page_display() but I > don't quite understand what use page_enter() has? It seems a bit > redundant to me since the request parameters are not merged into > ctx.locals until **after** page_enter() is called. > > It's probably worth explaining that what I expected to be able to do > is something like this (not tested): > > page1.py > -------- > > def page_process(ctx): > if ctx.req_equals('edit'): > ctx.redirect('page2?objid=%s' % ctx.locals.objid) Doesn't that work? > page2.py > -------- > > def page_enter(ctx): > ctx.locals.obj = get_obj_from_somewhere(ctx.locals.objid) Ahhh... In a random application the page_enter() function gets called every request. You could just take the page_enter() code and prepend it to the page_process() function. > def page_process(ctx): > if ctx.req_equals('submit'): > # save data > ctx.redirect('page1') > elif ctx.req_equals('cancel'): > ctx.redirect('page1') > > def page_display(ctx): > ctx.locals.attr1 = ctx.locals.obj.attr1 > ctx.locals.attr2 = ctx.locals.obj.attr2 > ctx.run_template('page2.html') > > > The problem is that, as mentioned above, the request parameter, > objid, is not available during page_enter(), it's only there for > page_process(). That is a bit of a bugger. One thing you could do is subclass the application and replace the run() method with a slightly re-ordered sequence. class MyApp(RandomModularSessionApp): def run(self, req): # My own processing sequence copied from # RandomModularApp.run() but slightly resequenced. > One workaround is to put the object loading code in an else block in > page_process which doesn't feel like the right place for it. The > alternative is to transfer objid using a session var but I prefer > not to use the session where possible - it's just something else > that needs managing. See if overriding the application run method gives you what you need. The primary design goal of Albatross was to provide a toolkit from which you can build your own application models. We provide some examples pre-rolled which just happen to be useful for certain classes of application. I am more than a little interested to see if replacing Application.run() is useful to you. Does it make your brain hurt, or is it something useful? - Dave -- http://www.object-craft.com.au From neel at mediapulse.com Sat Feb 22 01:56:16 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Fri, 21 Feb 2003 09:56:16 -0500 Subject: [albatross-users] Random pages and application model Message-ID: >Page_display() is called to display a page (der!) and may not necessarily be >called in conjunction with anything else (e.g. if the user hits "refresh"). >When the user submits a form, then page_proces() is called. If page_process() >calls set_page(), then page_leave() and page_enter() will be called. But it >is perfectly valid for page_process() not to change the current page, in which >case page_leave() and page_enter() will not be called. Is this correct? In my time with Albatross, it seemed that page_process and page_display were called for every request, submission or no. I've never needed beyond the SimpleApp, so that might have something to do with it. I haven't yet figured out what the other page methods offer that is not doable in SimpleApp (not the session mixins, just the page mixins). Mike From matt at pollenation.net Sat Feb 22 11:34:08 2003 From: matt at pollenation.net (Matt Goodall) Date: 22 Feb 2003 00:34:08 +0000 Subject: [albatross-users] Random pages and application model In-Reply-To: References: Message-ID: <1045874047.20353.57.camel@localhost> Oops, my post was supposed to go to the list. Hope you don't mind me forwarding your reply Mike. Cheers, Matt On Fri, 2003-02-21 at 22:39, Michael C. Neel wrote: > Hmmm... I guess I misuse the non-random module then ;) I usally set a > page member variable on the page object, and set that from the request, > so that pages are able to be bookmarked, unless I do an interal switch, > for a thank-you page or something that I don't want to be bookmarked. I > then "switch" off of this variable in process(). > > One of my hobby sites, www.fistsofniall.com is this way. In fact, you > can't even tell that it's using *any* form of server side application > from the urls (all though that site doesn't have much in the way of > form, just a lot of dynamic content from a database). > > Mike > > -----Original Message----- > From: Matt Goodall [mailto:matt at pollenation.net] > Sent: Friday, February 21, 2003 5:19 PM > To: Michael C. Neel > Subject: RE: [albatross-users] Random pages and application model > > > On Fri, 2003-02-21 at 14:56, Michael C. Neel wrote: > > >Page_display() is called to display a page (der!) and may not > > necessarily be > > >called in conjunction with anything else (e.g. if the user hits > > "refresh"). > > > > >When the user submits a form, then page_proces() is called. If > > page_process() > > >calls set_page(), then page_leave() and page_enter() will be called. > > But it > > >is perfectly valid for page_process() not to change the current page, > > in which > > >case page_leave() and page_enter() will not be called. > > > > Is this correct? In my time with Albatross, it seemed that > > page_process and page_display were called for every request, > submission or no. > > The description above seems correct from what I've seen. For non-random > pages, page_process() is only called to process an action (form > submission, link click etc) for the page. > > > I've > > never needed beyond the SimpleApp, so that might have something to do > > with it. I haven't yet figured out what the other page methods offer > > that is not doable in SimpleApp (not the session mixins, just the page > > > mixins). > > They all let you do the same thing but in a different way. > > The only real difference I've seen between the PageObjectMixin and the > PageModuleMixin is how your application is structured. You're probably > best reading section 4.6 of the manual for more. > > The difference between random and non-random mixins is a bit more > interesting ... > > The non-random page mixins are great for truly stateful applications, > i.e. something like an administration system or a webmail application. I > think "application" is probably the key word here. The request URL for > these apps always stays the same no matter which page is displayed. > > The random page mixin is useful for your more traditional, > content-oriented website. The key difference is that the random mixin > uses the request URL to determine the page to display and, more > importantly, changes the request URL to move to a different page. That > gives the user something useful to bookmark which is pretty important in > many situations. > > Hope that helps. > > Cheers, Matt > > > Mike > > _______________________________________________ > > Albatross-users mailing list Albatross-users at object-craft.com.au > > > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- Matt Goodall, Technical Director Pollenation Internet Ltd, http://www.pollenation.net e: matt at pollenation.net t: 0113 2252500 From matt at pollenation.net Sat Feb 22 12:37:28 2003 From: matt at pollenation.net (Matt Goodall) Date: 22 Feb 2003 01:37:28 +0000 Subject: [albatross-users] Random pages and application model In-Reply-To: References: <1045791809.15828.62.camel@localhost> Message-ID: <1045877847.20357.114.camel@localhost> On Fri, 2003-02-21 at 04:39, Dave Cole wrote: > > There's a nice description of how the application model relates to > > the page_xxx() methods for 'stateful' applications in the mailing > > list archive but I've not come across an equivalent explanation for > > 'random' applications. > > > > >From debug traces I see the following sequence whenever the page is > > requested: > > > > page_enter(ctx) > > page_process(ctx) > > page_display(ctx) > > > > I have no problems with page_process() and page_display() but I > > don't quite understand what use page_enter() has? It seems a bit > > redundant to me since the request parameters are not merged into > > ctx.locals until **after** page_enter() is called. > > > > It's probably worth explaining that what I expected to be able to do > > is something like this (not tested): > > > > page1.py > > -------- > > > > def page_process(ctx): > > if ctx.req_equals('edit'): > > ctx.redirect('page2?objid=%s' % ctx.locals.objid) > > Doesn't that work? > > > page2.py > > -------- > > > > def page_enter(ctx): > > ctx.locals.obj = get_obj_from_somewhere(ctx.locals.objid) > > Ahhh... > > In a random application the page_enter() function gets called every > request. You could just take the page_enter() code and prepend it to > the page_process() function. > > > def page_process(ctx): > > if ctx.req_equals('submit'): > > # save data > > ctx.redirect('page1') > > elif ctx.req_equals('cancel'): > > ctx.redirect('page1') > > > > def page_display(ctx): > > ctx.locals.attr1 = ctx.locals.obj.attr1 > > ctx.locals.attr2 = ctx.locals.obj.attr2 > > ctx.run_template('page2.html') > > > > > > The problem is that, as mentioned above, the request parameter, > > objid, is not available during page_enter(), it's only there for > > page_process(). > > That is a bit of a bugger. One thing you could do is subclass the > application and replace the run() method with a slightly re-ordered > sequence. True, should be easy enough. > > class MyApp(RandomModularSessionApp): > def run(self, req): > # My own processing sequence copied from > # RandomModularApp.run() but slightly resequenced. > > > One workaround is to put the object loading code in an else block in > > page_process which doesn't feel like the right place for it. The > > alternative is to transfer objid using a session var but I prefer > > not to use the session where possible - it's just something else > > that needs managing. > > See if overriding the application run method gives you what you need. > > The primary design goal of Albatross was to provide a toolkit from > which you can build your own application models. We provide some > examples pre-rolled which just happen to be useful for certain classes > of application. Fair point, I should make sure I understand all the mixins properly and see if a DIY application class might suit me better. > > I am more than a little interested to see if replacing > Application.run() is useful to you. Does it make your brain hurt, or > is it something useful? It works fine and it was easy. All I did was move self.merge_request(ctx) to above self.load_page(ctx). However, after thinking more about where the loading code should go made me realise that I don't want to put it in page_enter() anyway. That's called every time the page is requested, even when a form on the page is submitted, so I was being stupid ;-). Is there actually a good reason why request parameters are not merged into ctx.locals before page_enter() is called? It seems strange that the session attributes are there but not the request. > > - Dave -- Matt Goodall, Technical Director Pollenation Internet Ltd, http://www.pollenation.net e: matt at pollenation.net t: 0113 2252500