From andrewm at object-craft.com.au Mon Mar 4 14:24:24 2002 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 04 Mar 2002 14:24:24 +1100 Subject: [albatross-users] Welcome to Albatross-users Message-ID: <20020304032424.32C3438F35@coffee.object-craft.com.au> Since the list has been rather quiet, I thought I would just say "welcome" to the 3 non-Object Craft subscribers on the list! I have some questions for you: - Are you using Albatross or just considering it? - Do you have any suggestions regarding the module or it's documentation? - Do you have any questions? We expect to do a 0.06 release shortly, as well as announcing the mailing list more widely - this release contains: - many documentation improvements, - a samples installer, - MD5 signing of hidden field data (which required a new "secret" parameter to app objects utilising the HiddenField mixin), - tag parsing now accepts either single or double quotes in attributes, as well as allowing the quotes to be escaped with backslash. - a new file based session recorder to supplement the hidden field and session server recorders, - a wrapper around the session server to allow it to be easily used as a daemon on unix platforms, - more unit tests, unit tests now use the current albatross instance, rather than the installed instance. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From tchur at optushome.com.au Mon Mar 4 18:15:22 2002 From: tchur at optushome.com.au (Tim Churches) Date: Mon, 04 Mar 2002 18:15:22 +1100 Subject: [albatross-users] Welcome to Albatross-users References: <20020304032424.32C3438F35@coffee.object-craft.com.au> Message-ID: <3C831F0A.31E07BBC@optushome.com.au> Andrew McNamara wrote: > > Since the list has been rather quiet, I thought I would just say "welcome" > to the 3 non-Object Craft subscribers on the list! > > I have some questions for you: > > - Are you using Albatross or just considering it? Andrew, Ben and Dave already know about our use of Albatross, since we have contracted them to assist us withing with the development of our application, but I'll describe it briefly for the other two subscribers and for the list archives. We are building, or rather have built a prototype epidemiological mortality analysis system. It allows the user to specify a range of quite complex parameters, such as the cause of death (picked from an Albatross tree display of International Classification of Diseases codes in three groups [ICD-8, ICD-9 and ICD-10] - the ICD trees each have between 6,000 and 9,000 nodes in them, but Albatross manages their display and unfolding perfectly, using very little code - very impressive), age of death, residence, year of death etc, and then lets the user specify what they want in terms of particular graphs, tables and other statistical analyses. The number crunching is handled partly by a data analysis engine we have written in Python (with help from Dave Cole of Object Craft - we hope to release this engine separately in the next few months) and is partly handled by the R open source statistical package (see http://www.r-project.org). Thus, a set of inter-related analysis parameters are built up and modified (in any order) by the user through a number of different screens, and Albatross transparently handles the maintenance of this 'state' i.e. the set of parameters being specified. There are facilities to store and recall sets of parameters too. Finally the user clicks "Submit" and their analysis is performed and teh results displayed, as graphs and tables. The whole thing works a treat and I am now happily extending the user Albatross-mediated interface without reference to Object Craft (except for the occasional request for help). > - Do you have any suggestions regarding the module or it's documentation? Looks like you have already implemented most of them for the 0.6 release. One thing which almost every application requires is logging. Would it be possible to add some hooks into Albatross so that a logging class is called automatically at given points in teh processing? Would it be possible to incorporate the nifty cgitb (CGI traceback) module which is now standard in python 2.2 into Albatross 9it is available for early versions of Python - see http://www.python.org/doc/current/lib/module-cgitb.html)? Related to the last two requests, a built-in means of logging exceptions and/or emailing their occurence and/or details to nominated addresses would be useful. > - Do you have any questions? > > We expect to do a 0.06 release shortly, as well as announcing the mailing > list more widely - this release contains: > > - many documentation improvements, > - a samples installer, > - MD5 signing of hidden field data (which required a new "secret" > parameter to app objects utilising the HiddenField mixin), > - tag parsing now accepts either single or double quotes in attributes, > as well as allowing the quotes to be escaped with backslash. > - a new file based session recorder to supplement the hidden field > and session server recorders, > - a wrapper around the session server to allow it to be easily used > as a daemon on unix platforms, > - more unit tests, unit tests now use the current albatross instance, > rather than the installed instance. Sounds good. Will the file-based session server support "migration" of user sessions from one server to another eg if there is a "farm" of Web app servers each accessing a shared file-based session server, then a round-robin DNS can be used to route each HTTP request to the next server and that server will load the correct application state. Possible? Cheers, Tim C From djc at object-craft.com.au Mon Mar 4 18:46:16 2002 From: djc at object-craft.com.au (Dave Cole) Date: 04 Mar 2002 18:46:16 +1100 Subject: [albatross-users] Welcome to Albatross-users In-Reply-To: <3C831F0A.31E07BBC@optushome.com.au> References: <20020304032424.32C3438F35@coffee.object-craft.com.au> <3C831F0A.31E07BBC@optushome.com.au> Message-ID: >>>>> "Tim" == Tim Churches writes: Tim> One thing which almost every application requires is Tim> logging. Would it be possible to add some hooks into Albatross so Tim> that a logging class is called automatically at given points in Tim> teh processing? I will let Ben reply to this - he has been doing some stuff in that area. Tim> Would it be possible to incorporate the nifty cgitb (CGI Tim> traceback) module which is now standard in python 2.2 into Tim> Albatross 9it is available for early versions of Python - see Tim> http://www.python.org/doc/current/lib/module-cgitb.html)? That looks like a good thing. Without actually trying it out ('cos I'm a lazy bugger), something like this should do something close to what you want: import cgitb from albatross import SimpleApp class MyApp(SimpleApp): def handle_exception(self, req): cgitb.handler() Tim> Sounds good. Will the file-based session server support Tim> "migration" of user sessions from one server to another eg if Tim> there is a "farm" of Web app servers each accessing a shared Tim> file-based session server, then a round-robin DNS can be used to Tim> route each HTTP request to the next server and that server will Tim> load the correct application state. Possible? One of the advantages of using a session server is that it allows sessions to work transparently across multiple front end web serving machines. - Dave -- http://www.object-craft.com.au From bgg at object-craft.com.au Mon Mar 4 19:09:00 2002 From: bgg at object-craft.com.au (Ben Golding) Date: Mon, 4 Mar 2002 19:09:00 +1100 Subject: [albatross-users] Logging from Albatross applications In-Reply-To: Message-ID: <15DD470C-2F47-11D6-8EA9-003065907038@object-craft.com.au> On Monday, March 4, 2002, at 06:46 , Dave Cole wrote: >>>>>> "Tim" == Tim Churches writes: > > Tim> One thing which almost every application requires is > Tim> logging. Would it be possible to add some hooks into Albatross so > Tim> that a logging class is called automatically at given points in > Tim> teh processing? > > I will let Ben reply to this - he has been doing some stuff in that > area. I found myself getting frustrated with wanting to log and not having a simple way of doing that. What I ended up doing was writing a little LogMixin that looks like: class LogMixin: def log(self, s): sys.stderr.write('%s\n' % s) sys.stderr.flush() In my AppContext, I declared it as: class AppContext(SimpleAppContext, logMixin.LogMixin): ... self.log('AppContext.get_mailbox: self.locals %s' % dir(self.locals)) which I thought was great. Apache logs stderr to ite error_log on unix but by just changing that single mixin, you could make errors go elsewhere (say, syslog instead) or handle them completely different (eg, if you were using Windows). I was also able to add the mixin to my own classes and log from them using self.log() as well. That meant that all logging went to the same place and had the same format. There's also the possibility of subclassing the mixin to change the output to (say) including a timestamp, pid, or something. I've suggested to Dave that he add a LogMixin class to Albatross because other, lesser people do have to do debugging from time to time. Providing a standard mechanism for that could be a real advantage. If he adds it, the names and functionality might change but this should get you going. Ben. From andrewm at object-craft.com.au Mon Mar 4 21:14:33 2002 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 04 Mar 2002 21:14:33 +1100 Subject: [albatross-users] Welcome to Albatross-users In-Reply-To: Your message of "Mon, 04 Mar 2002 18:15:22 +1100." <3C831F0A.31E07BBC@optushome.com.au> Message-ID: <20020304101433.CC45F38F35@coffee.object-craft.com.au> >> - a new file based session recorder to supplement the hidden field >> and session server recorders, > >Sounds good. Will the file-based session server support "migration" of >user sessions from one server to another eg if there is a "farm" of Web >app servers each accessing a shared file-based session server, then a >round-robin DNS can be used to route each HTTP request to the next >server and that server will load the correct application state. No, it's really a simpler alternative to running a session server. The cgi itself is responsible for writing the pickled sessions to the filesystem. The implementation was kept deliberately simple and portable - it should work under windows (although this hasn't been tested). This does mean that there is no provision for sharing the sessions between servers (the file access is *not* NFS safe, because the techniques used would upset windows, and there are better alternatives anyway). As Dave said, you can run a single session server, and have multiple front ends hit this server (since the server protocol is TCP). Currently the session server is not persistent - if you restart it, you lose all the currently open sessions. Future work will add some sort of presistent store (maybe libdb). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From djc at object-craft.com.au Fri Mar 15 22:41:33 2002 From: djc at object-craft.com.au (Dave Cole) Date: 15 Mar 2002 22:41:33 +1100 Subject: [albatross-users] Albatross 0.06 released Message-ID: Albatross is a small toolkit for developing highly stateful web applications. The toolkit has been designed to take a lot of the pain out of constructing intranet applications although you can also use Albatross for deploying publicly accessed web applications. In slightly more than 3000 lines of Python you get the following: - An extensible HTML templating system similar to DTML including tags for: - Conditional processing. - Macro definition and expansion. - Sequence iteration and pagination. - Tree browsing. - Lookup tables to translate Python values to arbitrary template text. - Application classes which offer the following features: - Optional server side or browser side sessions. - The ability to place Python code for each page in a dynamically loaded module, or to place all page processing code in a single mainline. - The ability to deploy applications either as CGI or via mod_python by changing less than 10 lines of code. The toolkit application functionality is defined by a collection of fine grained mixin classes. Eight different application types and four different execution contexts are prepackaged, you are able to define your own drop in replacements for any of the mixins to alter any aspect of the toolkit semantics. Application deployment is controlled by your choice of either cgi or mod_python Request class. It should be possible to develop a Request class for FastCGI or Medusa to allow applications to be deployed on those platforms with minimal changes. Albatross comes with over 130 pages of documentation. HTML, PDF and PostScript formatted documentation is available from the toolkit homepage. The toolkit homepage: http://www.object-craft.com.au/projects/albatross/ Important changes since last release: * The template parser has been enhanced to handle attribute values enclosed with either single or double quotes. The enclosing quote character can be used in the attribute string if it is escaped by a backslash ('\'). Attribute values can be broken over multiple lines. * All pickles sent to browser are now MD5 signed to detect and prevent modification. New pickle security techniques can be defined by defining a replacement for the PickleSignMixin class. * The new RandomPageModuleMixin class now allows you to build applications which use the request URL to determine which page module will be used to process the browser request. * A set of classes for implementing file based server side sessions has been added. * The simple session server can now be run as a daemon under Unix. * Program mainline for mod_python deployment has been simplified. You now hook into mod_python like this: def handler(req): return app.run(Request(req)) instead of this: from mod_python import apache : def handler(req): app.run(Request(req)) return apache.OK * New redirect() execution context method for doing browser redirection. * Session saving can be disabled via the new set_save_session() method. * The samples have been completely reorganised and documentation updated to make them less confusing. An installation program has been provided to reduce the pain of running the samples. * Many documentation improvements. - Dave -- http://www.object-craft.com.au From djc at object-craft.com.au Sat Mar 16 10:07:11 2002 From: djc at object-craft.com.au (Dave Cole) Date: 16 Mar 2002 10:07:11 +1100 Subject: [albatross-users] Re: session server In-Reply-To: <200203151538.g2FFc1009198@lewis.abi.tconline.net> References: <200203151538.g2FFc1009198@lewis.abi.tconline.net> Message-ID: >>>>> "Lewis" == Lewis Bergman writes: Lewis> I noticed that the installer did not install the session Lewis> server. Is the supplied example considered not usable without Lewis> modification or extension? I was thinking of making a RH Lewis> startup script for it and was going to point it to the Lewis> site-packages dir and then noticed it isn't there. We haven't really though about automatically installing the session server. The supplied example is usable - the only problem is that when the program exits all sessions are lost. - Dave -- http://www.object-craft.com.au From djc at object-craft.com.au Sat Mar 16 10:20:23 2002 From: djc at object-craft.com.au (Dave Cole) Date: 16 Mar 2002 10:20:23 +1100 Subject: [albatross-users] Re: css In-Reply-To: <200203151856.g2FIu2d09361@lewis.abi.tconline.net> References: <200203151856.g2FIu2d09361@lewis.abi.tconline.net> Message-ID: >>>>> "Lewis" == Lewis Bergman writes: Lewis> I hate to bother whoever gets this but I was wondering about Lewis> css. As I am making my way through the different al-input tags Lewis> I see no way of enabling some kind of css identifier like Lewis> class= or id=. I was hoping to be able to at least use class so Lewis> that I might differentiate different input fields pased on type Lewis> or status. Lewis> For instance, I like to use a light blue background for any Lewis> text entry that is a db search input. Using css and something Lewis> like class=srch makes this easy. I also like to use a Lewis> background of light yellow for any field that failed some Lewis> verification text after changing the class type to class=err. Lewis> This might be out of the scope of albatross but I thought I Lewis> would ask first. Maybe there is some other way to do this that Lewis> I haven't thought of yet. Thanks again for the great package. Oops... The documentation doesn't seem to mention this but any tag attributes not recognised by Albatross are passed through to the output unmodified. The following passes a class attribute through - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> import albatross >>> ctx = albatross.SimpleContext('.') >>> ctx.locals.names = ['John', 'Terry', 'Eric'] >>> albatross.Template(ctx, '', ''' ... ... ... ... ''').to_html(ctx) >>> ctx.flush_content() - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This does not directly solve your problem of needing to alter the value of the class attribute, but you can always use to select between normal and error variants of the tag. - Dave -- http://www.object-craft.com.au From djc at object-craft.com.au Sat Mar 16 10:25:27 2002 From: djc at object-craft.com.au (Dave Cole) Date: 16 Mar 2002 10:25:27 +1100 Subject: [albatross-users] Re: al-flush comment In-Reply-To: <200203152148.g2FLm5909877@lewis.abi.tconline.net> References: <200203152148.g2FLm5909877@lewis.abi.tconline.net> Message-ID: >>>>> "Lewis" == Lewis Bergman writes: Lewis> After going through the tutorials and into the tag Lewis> documentation I get the feeling that the flush tags is supposed Lewis> to update the browser incrementally. ie: in the tutorial Lewis> example it is inside a al-for loop I think. Lewis> What actually happens (at least on my 1.5.2) is that the first Lewis> line appears, then nothing, then all the iterations appear Lewis> (1-10 I think) and the line "finished" or some such. Lewis> Is this expected or should it output once a second with the Lewis> next iteration? Maybe I am missing something. This seems to be very browser specific unfortunately. If you use Mozilla the example works as advertised. It would be nice if there was a way to make the example work with all browsers... As a matter of interest, what browser are you using? - Dave -- http://www.object-craft.com.au From djc at object-craft.com.au Sun Mar 17 10:48:54 2002 From: djc at object-craft.com.au (Dave Cole) Date: 17 Mar 2002 10:48:54 +1100 Subject: [albatross-users] Re: css In-Reply-To: <1041.65.170.190.143.1016252420.squirrel@www.abi.tconline.net> References: <1041.65.170.190.143.1016252420.squirrel@www.abi.tconline.net> Message-ID: >>>>> "Lewis" == Lewis Bergman writes: Lewis> Yes, a couple of hours after I wrote that I thought I probably Lewis> should have just tried it. =) Always the way. >> This does not directly solve your problem of needing to alter the >> value of the class attribute, but you can always use >> to select between normal and error >> variants of the tag. Lewis> Exactly how I was thinking of doing it anyway. Although, maybe Lewis> by the 2.0 version there will be some elegent, yea even "magic" Lewis> way of doing this. I thought of a way to do this sort of thing a while ago. I am not sure that it is a good idea though. It could lead to all sorts of confusion - I should give it a try at some point. Lewis> Maybe I will get to know albatross well enough one day to allow Lewis> me to write some class extending the exectution framework that Lewis> would do some validation and then pass back to the model the Lewis> fact that something didn't jive. There are hooks which could almost be used for that sort of thing. If you note in the Application.run() method there is a call to validate_request(). In the Application class the method always succeeds. If you make your own application class you could supply a method which does some form of validation and returns FALSE on failure. That will prevent the page_process() page module function being executed. Lewis> Maybe some presets even. Maybe alpha only, digits. only, hex, Lewis> only, alphanumeric, us phone, international phone, email(that's Lewis> controversial) . Ahhhh.... the regex's are endless. And of Lewis> course, good docs to tell how to (whats the term?) overload?, Lewis> supercede?. Overload (extend current function) or override (replace current function). Lewis> Thanks again for all the hard work. It is quite evident that Lewis> untold number of hours went into this. Lots and lots of work. Still more to come though. Lewis> I will say one thing about the docs though. They would be well Lewis> served by a PHP'ish style of giving the simple syntax of at Lewis> least the tags so someone might lookup what arguement's or Lewis> whatever a tag has. You know, how the first line of the docs Lewis> says: trimr(string[string], char[int], pos[int]) I made that Lewis> up. But a quick reference to the args, any type they might Lewis> expected to be and so on. But, I must admit, the flexability of Lewis> most of the tags would probably make that difficult. That is a good idea. Some sort of quick reference sheet which gave the call signature for each method of each class. The trouble we have is that we are too close to the code to think of things like that. Input from people just getting started is extremely valuable. - Dave -- http://www.object-craft.com.au From lbergman at abi.tconline.net Wed Mar 20 01:13:22 2002 From: lbergman at abi.tconline.net (Lewis Bergman) Date: Tue, 19 Mar 2002 08:13:22 -0600 Subject: [albatross-users] .6 prerequisite of python2.? Message-ID: <200203191413.g2JEDMr20777@lewis.abi.tconline.net> The following makes me wonder if some version of python other than what is listed in the manual (1.5.2) is required to enable all of albatross .6 to work as described? I was trying some of the installed samples and I ran across several tracebacks with popview4. (The session server one). Most were name errors and some attribute errors. Here is an example from the al-session-deamon: Server starting at Mon Mar 18 15:27:26 2002 new client: 5 from 127.0.0.1 client 5 cmd: new popview4 1800 Traceback (innermost last): File "./simpleserver.py", line 276, in handle_command sesid = self.make_sesid(words[1]) File "./simpleserver.py", line 256, in make_sesid sesid = binascii.hexlify(text) AttributeError: hexlify del client: 5 And some from the client: Template traceback (most recent call last): Traceback (innermost last): File "/usr/lib/python1.5/site-packages/albatross/app.py", line 165, in run self.load_session(ctx) File "/usr/lib/python1.5/site-packages/albatross/app.py", line 227, in load_session ctx.load_session() File "/usr/lib/python1.5/site-packages/albatross/session.py", line 67, in load_session sesid = self.app.new_session() File "/usr/lib/python1.5/site-packages/albatross/session.py", line 168, in new_session return self._server_read_response() File "/usr/lib/python1.5/site-packages/albatross/session.py", line 145, in _server_read_response raise SessionServerError('Session server returned: %s' % resp) SessionServerError: Session server returned: ERROR session server failure - check logs I first changed al-session-deamon to use 2.2 from 1.5.2 (I am on a RH7.2 sys) And that changed the client from a session server error to a name error (I think). It was involving a call to cookie I believe. No big deal if it is, I just would like to know. -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 915-695-6962 ext 115 From lbergman at abi.tconline.net Wed Mar 20 01:16:31 2002 From: lbergman at abi.tconline.net (Lewis Bergman) Date: Tue, 19 Mar 2002 08:16:31 -0600 Subject: [albatross-users] .6 prerequisite of python2.? Message-ID: <200203191416.g2JEGVh20781@lewis.abi.tconline.net> Oh, one last detail. Once the al-session-deamon and the popview.py script were changed to my 2.2 install binary of #!/usr/local/bin/python2.2 all worked fine. My #!/usr/local/env python and #!/usr/bin/python point to 1.5.2 -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 915-695-6962 ext 115 From andrewm at object-craft.com.au Wed Mar 20 10:36:35 2002 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 20 Mar 2002 10:36:35 +1100 Subject: [albatross-users] .6 prerequisite of python2.? In-Reply-To: Your message of "Tue, 19 Mar 2002 08:13:22 MDT." <200203191413.g2JEDMr20777@lewis.abi.tconline.net> Message-ID: <20020319233635.A2C7F38F4C@coffee.object-craft.com.au> >The following makes me wonder if some version of python other than what is >listed in the manual (1.5.2) is required to enable all of albatross .6 to >work as described? I think this is just an oversight - we develop with Python 2.2, but the intention is that Albatross work with 1.5.2. >SessionServerError: Session server returned: ERROR session server failure - >check logs BTW, when you get this, there should be a traceback in the session server's log file (if you have enabled logging). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Wed Mar 20 11:24:50 2002 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 20 Mar 2002 11:24:50 +1100 Subject: [albatross-users] .6 prerequisite of python2.? In-Reply-To: Your message of "Wed, 20 Mar 2002 10:36:35 +1100." <20020319233635.A2C7F38F4C@coffee.object-craft.com.au> Message-ID: <20020320002450.4B8CB38F4C@coffee.object-craft.com.au> >>SessionServerError: Session server returned: ERROR session server failure - >>check logs > >BTW, when you get this, there should be a traceback in the session server's >log file (if you have enabled logging). Shows how carefully I was reading - you had already posted this! 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Fri Mar 22 10:50:29 2002 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 22 Mar 2002 10:50:29 +1100 Subject: [albatross-users] Re: Python embedded like PHP Message-ID: <20020321235029.B66B438F4C@coffee.object-craft.com.au> > > Albatross encourages (but doesn't enforce) the separation of presentation > > and logic. You might do something like this in Albatross: > > > >
    > > > >
    • > >     > >
> > Why, oh why, does it use HTML-like syntax? People keep implementing > templating languages that do this over and over, and it's a bad, bad > idea. Any moderately complex example of templating will violate the > rules of HTML/SGML, with things like ">, which is horrible to read, will anger WYSIWYG > editors to no end, and isn't at all necessary. The intention is that Albatross templates be valid XML - while Albatross will do the expected thing in the example you give above, it generally provides a "better" way, such as: > All you have to do is use [] instead of <> -- it look about the same, > will have all the good cognitive associations (how nesting works, > etc), but is orthogonal to HTML, just like your templating system is > orthogonal to HTML. I.e., you're templates would look like But this wouldn't be XML... 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From ianb at colorstudy.com Fri Mar 22 11:17:38 2002 From: ianb at colorstudy.com (Ian Bicking) Date: 21 Mar 2002 18:17:38 -0600 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: <20020321235029.B66B438F4C@coffee.object-craft.com.au> References: <20020321235029.B66B438F4C@coffee.object-craft.com.au> Message-ID: <1016756258.554.46.camel@localhost> On Thu, 2002-03-21 at 17:50, Andrew McNamara wrote: > > > > Albatross encourages (but doesn't enforce) the separation of presentation > > > and logic. You might do something like this in Albatross: > > > > > >
    > > > > > >
    • > > >     > > >
> > > > Why, oh why, does it use HTML-like syntax? People keep implementing > > templating languages that do this over and over, and it's a bad, bad > > idea. Any moderately complex example of templating will violate the > > rules of HTML/SGML, with things like ">, which is horrible to read, will anger WYSIWYG > > editors to no end, and isn't at all necessary. > > The intention is that Albatross templates be valid XML - while Albatross > will do the expected thing in the example you give above, it generally > provides a "better" way, such as: > > Do you mean that you have a template tag for every kind of tag for which you would want to modify an attribute? That's every single HTML tag -- IMG is hardly the only one. A dynamic CSS class attribute, for instance, or events (onMouseOver, etc), id tags, background colors... there's a million possibilities. Plus you've got the same problems ZPT has, where it's not really proper -- or perhaps even possible -- to dynamically generate CSS or Javascript with your language, since they are generally guarded by comments and are thus opaque to XML. XML just seems so darn *hard*. Ian From andrewm at object-craft.com.au Fri Mar 22 11:37:38 2002 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 22 Mar 2002 11:37:38 +1100 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: Your message of "21 Mar 2002 18:17:38 MDT." <1016756258.554.46.camel@localhost> Message-ID: <20020322003738.A273C38F4C@coffee.object-craft.com.au> >> The intention is that Albatross templates be valid XML - while Albatross >> will do the expected thing in the example you give above, it generally >> provides a "better" way, such as: >> >> > >Do you mean that you have a template tag for every kind of tag for which >you would want to modify an attribute? That's every single HTML tag -- >IMG is hardly the only one. A dynamic CSS class attribute, for >instance, or events (onMouseOver, etc), id tags, background colors... >there's a million possibilities. No, we don't, although we're considering some options (such as abusing the XML namespace - for example: - thoughts? -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From djc at object-craft.com.au Fri Mar 22 18:31:07 2002 From: djc at object-craft.com.au (Dave Cole) Date: 22 Mar 2002 18:31:07 +1100 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: <1016756258.554.46.camel@localhost> References: <20020321235029.B66B438F4C@coffee.object-craft.com.au> <1016756258.554.46.camel@localhost> Message-ID: >>>>> "Ian" == Ian Bicking writes: >> The intention is that Albatross templates be valid XML - while >> Albatross will do the expected thing in the example you give above, >> it generally provides a "better" way, such as: >> >> Ian> Do you mean that you have a template tag for every kind of tag Ian> for which you would want to modify an attribute? That's every Ian> single HTML tag -- IMG is hardly the only one. A dynamic CSS Ian> class attribute, for instance, or events (onMouseOver, etc), id Ian> tags, background colors... there's a million possibilities. I think I can see your point. If I knew the perfect solution I would have tried implementing that. Ian> Plus you've got the same problems ZPT has, where it's not really Ian> proper -- or perhaps even possible -- to dynamically generate CSS Ian> or Javascript with your language, since they are generally Ian> guarded by comments and are thus opaque to XML. Ian> XML just seems so darn *hard*. I tried doing the ZPT thing - it made the template loading run like a slug on valium. You end up with at least one object for every tag and every attribute. With the Albatross templates you only end up with objects for the Albatross tags and attributes. As machines get faster this will not be such an issue. - Dave -- http://www.object-craft.com.au From lbergman at abi.tconline.net Sat Mar 23 03:22:13 2002 From: lbergman at abi.tconline.net (Lewis Bergman) Date: Fri, 22 Mar 2002 10:22:13 -0600 Subject: [albatross-users] General design question for ModularSessionApp Message-ID: <200203221622.g2MGMDQ24050@lewis.abi.tconline.net> In popview4 the main entry point for the app contains a class and it has one imported class. I am kind of at a loss as to what should go in this "entry point" and what should be in a imported class. I know the example is a simple one but the class in it seems to be pretty single purpose. I am designing a large app that will consist of data entry, modification, and reports on a postgres backend. I am having trouble deciding what (if anything) should be in the "entry point" file (popview in the example). I guess maybe classes that every module will need? Is that the main idea of that initial page? ( other than the obvious starting of the session ). The docs and examples are great but being new to python and albatross is overwhelming me at the moment. -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 915-695-6962 ext 115 From ianb at colorstudy.com Sat Mar 23 05:45:50 2002 From: ianb at colorstudy.com (Ian Bicking) Date: 22 Mar 2002 12:45:50 -0600 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: <20020322003738.A273C38F4C@coffee.object-craft.com.au> References: <20020322003738.A273C38F4C@coffee.object-craft.com.au> Message-ID: <1016822750.495.34.camel@localhost> On Thu, 2002-03-21 at 18:37, Andrew McNamara wrote: > >> The intention is that Albatross templates be valid XML - while Albatross > >> will do the expected thing in the example you give above, it generally > >> provides a "better" way, such as: > >> > >> > > > >Do you mean that you have a template tag for every kind of tag for which > >you would want to modify an attribute? That's every single HTML tag -- > >IMG is hardly the only one. A dynamic CSS class attribute, for > >instance, or events (onMouseOver, etc), id tags, background colors... > >there's a million possibilities. > > No, we don't, although we're considering some options (such as abusing > the XML namespace - for example: - thoughts? I assume you are thinking that any al-* tag that isn't otherwise defined would turn into a plain tag? So you'd do ? Seems kind of unXMLish as well. You could do something like: ...
 That's very long, and you have to parse the entire document (I'm not sure if you are doing that now). Actually, it looks horrible and if I was using such a language I would hate you. Maybe: ...
I'm not sure if that's quite kosher or not... I guess there's nothing really wrong about it, it just doesn't feel much like XML -- something about binding two elements together when they are only next to each other, not contained, seems odd. And it still isn't pretty. Of course there's the ZPT approach, which isn't bad, but then you might as well use ZPT. But I guess there's no reason you can't use something like ZPT just for changing attributes, like: And then skip all the looping and such that ZPT does with attributes. You'd still have the worry about generating CSS and Javascript, though. Dave mentioned performance... doing a full XML parse is performance-intensive, but you could fake it for this particular case -- you don't need to find the
tag or anything, you could probably do it just with regexes. I still think it's so much easier to use [], and make the system orthogonal to XML or any other medium you might want to generate. I think it actually gives you better tool support as well. Ian From djc at object-craft.com.au Sat Mar 23 14:50:19 2002 From: djc at object-craft.com.au (Dave Cole) Date: 23 Mar 2002 14:50:19 +1100 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: <1016822750.495.34.camel@localhost> References: <20020322003738.A273C38F4C@coffee.object-craft.com.au> <1016822750.495.34.camel@localhost> Message-ID: >>>>> "Ian" == Ian Bicking writes: >> No, we don't, although we're considering some options (such as >> abusing the XML namespace - for example: > expr:src="something"> - thoughts? Ian> I assume you are thinking that any al-* tag that isn't otherwise Ian> defined would turn into a plain tag? So you'd do expr:bgcolor="something"> ? Seems kind of unXMLish as well. Ian> You could do something like: Ian> ...
 Ian> That's very long, and you have to parse the entire document (I'm Ian> not sure if you are doing that now). Actually, it looks horrible Ian> and if I was using such a language I would hate you. Maybe: Ian> ...
Ian> I'm not sure if that's quite kosher or not... I guess there's Ian> nothing really wrong about it, it just doesn't feel much like XML Ian> -- something about binding two elements together when they are Ian> only next to each other, not contained, seems odd. And it still Ian> isn't pretty. I had a crazy idea a while ago which would stop us having to do the thing that you pointed out: "> The idea, which I am still not sold on, goes a bit like this: The first bit of template attaches an attribute name and value to an attribute id. This attribute association would be stored in the execution context so you could define values in your Python code if you wished. Albatross tags would then retrieve values from the association by using the same id attribute. This would allow Albatross templates to be much more flexible. Consider the tag. At the moment you have to staticly decide the name of the iterator. This means that you cannot reuse a bunch of template code which paginated a sequence in a macro since you would be using the same iterator for multiple sequences. With the above you could do this (not really a good example): blah blah spam eggs The functionality would require an extensive reworking of the tags code. There are some advantages to the approach but I am still a bit concerned that it is too obscure. Andrew has since mentioned changing the way that the we name the Albatross processed attributes to make them more functional and consistent. Something like: I am starting to think that this would be an excellent idea. Ian> Of course there's the ZPT approach, which isn't bad, but then you Ian> might as well use ZPT. But I guess there's no reason you can't Ian> use something like ZPT just for changing attributes, like: Ian> I have a few concerns about ZPT. You are forced to embed programming logic which is used to dynamically alter the presentation of the interface directly inside the presentation elements. I have a feeling that this makes the whole template unduly fragile and resistant to change. The idea that an HTML developer who does not understand ZPT will be able to ignore the ZPT attributes and just change the interface in isolation is a fantasy. The ZPT attributes define an executable program - their correct placement is critical to the functioning of the template. Note that the same is true of Albatross tags, but you can change the HTML in isolation to the Albatross tags. Ian> And then skip all the looping and such that ZPT does with Ian> attributes. You'd still have the worry about generating CSS and Ian> Javascript, though. Dave mentioned performance... doing a full Ian> XML parse is performance-intensive, but you could fake it for Ian> this particular case -- you don't need to find the
tag Ian> or anything, you could probably do it just with regexes. Ian> I still think it's so much easier to use [], and make the system Ian> orthogonal to XML or any other medium you might want to generate. Ian> I think it actually gives you better tool support as well. The [] characters do not make things much more pretty IMO. You sill end up with things like this: Something which would dynamically assign attributes to tags would look much nicer. The whole goal of Albatross is to place as little logic as is possible in the templating system. All real programming should be in Python. Having said that, I recognise that the templating system is far from perfect. If it was an easy problem, we would all be using the same templating system which was a standard Python module. - Dave -- http://www.object-craft.com.au From djc at object-craft.com.au Sat Mar 23 15:12:41 2002 From: djc at object-craft.com.au (Dave Cole) Date: 23 Mar 2002 15:12:41 +1100 Subject: [albatross-users] General design question for ModularSessionApp In-Reply-To: <200203221622.g2MGMDQ24050@lewis.abi.tconline.net> References: <200203221622.g2MGMDQ24050@lewis.abi.tconline.net> Message-ID: >>>>> "Lewis" == Lewis Bergman writes: Lewis> In popview4 the main entry point for the app contains a class Lewis> and it has one imported class. Lewis> I am kind of at a loss as to what should go in this "entry Lewis> point" and what should be in a imported class. I know the Lewis> example is a simple one but the class in it seems to be pretty Lewis> single purpose. Try to think of your problem in two parts. Think about the pure Python business logic first. That should dictate most of the structure of the Python code. Next think about how you want to present your business objects to the user. This will determine what HTML pages you need in your web application. Try to keep a clean separation between the implementation of the business logic and the presentation layer. The more complex your application the more important it will be to have a clean interface. By placing the business logic in pure Python you will be able to test the code without having to sit in front of a browser. Lewis> I am designing a large app that will consist of data entry, Lewis> modification, and reports on a postgres backend. I am having Lewis> trouble deciding what (if anything) should be in the "entry Lewis> point" file (popview in the example). I guess maybe classes Lewis> that every module will need? Is that the main idea of that Lewis> initial page? ( other than the obvious starting of the session Lewis> ). Start small by thinking of a simple part of the application which you can code quickly. Try building that portion of the application using Albatross. You will learn only by trying and making mistakes. This stuff is quite mind bending. Once you have some things going you will find the rest starts fall into place. I imagine that you have a model in your head but are having trouble trying to attach Albatross to that model. The best way to break the log jam is to use Albatross on a trivial problem to let Albatross become one of the mental constructs that you can push around in your head. Lewis> The docs and examples are great but being new to python and Lewis> albatross is overwhelming me at the moment. Start small and simple and build your knowledge slowly. - Dave -- http://www.object-craft.com.au From ianb at colorstudy.com Mon Mar 25 07:00:08 2002 From: ianb at colorstudy.com (Ian Bicking) Date: 24 Mar 2002 14:00:08 -0600 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: References: <20020322003738.A273C38F4C@coffee.object-craft.com.au> <1016822750.495.34.camel@localhost> Message-ID: <1017000019.3094.31.camel@localhost> On Fri, 2002-03-22 at 21:50, Dave Cole wrote: > I had a crazy idea a while ago which would stop us having to do the > thing that you pointed out: > > "> > > The idea, which I am still not sold on, goes a bit like this: > > > > > > The first bit of template attaches an attribute name and value to an > attribute id. This attribute association would be stored in the > execution context so you could define values in your Python code if > you wished. Albatross tags would then retrieve values from the > association by using the same id attribute. > > This would allow Albatross templates to be much more flexible. > Consider the tag. At the moment you have to staticly decide > the name of the iterator. This means that you cannot reuse a bunch of > template code which paginated a sequence in a macro since you would be > using the same iterator for multiple sequences. With the above you > could do this (not really a good example): > > > > blah blah > > > > > > spam > > > > eggs > > The functionality would require an extensive reworking of the tags > code. There are some advantages to the approach but I am still a > bit concerned that it is too obscure. For this problem, I think the solution is in the interpreter -- your macros are just hard to work with (from what I can see), because they are dynamically scoped and being used in lieu of real functions. It's not a syntax issue. > Andrew has since mentioned changing the way that the we name the > Albatross processed attributes to make them more functional and > consistent. Something like: > > > > > I am starting to think that this would be an excellent idea. > > Ian> Of course there's the ZPT approach, which isn't bad, but then you > Ian> might as well use ZPT. But I guess there's no reason you can't > Ian> use something like ZPT just for changing attributes, like: > > Ian> > > I have a few concerns about ZPT. > > You are forced to embed programming logic which is used to dynamically > alter the presentation of the interface directly inside the > presentation elements. I have a feeling that this makes the whole > template unduly fragile and resistant to change. > > The idea that an HTML developer who does not understand ZPT will be > able to ignore the ZPT attributes and just change the interface in > isolation is a fantasy. The ZPT attributes define an executable > program - their correct placement is critical to the functioning of > the template. Note that the same is true of Albatross tags, but you > can change the HTML in isolation to the Albatross tags. I'm not sold on all the benefits of ZPT either, but I think it's a natural fit for the particular case of replacing an attribute value. To me,
reads pretty well, and should make some intuitive sense even if you don't understand the scripting itself. All attributes are kind of hidden, and the dynamic statement is no more hidden than the thing it is replacing. Also, you're left with a mostly-intact tag -- al-td isn't an HTML tag, and software that understands HTML won't understand that tag. That means you can't preview the unrendered code in a browser and you can't let a WYSIWYG editor touch it. Ian From djc at object-craft.com.au Tue Mar 26 01:09:44 2002 From: djc at object-craft.com.au (Dave Cole) Date: 26 Mar 2002 01:09:44 +1100 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: <1017000019.3094.31.camel@localhost> References: <20020322003738.A273C38F4C@coffee.object-craft.com.au> <1016822750.495.34.camel@localhost> <1017000019.3094.31.camel@localhost> Message-ID: > For this problem, I think the solution is in the interpreter -- your > macros are just hard to work with (from what I can see), because > they are dynamically scoped and being used in lieu of real > functions. It's not a syntax issue. I would really like it if you could explain a little further. The macros do sort of work like functions in that they pass arbitrary template content to the macro for substitution at the location specified by the macro. I tried to work out a simple way in which values from the execution context namespace could be passed as arguments but couldn't see how to do it in a nice fashion > I'm not sold on all the benefits of ZPT either, but I think it's a > natural fit for the particular case of replacing an attribute value. > To me, reads pretty well, and > should make some intuitive sense even if you don't understand the > scripting itself. All attributes are kind of hidden, and the > dynamic statement is no more hidden than the thing it is replacing. I agree. My biggest problem with ZPT was the control flow. > Also, you're left with a mostly-intact tag -- al-td isn't an HTML > tag, and software that understands HTML won't understand that tag. > That means you can't preview the unrendered code in a browser and > you can't let a WYSIWYG editor touch it. The reason for the al- prefix is to allow the regex parser to recognise the tag in amongst the plain HTML tags. - Dave -- http://www.object-craft.com.au From lbergman at abi.tconline.net Tue Mar 26 06:43:25 2002 From: lbergman at abi.tconline.net (Lewis Bergman) Date: Mon, 25 Mar 2002 13:43:25 -0600 Subject: [albatross-users] examples and ctx Message-ID: <200203252107.g2PL7m103190@lewis.abi.tconline.net> I noticed that in the examples in the manual the first few show in the code where ctx is created as an object. For example in simple5 we have : ctx = SimpleContext('.') After we initiate the session app we don't see this again. Instead we see this : if __name__ == '__main__': app = App() app.run(Request()) Is this because the ctx object is initiated by the run() method in the backround mixin classes as described (I think) in the manual starting at 4.1? I am trying to get this straight in my head because the popview app doesn't seem to behave as expected and I am trying to ensure I have the theory down. The ctx object just appears but if I understand correctly it is created by the app.run(Request()) call correct? -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 915-695-6962 ext 115 From ianb at colorstudy.com Tue Mar 26 02:11:59 2002 From: ianb at colorstudy.com (Ian Bicking) Date: 25 Mar 2002 09:11:59 -0600 Subject: [albatross-users] Re: Python embedded like PHP In-Reply-To: References: <20020322003738.A273C38F4C@coffee.object-craft.com.au> <1016822750.495.34.camel@localhost> <1017000019.3094.31.camel@localhost> Message-ID: <1017069119.589.18.camel@localhost> On Mon, 2002-03-25 at 08:09, Dave Cole wrote: > > For this problem, I think the solution is in the interpreter -- your > > macros are just hard to work with (from what I can see), because > > they are dynamically scoped and being used in lieu of real > > functions. It's not a syntax issue. > > I would really like it if you could explain a little further. > > The macros do sort of work like functions in that they pass arbitrary > template content to the macro for substitution at the location > specified by the macro. > > I tried to work out a simple way in which values from the execution > context namespace could be passed as arguments but couldn't see how to > do it in a nice fashion Well, you might be able to help the situation some if you create a new scope for the macro, and have something like dtml-let -- that way you could do stuff like. That way variable assignments inside your macro will pass out of scope when the macro finishes, and at least not overwrite things in the main scope. You can use some form of let to manipulate the namespace when it doesn't match what the macro expects. This is what DTML does, and I assume ZPT uses the same mechanisms (it only seems to be a change of syntax). I don't like this at all, though, as there's all sorts of problems that pop up when you start abstracting things more deeply. Also, I think macros are very important, and keeping them python-like is a very nice. Then you can define, inside a single template, not only the full page style, but the style of components of the page. For instance, I create pages that create headers with lists underneath them, all entirely dynamic. If the template can define what a header and what a list should look like, then I have much more power over the look of the page. I'd pass arguments like: This seems pretty straight-forward, and also maps directly to keyword arguments. You could add the syntax: (which isn't XML, but so it goes), which would equivalent to -- basically saying which parts of the namespace to pass in. It should also be fairly easy to create Python functions that do the same thing as the macro. Some people will still want to pass in entire namespaces... you could use inclusion instead of macros in that case, or make another form of macros. You could also make another form of setting variables, that sets them globally (perhaps as constants) -- this is much cleaner than making every passing variable and loop global. Ian From djc at object-craft.com.au Tue Mar 26 21:38:15 2002 From: djc at object-craft.com.au (Dave Cole) Date: 26 Mar 2002 21:38:15 +1100 Subject: [albatross-users] examples and ctx In-Reply-To: <200203252107.g2PL7m103190@lewis.abi.tconline.net> References: <200203252107.g2PL7m103190@lewis.abi.tconline.net> Message-ID: > I noticed that in the examples in the manual the first few show in > the code where ctx is created as an object. For example in simple5 > we have : ctx = SimpleContext('.') > > After we initiate the session app we don't see this again. Instead > we see this: > if __name__ == '__main__': > app = App() > app.run(Request()) > > Is this because the ctx object is initiated by the run() method in > the backround mixin classes as described (I think) in the manual > starting at 4.1? When you use an Albatross application object it creates an execution context on your behalf as part of the application run() method. Ignoring the exception handling, the run() method looks like this: ctx = self.create_context() ctx.set_request(req) self.load_session(ctx) self.load_page(ctx) if self.validate_request(ctx): self.merge_request(ctx) self.process_request(ctx) self.display_response(ctx) self.save_session(ctx) So the first stage of the run() method creates an execution context and attaches the browser request to it. If you look at the implementation of the create_context() method of the application class you will see the familiar call to the execution context constructor. For example the ModularSessionApp application class creates a SessionAppContext execution context whereas the SimpleApp application class creates a SimpleAppContext execution context. > I am trying to get this straight in my head because the popview app > doesn't seem to behave as expected and I am trying to ensure I have > the theory down. The ctx object just appears but if I understand > correctly it is created by the app.run(Request()) call correct? Yes. Once you have determined which application and execution context you are using you can use the inheritance diagrams in chapter 8 to see where each of the methods are implemented. The diagrams are UML. A class points to the class(es) from which it inherits behaviour. The diagrams are arranged to match the order of inheritance in Python. Superclasses are drawn above the classes which inherit from them. When a class uses multiple inheritance, the superclasses are drawn in the same left to right sequence as the inheritance in Python. This means that you scan the diagram bottom to top, left to right to find which implementation of a method will be used. - Dave -- http://www.object-craft.com.au