From mike at daboyz.org Sat Jan 4 11:14:00 2003 From: mike at daboyz.org (Michael Barrett) Date: Fri, 3 Jan 2003 16:14:00 -0800 Subject: [albatross-users] Form Field Value Storage Changed? Message-ID: <20030104001400.GB67085@daboyz.org> Hi, I was writing an application back with .6 of albatross and thinks were working just fine. However, I just upgraded to 1.0 and I've gotten most of the initial problems (random module became randompage, etc) fixed. However I'm being plagued by another problem that I can't seem to figure out quite yet. Pretty much, I have a form and before when I hit submit on that form it would submit to the same page. The values that were put into the fields of the form would be accessible in the ctx.locals object. For example, I had an input field (button) named 'query' which you would click when you were finished with the form. Before I could just look at ctx.locals.query for the value. Now however I no longer get any value in that variable. Has the way that form values are saved been changed? As far as which context I'm using, it's the SessionFileAppContext. I'm also using my own module to maintain the session data called RandomModularSessionFileApp, something I created back in .6 to bridge the gap that I had found. Any help you can give will be much appreciated. Thank you. -- Michael E. Barrett From andrewm at object-craft.com.au Mon Jan 6 13:00:54 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 06 Jan 2003 13:00:54 +1100 Subject: [albatross-users] Form Field Value Storage Changed? In-Reply-To: Message from Michael Barrett of "Fri, 03 Jan 2003 16:14:00 -0800." <20030104001400.GB67085@daboyz.org> References: <20030104001400.GB67085@daboyz.org> Message-ID: <20030106020054.E8A903C1F4@coffee.object-craft.com.au> > Pretty much, I have a form and before when I hit submit on that form it > would submit to the same page. The values that were put into the fields > of the form would be accessible in the ctx.locals object. For example, > I had an input field (button) named 'query' which you would click when you > were finished with the form. Before I could just look at ctx.locals.query > for the value. Now however I no longer get any value in that variable. > > Has the way that form values are saved been changed? As far as which > context I'm using, it's the SessionFileAppContext. I'm also using my own > module to maintain the session data called RandomModularSessionFileApp, > something I created back in .6 to bridge the gap that I had found. The merging of fields back into the local context was tightened slightly in the name of security, although I'm not sure how this would be effecting your application. Are you able to post a minimal application that demonstrates the problem you are seeing? Another technique I find useful in these cases is to add debugging to albatross itself - basically, just sys.stderr.write() at strategic places to see what's being passed in. The logical place to start is albatross/context.py, specifically the NameRecorderMixin class and the merge_request method. "merge_request" looks a little scary - essentially, if the request doesn't have an __albform__ field, it is merged straight in. If it does have an __albform__ (which is a md5 signed, gziped base64 pickle), then this drives the merging back into ctx.locals. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From gnb at itga.com.au Fri Jan 10 12:55:11 2003 From: gnb at itga.com.au (Gregory Bond) Date: Fri, 10 Jan 2003 12:55:11 +1100 Subject: [albatross-users] Handy mod_python hint In-Reply-To: Your message of Mon, 23 Dec 2002 15:02:10 +1100. Message-ID: <200301100155.MAA28003@lightning.itga.com.au> I wrote: > You can run a single Albatross program either as a normal CGI, as a native > mod_python script, or as a CGI under mod_python using mod_python's cgihandler > , > with a trick like this: > > try: > os.environ['GATEWAY_INTERFACE'] > cgi = 1 > except: > cgi = 0 > > from albatross import SimpleSessionFileApp, SessionFileAppContext > if cgi: > from albatross.cgiapp import Request > else: > from albatross.apacheapp import Request [rest snipped] This part can all be simplified and also made to work from the command line (for simpler testing) by changing the above to: from albatross import SimpleSessionFileApp, SessionFileAppContext try: from albatross.apacheapp import Request cgi = 0 except ImportError: cgi = 1 from albatross.cgiapp import Request This depends on the fact that albatross.apacheapp imports mod_python, and this will always fail unless this script is being imported by mod_python inside a running apache process. Greg. From neel at mediapulse.com Sat Jan 11 07:25:51 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Fri, 10 Jan 2003 15:25:51 -0500 Subject: [albatross-users] More SQL goodness Message-ID: A while back, I posted my alx-sql tag, which has served me greatly so far, but I got tired of cluttering up a template with a lot of basic queries for lookup tables in select boxes. That, and not being able to mix optionexpr with tags bugged me. So here is my alx-sqlselect and alx-sqloption tags, which if you find useful feel free to use =D A few notes, first I have a pretty standard way of creating lookup tables in my apps, and these tags are written with that in mind, they have some flexability but you still may need to alter the code to work with your db scheme. Also, this is still in development, and may have an issue or two, but so far it's been working fine here. My globals.py defines db, which is used below (another convention of mine). For reference, my lookup tables look like: CREATE TABLE lookup ( lookup_id int(10) unsigned zerofill NOT NULL auto_increment, ordering int(10) unsigned NOT NULL default '0', code varchar(10) NOT NULL default '', text varchar(255) NOT NULL default '', deleted enum('Y','N') NOT NULL default 'N', PRIMARY KEY (lookup_id) ) TYPE=MyISAM COMMENT='Lookup Table for a generic lookup' The tag in use looks like: Pick one... Other You can also have a where and an order argument. Notice that the al-option can be mixed in, and the alx-option tag is and empty tag (i.e. no ). Also, since the alx-sqlselect is sub classed from the standard al-select, all normal options (like nameexpr) will still work, and just like before and optionexpr will override the al-option/alx-sqloption tags (so there would be no point in doing that, use al-select instead). Here is the python code: import albatross from globals import * class SqlSelect(albatross.tags.Select): name = "al-sqlselect" def append(self, tag): if isinstance(tag, SqlOption) or isinstance(tag, albatross.tags.Option): self.options.append(tag) else: EnclosingTag.append(self, tag) class SqlOption(albatross.EmptyTag): name = 'al-sqloption' def to_html(self, ctx, select_value): if self.has_attrib('table'): table = self.get_attrib('table') # set defaults index = "%s_id" % table text = "text" order = "ordering" where = "deleted = 'N'" if self.has_attrib('index'): index = self.get_attrib('index') if self.has_attrib('text'): text = self.get_attrib('text') if self.has_attrib('order'): order = self.get_attrib('order') if self.has_attrib('where'): where = self.get_attrib('where') c = db.cursor() c.execute("""SELECT %s, %s FROM %s WHERE %s ORDER BY %s""" % (index, text, table, where, order)) for (value, label) in c.fetchall(): ctx.write_content('' % albatross.tags.escape(value)) ctx.write_content(albatross.tags.escape(label)) Hope this is helpful to somebody out there, and have a great weekend! Mike From mike at daboyz.org Sat Jan 11 19:28:18 2003 From: mike at daboyz.org (Michael Barrett) Date: Sat, 11 Jan 2003 00:28:18 -0800 Subject: [albatross-users] Form Field Value Storage Changed? In-Reply-To: <20030106020054.E8A903C1F4@coffee.object-craft.com.au> References: <20030104001400.GB67085@daboyz.org> <20030106020054.E8A903C1F4@coffee.object-craft.com.au> Message-ID: <20030111082818.GA47308@daboyz.org> Ok, here's a minimal application that doens't work the way I'd expect it to on my system. There are four parts. The template, the script, my RandomSessionFileApp mixin (I think thats the proper term?) and the index.py. index.py: #!/usr/local/bin/python from albatross import SessionFileAppContext from albatross.cgiapp import Request import sys, md5 sys.path.append('.') from albext import RandomModularSessionFileApp class AppContext(SessionFileAppContext): def __init__(self, app): SessionFileAppContext.__init__(self, app) self.log = open('/tmp/ocd.log','a',0) class App(RandomModularSessionFileApp): def __init__(self): RandomModularSessionFileApp.__init__(self, base_url = 'index.py', module_path = './lib', template_path = './templates', start_page = 'test', secret = '-=-secret-=-', session_appid = 'alb', session_dir = './session') # Configuration data self.Config = {} self.Config['smtpHost'] = '127.0.0.1' self.Config['smtpPort'] = 25 self.Config['siteurl'] = 'http://home.daboyz.org/ocd/alb' def create_context(self): return AppContext(self) if __name__ == '__main__': app = App() app.run(Request()) ====== lib/test.py: def page_enter(ctx): ctx.locals.submitted = 0 def page_display(ctx): ctx.run_template('test.xml') ====== templates/test.xml: Submitted? - - ====== albext.py: from albatross.context import CachingTemplateLoaderMixin, PickleSignMixin, _caller_globals from albatross.app import Application, PageModuleMixin from albatross.sessionfile import SessionFileAppMixin, SessionFileAppContext from albatross.randompage import RandomPageModuleMixin class RandomModularSessionFileApp(PickleSignMixin, Application, CachingTemplateLoaderMixin, RandomPageModuleMixin, SessionFileAppMixin): def __init__(self, base_url, module_path, template_path, start_page, secret, session_appid, session_dir): PickleSignMixin.__init__(self, secret) Application.__init__(self, base_url) CachingTemplateLoaderMixin.__init__(self, template_path) RandomPageModuleMixin.__init__(self, module_path, start_page) SessionFileAppMixin.__init__(self, session_appid, session_dir) def create_context(self): return SessionFileAppContext(self) ====== Anyways, you can see this running @ http://home.daboyz.org/alb/ As you'll see, no matter if you click on the button or not, submitted is still set to '0'. Did page_enter and page_display change possibly? I'm at a loss so far, and I thought maybe it was something simple that I just wasn't aware of in the change of versions that someone who's been more active with albatross over the past couple months might be able to pick up right away. Again, thanks for all your help. On Mon, Jan 06, 2003 at 01:00:54PM +1100, Andrew McNamara wrote: > The merging of fields back into the local context was tightened slightly > in the name of security, although I'm not sure how this would be effecting > your application. > > Are you able to post a minimal application that demonstrates the problem > you are seeing? From mike at daboyz.org Sat Jan 11 19:48:02 2003 From: mike at daboyz.org (Michael Barrett) Date: Sat, 11 Jan 2003 00:48:02 -0800 Subject: [albatross-users] Form Field Value Storage Changed? In-Reply-To: <20030106020054.E8A903C1F4@coffee.object-craft.com.au> References: <20030104001400.GB67085@daboyz.org> <20030106020054.E8A903C1F4@coffee.object-craft.com.au> Message-ID: <20030111084802.GA47526@daboyz.org> Ok, after doing a little troubleshooting based on what you told me below I've found that it seems to be the fault of the tags. IE: what you said below seems to be the culprit. When there's an __albform__ field in the req then it does a whole lot of stuff that I haven't even started to try to understand. Does anyone know why this is? Is there supposed to be a time and a place (such as mine) when you shouldn't be using instead of just
calls? On Mon, Jan 06, 2003 at 01:00:54PM +1100, Andrew McNamara wrote: > > Pretty much, I have a form and before when I hit submit on that form it > > would submit to the same page. The values that were put into the fields > > of the form would be accessible in the ctx.locals object. For example, > > I had an input field (button) named 'query' which you would click when you > > were finished with the form. Before I could just look at ctx.locals.query > > for the value. Now however I no longer get any value in that variable. > > > > Has the way that form values are saved been changed? As far as which > > context I'm using, it's the SessionFileAppContext. I'm also using my own > > module to maintain the session data called RandomModularSessionFileApp, > > something I created back in .6 to bridge the gap that I had found. > > The merging of fields back into the local context was tightened slightly > in the name of security, although I'm not sure how this would be effecting > your application. > > Are you able to post a minimal application that demonstrates the problem > you are seeing? > > Another technique I find useful in these cases is to add debugging to > albatross itself - basically, just sys.stderr.write() at strategic > places to see what's being passed in. The logical place to start is > albatross/context.py, specifically the NameRecorderMixin class and the > merge_request method. > > "merge_request" looks a little scary - essentially, if the request > doesn't have an __albform__ field, it is merged straight in. If it > does have an __albform__ (which is a md5 signed, gziped base64 pickle), > then this drives the merging back into ctx.locals. > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- From andrewm at object-craft.com.au Mon Jan 13 15:20:09 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Mon, 13 Jan 2003 15:20:09 +1100 Subject: [albatross-users] Form Field Value Storage Changed? In-Reply-To: Message from Michael Barrett of "Sat, 11 Jan 2003 00:28:18 -0800." <20030111082818.GA47308@daboyz.org> References: <20030104001400.GB67085@daboyz.org> <20030106020054.E8A903C1F4@coffee.object-craft.com.au> <20030111082818.GA47308@daboyz.org> Message-ID: <20030113042009.E9AD23C1F6@coffee.object-craft.com.au> >templates/test.xml: > > > > > > > Submitted? - - > > The element should be . What happens inside Albatross is that all the al-input's in a template are recorded, and their details added to an "__albform__" hidden field that is added at the end of the element. When the form is submitted by the browser, Albatross only merges inputs mentioned in the __albform__ structure. So, by using instead of , your input isn't recorded in the __albform__ and therefore isn't merged back into ctx.locals on submission. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From djc at object-craft.com.au Tue Jan 14 10:57:21 2003 From: djc at object-craft.com.au (Dave Cole) Date: 14 Jan 2003 10:57:21 +1100 Subject: [albatross-users] Form Field Value Storage Changed? In-Reply-To: <20030111084802.GA47526@daboyz.org> References: <20030104001400.GB67085@daboyz.org> <20030106020054.E8A903C1F4@coffee.object-craft.com.au> <20030111084802.GA47526@daboyz.org> Message-ID: >>>>> "Michael" == Michael Barrett writes: Michael> Ok, after doing a little troubleshooting based on what you Michael> told me below I've found that it seems to be the fault of the Michael> tags. IE: what you said below seems to be the Michael> culprit. When there's an __albform__ field in the req then Michael> it does a whole lot of stuff that I haven't even started to Michael> try to understand. It tries to do a few things which simplify your code. If you have a form which looks like this: and the user only supplies input to field1 then the browser will not mention field2 in the request. When you use and the form will get an additional hidden field called __albform__ which describes the content of the form which was sent to the browser. Upon reception of the request Albatross decodes the __albform__ and does the following: 1) Any field not present in the browser request is set to None in ctx.locals. This allows you to assume that all field in the form as always present, even if they have the value None. 2) If you had multiple instances of field2 in the form, Albatross will always return the value of field2 as a list. This saves you from having to constantly write code like this: if hasattr(ctx.locals, 'field2'): if type(ctx.locals.field2) is type([]): # something else: # something else: # something you are able to just do this: for value in ctx.locals.field2: # something Michael> Does anyone know why this is? Is there supposed to be a time Michael> and a place (such as mine) when you shouldn't be using Michael> instead of just
calls? If you use and then the request merging will be merge all fields presented by the browser. This might be what you want. The reason why Albatross uses tags is purely for performance reasons. The template parser treats all template content as plain text which is delimited by tags. The alternative would have a huge performance impact --- all of a sudden every tag, attribute, and value would be a new Python object. - Dave -- http://www.object-craft.com.au From gnb at itga.com.au Wed Jan 15 14:25:15 2003 From: gnb at itga.com.au (Gregory Bond) Date: Wed, 15 Jan 2003 14:25:15 +1100 Subject: [albatross-users] Macro default args Message-ID: <200301150325.OAA03897@lightning.itga.com.au> I needed this so I made the attached patch (code only, not docco!) Usage: This is OK for small amounts of text, but not fabulous for large macro args. I use it for small things like specifying colors etc:
">
Normal stuff in a box redError!! -------------- next part -------------- --- albatross/tags.py.DIST Thu Sep 5 00:07:10 2002 +++ albatross/tags.py Wed Jan 15 14:17:50 2003 @@ -9,6 +9,7 @@ import time from albatross.template import Content, EmptyTag, EnclosingTag +from albatross.context import MacroError # Empty content object which tags can use as default value for # optional child tag content. , , etc. @@ -1054,7 +1055,14 @@ name = 'al-usearg' def to_html(self, ctx): - text = ctx.get_macro_arg(self.get_attrib('name')) + try: + text = ctx.get_macro_arg(self.get_attrib('name')) + except MacroError: + # OK, look for a default= clause + if self.has_attrib('default'): + text = self.get_attrib('default') + else: + raise ctx.write_content(text) class Macro(EnclosingTag): From gnb at itga.com.au Wed Jan 15 14:39:41 2003 From: gnb at itga.com.au (Gregory Bond) Date: Wed, 15 Jan 2003 14:39:41 +1100 Subject: [albatross-users] Macro default args In-Reply-To: Your message of Wed, 15 Jan 2003 14:25:15 +1100. Message-ID: <200301150339.OAA04773@lightning.itga.com.au> By the way: I'd love to be able to do Error!! instead of redError!! (i.e. put macro args in the al-expand tag.) Again, only useful for small amounts of argument text, but much neater. Some hackery in Expand.to_html should do it (see below). This only allows plain text substitutions (no nested etc), but will still work with the which is better for longer or more complicated macro text. What do people think? -------------- next part -------------- --- albatross/tags.py.DIST1 Wed Jan 15 14:33:07 2003 +++ albatross/tags.py Wed Jan 15 14:35:51 2003 @@ -1100,6 +1100,9 @@ if not macro: self.raise_error('undefined macro "%s"' % self.get_attrib('name')) dict = {} + for k, v in self.attrib_items(): + if k != 'name': + dict[k] = v ctx.push_content_trap() self.content.to_html(ctx) dict[None] = ctx.pop_content_trap() From gnb at itga.com.au Fri Jan 17 14:34:28 2003 From: gnb at itga.com.au (Gregory Bond) Date: Fri, 17 Jan 2003 14:34:28 +1100 Subject: [albatross-users] Access to current/other page objects/modules Message-ID: <200301170334.OAA26960@lightning.itga.com.au> I'm trying to work out a way to do semi-automated navigation. I'm using a file-based session and page classes, tho something portable to page modules wouldn't hurt. The actual navigation I can do with a page base class, and a nav_to[] class variable for each page class that the base class page_process() can look at. But I can't work out a way to generate a nav bar HTML automatically. Ideally, I'd like each page class to have a description, which might depend on the current local context / session, and then have a single tag/function/macro/ something that can be called from a template and can: - find the class object for the current page - for each of the class objects mentioned in the nav_to[] member: - find the class object for this destination page - find the description of this destination page after possibly substituing stuff from the current session with al-value etc - Generate a tag with the appropriate description. So given something like: class Start(PageBase): name='start' nav_desc='Start Again' #... class HomeAddress(PageBase): name='homeaddr' nav_to=['start', 'workaddr'] nav_desc = 'Update Home Address for ' #... class WorkAddress(PageBase): name='workaddr' nav_to=['start', 'homeaddr'] nav_desc = 'Update Work Address for ' then I could from homeaddr.html call a macro / custom tag that would produce Start Again Update Work Address for BOND But I can't work out a way of doing this that has access to all the pieces needed.... which (afaict) amounts to - the current session (for substituting into descriptions) - the current page class object ("self" in page_display()) - the list of page objects (hidden inside the current application object?) and is callable from the middle of a HTML template. Any ideas? From bdhruva at gmx.net Fri Jan 24 04:37:04 2003 From: bdhruva at gmx.net (Dhruva B. Reddy) Date: Thu, 23 Jan 2003 10:37:04 -0700 Subject: [albatross-users] Pagination Issue Message-ID: <20030123173704.GA3402@greatspacetoaster> Hello, We have developed an application that uses Albatross's pagination support to display query results. It is supposed to display the total number of results, then each result (20 per page). However, it intermittently fails to display the results. Here are a few other observations: -The number of results is accurately displayed. -I have noticed this problem on queries that yield fewer than 20 results. -We have buttons to access the next/previous 20 results. The button for the previous set is displayed, and clicking on it displays the results. Has anyone seen anything like this before? Any clues at all would be greatly appreciated. Many thanks, Dhruva -- "Advice is what we ask for when we already know the answer but wish we didn't." Erica Jong (b. 1942); US author From andrewm at object-craft.com.au Fri Jan 24 10:37:40 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 24 Jan 2003 10:37:40 +1100 Subject: [albatross-users] Access to current/other page objects/modules In-Reply-To: Message from Gregory Bond of "Fri, 17 Jan 2003 14:34:28 +1100." <200301170334.OAA26960@lightning.itga.com.au> References: <200301170334.OAA26960@lightning.itga.com.au> Message-ID: <20030123233740.6BD793C1F4@coffee.object-craft.com.au> >But I can't work out a way of doing this that has access to all the pieces >needed.... which (afaict) amounts to > - the current session (for substituting into descriptions) > - the current page class object ("self" in page_display()) > - the list of page objects (hidden inside the current application object?) >and is callable from the middle of a HTML template. Could the PageBase class copy the relevent data from the subclass into ctx.locals in the page_enter method? Something like (off the top of my head): class PageDetails: def __init__(self, name, desc, nav): self.name = name self.desc = desc self.nav = nav class PageBase: def page_enter(ctx): details = PageDetails(self.name, self.nav_desc, self.nav_to) ctx.locals.page_details = details -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From andrewm at object-craft.com.au Fri Jan 24 10:50:13 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 24 Jan 2003 10:50:13 +1100 Subject: [albatross-users] Pagination Issue In-Reply-To: Message from "Dhruva B. Reddy" of "Thu, 23 Jan 2003 10:37:04 PDT." <20030123173704.GA3402@greatspacetoaster> References: <20030123173704.GA3402@greatspacetoaster> Message-ID: <20030123235013.11E913C1F4@coffee.object-craft.com.au> >It is supposed to display the total number of results, then each result >(20 per page). However, it intermittently fails to display the results. [...] >Has anyone seen anything like this before? Any clues at all would be >greatly appreciated. I think the first thing to do is to pull bits out of your application until you have the smallest amount of code that still demonstrates your problem. For example - there's a lot of complexity potentially hiding in the query logic - try replacing it with some statically generated data and see if you can still reproduce the problem. You can also work in the other direction - start with the pagination example included with Albatross and see if you can make it fail in the same way as your application. It you can reduce it to a simple enough example, consider posting it to the list, and maybe someone on the list will be able to help you. The other thing to remember is that Albatross isn't a closed box - you're invited to tinker with it's internals in any way you want. In particular, you might want to strategically place some sys.stderr.write() statements in it so you can see how it's handling your request. You'll want to look at the For and ListIterator classes in the tag.py module. Please let us know what you find - even if it turns out to be a bug in your code, it may spur us on to improving the documentation... 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From bdhruva at gmx.net Fri Jan 24 10:55:01 2003 From: bdhruva at gmx.net (Dhruva B. Reddy) Date: Thu, 23 Jan 2003 16:55:01 -0700 Subject: [albatross-users] Trying to Integrate with PayPal Message-ID: <20030123235501.GC5577@greatspacetoaster> Hi, I am working with PayPal (using their Instant Payment Notification service), and it sends a POST request back to my application. This request contains a field whose name is of zero-length. This causes albatross to barf in context.set_value(), line 323. I tried putting in the following check and it seems to work: if len(name) == 0: return Does anyone know if there is any harm in doing this? Thanks, -d -- "Advice is what we ask for when we already know the answer but wish we didn't." Erica Jong (b. 1942); US author From gnb at itga.com.au Fri Jan 24 11:04:16 2003 From: gnb at itga.com.au (Gregory Bond) Date: Fri, 24 Jan 2003 11:04:16 +1100 Subject: [albatross-users] Access to current/other page objects/modules In-Reply-To: Your message of Fri, 24 Jan 2003 10:37:40 +1100. Message-ID: <200301240004.LAA29572@lightning.itga.com.au> Andrew, Thanks for your response. I was about to post a followup.... > Could the PageBase class copy the relevent data from the subclass into > ctx.locals in the page_enter method? I thought of that, but you also have to add it the session so that page refreshes work right. And it was still not clear how to access this information in a way that says "place an HTML nabvar here". After a fair bit of experimenting I've come up with the following solution that seems to work OK: - Do it with a new tag, as this will have access to the ctx for generating html - The ctx object has a reference to the application object in ctx.app - The ctx object also has the name of the current page in ctx.locals.__page__ - Alas, with the standard PageObjectMixin there is no way to get at the map of names->page objects, because this is hidden by the funky handling of the __page_objects name. No other method of the mixin gives access to a page object without undesriable side effects! - This can be fixed with a patch to add a page_object() method the mixin, or you can override the register_page() method in your app class and keep a second parallel copy of the page_objects dict: def register_page(self, name, cls): self.page_objects[name] = cls SimpleSessionFileApp.register_page(self, name, cls) def page_object(self, name): return self.page_objects[name] - The to_html() method of the navbar tag can recognise when the descriptions have embedded albatross tags and treat them as a kind of mini template. This took the most hunting and fiddling and I'm not entirely sure I've done it the best way.... - copy the ideas from the al-a tag to format the actual navbar links. so my tag class looks like this: class NavBar(EmptyTag): ''' The main guts of the navbar, based on the @nav_to & @description page class members. Applications can subclass this and replace the to_html() and format_link() functions to change the look of the navbar. They will need to (re-) register the tag in the application code to get the overriden version tho. ''' name = 'alx-navbar' def to_html(self, ctx): ctx.write_content('\n
\n') self.do_links(ctx) ctx.write_content('\n') def do_links(self, ctx): self.format_link(ctx, 'restart', 'Start Again') if len(ctx.locals.back) > 0: self.format_link(ctx, 'goback', 'Back') pclass = ctx.app.page_object(ctx.locals.__page__) for dest in pclass.nav_to: dclass = ctx.app.page_object(dest) desc = dclass.description if desc.find("= 0: ctx.push_content_trap() Template(ctx, '', desc).to_html(ctx) desc = ctx.pop_content_trap() self.format_link(ctx, dest, desc) def format_link(self, ctx, href, desc): ctx.write_content('%s  \n' % (ctx.current_url(), href, desc)) From andrewm at object-craft.com.au Fri Jan 24 11:15:26 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Fri, 24 Jan 2003 11:15:26 +1100 Subject: [albatross-users] Trying to Integrate with PayPal In-Reply-To: Message from "Dhruva B. Reddy" of "Thu, 23 Jan 2003 16:55:01 PDT." <20030123235501.GC5577@greatspacetoaster> References: <20030123235501.GC5577@greatspacetoaster> Message-ID: <20030124001526.53C383C1F4@coffee.object-craft.com.au> >I am working with PayPal (using their Instant Payment Notification >service), and it sends a POST request back to my application. This >request contains a field whose name is of zero-length. > >This causes albatross to barf in context.set_value(), line 323. I tried >putting in the following check and it seems to work: > > if len(name) == 0: > return > >Does anyone know if there is any harm in doing this? That seems reasonable (although I can't imagine how PayPal's behaviour in this regard could be called reasonable... 8-). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From djc at object-craft.com.au Fri Jan 24 15:41:03 2003 From: djc at object-craft.com.au (Dave Cole) Date: 24 Jan 2003 15:41:03 +1100 Subject: [albatross-users] Access to current/other page objects/modules In-Reply-To: <200301240004.LAA29572@lightning.itga.com.au> References: <200301240004.LAA29572@lightning.itga.com.au> Message-ID: > I thought of that, but you also have to add it the session so that > page refreshes work right. And it was still not clear how to access > this information in a way that says "place an HTML nabvar here". > > After a fair bit of experimenting I've come up with the following > solution that seems to work OK: > > - Do it with a new tag, as this will have access to the ctx for > generating html If we ever get around to updating our documentation we will have a new release... In the current code we have made the execution context available to the template expressions by doing this: class NamespaceMixin: def eval_expr(self, expr): self.locals.__ctx__ = self try: return eval(expr, self.__globals, self.locals.__dict__) finally: del self.locals.__ctx__ > - Alas, with the standard PageObjectMixin there is no way to get at > the map of names->page objects, because this is hidden by the > funky handling of the __page_objects name. No other method of the > mixin gives access to a page object without undesriable side > effects! Maybe we should add your extra method to PageObjectMixin. > class NavBar(EmptyTag): > ''' > The main guts of the navbar, based on the @nav_to & @description > page class members. > > Applications can subclass this and replace the to_html() and > format_link() functions to change the look of the navbar. They > will need to (re-) register the tag in the application code to get > the overriden version tho. > ''' > name = 'alx-navbar' > > def to_html(self, ctx): > ctx.write_content('\n
\n') > self.do_links(ctx) > ctx.write_content('\n') > > def do_links(self, ctx): > self.format_link(ctx, 'restart', 'Start Again') > if len(ctx.locals.back) > 0: > self.format_link(ctx, 'goback', 'Back') > pclass = ctx.app.page_object(ctx.locals.__page__) > for dest in pclass.nav_to: > dclass = ctx.app.page_object(dest) > desc = dclass.description > if desc.find("= 0: > ctx.push_content_trap() > Template(ctx, '', desc).to_html(ctx) > desc = ctx.pop_content_trap() > self.format_link(ctx, dest, desc) > > def format_link(self, ctx, href, desc): > ctx.write_content('%s  \n' % > (ctx.current_url(), href, desc)) The only thing you might want to do is turn dclass.description into a method which returns either a string or a template. This will allow you to cache templates in the dclass if you deploy on mod_python. for dest in pclass.nav_to: dclass = ctx.app.page_object(dest) desc = dclass.description() if isinstance(desc, Template): ctx.push_content_trap() desc.to_html(ctx) desc = ctx.pop_content_trap() self.format_link(ctx, dest, desc) - Dave -- http://www.object-craft.com.au From mike at daboyz.org Tue Jan 28 04:28:02 2003 From: mike at daboyz.org (Michael Barrett) Date: Mon, 27 Jan 2003 09:28:02 -0800 Subject: [albatross-users] SessionFileAppMixin has no session_age Message-ID: <20030127172802.GA73707@daboyz.org> Is there a technical reason why SessionFileAppMixin has no 'session_age' argument? I see it in SessionServerApp, and I'd like to use it in the File version. Just wondering if this has already been attempted and wasn't able to be easily done, or if it's just not being dealt with. Thanks. -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- From andrewm at object-craft.com.au Tue Jan 28 11:53:11 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Tue, 28 Jan 2003 11:53:11 +1100 Subject: [albatross-users] SessionFileAppMixin has no session_age In-Reply-To: Message from Michael Barrett of "Mon, 27 Jan 2003 09:28:02 -0800." <20030127172802.GA73707@daboyz.org> References: <20030127172802.GA73707@daboyz.org> Message-ID: <20030128005311.E94E43C1F4@coffee.object-craft.com.au> > Is there a technical reason why SessionFileAppMixin has no 'session_age' > argument? I see it in SessionServerApp, and I'd like to use it in the > File version. Just wondering if this has already been attempted and > wasn't able to be easily done, or if it's just not being dealt with. With the SessionServer sessions, you have a single session daemon, which can track sessions and clean out old ones, but with the SessionFile implementation, processes come and go, so I decided it should really be an external mechanism. Under Unix, you would probably just have a cron job that cleaned out any files with a modification date older than some age. Something like this would remove sessions older than a day: find /some/session/dir -mtime +1 | xargs rm What's probably needed is a python equivilent, something like (WARNING - UNTESTED): import os, time def session_clean(dir, age): """ Scan "dir" for files older than "age" seconds, and remove them """ expire_time = time.time() - age for filename in os.listdir(dir): filepath = os.path.join(dir, filename) if os.path.getmtime(filepath) < expire_time: os.unlink(filepath) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From mike at daboyz.org Tue Jan 28 19:07:22 2003 From: mike at daboyz.org (Michael Barrett) Date: Tue, 28 Jan 2003 00:07:22 -0800 Subject: [albatross-users] SessionFileAppMixin has no session_age In-Reply-To: <20030128005311.E94E43C1F4@coffee.object-craft.com.au> References: <20030127172802.GA73707@daboyz.org> <20030128005311.E94E43C1F4@coffee.object-craft.com.au> Message-ID: <20030128080722.GA81263@daboyz.org> I was actually looking for a way to make the sessions last longer. Wouldn't it just be a matter of turning up the expire time on the cookie? I pretty much want to make it so that if someone logs into my site, and clicks the 'remember me' button it does just that and lets them log in. Say it keeps the session for about a week. Any reason why that wouldn't be possible? On Tue, Jan 28, 2003 at 11:53:11AM +1100, Andrew McNamara wrote: > > Is there a technical reason why SessionFileAppMixin has no 'session_age' > > argument? I see it in SessionServerApp, and I'd like to use it in the > > File version. Just wondering if this has already been attempted and > > wasn't able to be easily done, or if it's just not being dealt with. > > With the SessionServer sessions, you have a single session daemon, which > can track sessions and clean out old ones, but with the SessionFile > implementation, processes come and go, so I decided it should really be > an external mechanism. > > Under Unix, you would probably just have a cron job that cleaned out any > files with a modification date older than some age. Something like this > would remove sessions older than a day: > > find /some/session/dir -mtime +1 | xargs rm > > What's probably needed is a python equivilent, something like (WARNING - > UNTESTED): > > import os, time > > def session_clean(dir, age): > """ > Scan "dir" for files older than "age" seconds, and remove them > """ > expire_time = time.time() - age > for filename in os.listdir(dir): > filepath = os.path.join(dir, filename) > if os.path.getmtime(filepath) < expire_time: > os.unlink(filepath) > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- From danb at champonline.com Wed Jan 29 03:39:21 2003 From: danb at champonline.com (Dan Bergan) Date: Tue, 28 Jan 2003 10:39:21 -0600 Subject: [albatross-users] add_session_vars() Message-ID: <027c01c2c6eb$cf1b1cf0$dd64a8c0@danbergan> Hello, I'm a newbie playing around with my first app and I'm having some problems with add_session_vars(). It seems like when I call ctx.add_session_vars('foo') from within page_display(), then the variable does not get added to the session. During later processing on another page, I try to access ctx.locals.foo and I get: Attribute Error. Vars instance has no attribute 'foo'. But, when I do the same call to add_session_vars() from page_process(), I have no problem. (And, yes, I am creating ctx.locals.foo.) Am I doing something wrong, or is this by design? By the way, I am using the RandomModularSessionApp. Thanks for your help! Dan Bergan From danb at champonline.com Wed Jan 29 05:48:23 2003 From: danb at champonline.com (Dan Bergan) Date: Tue, 28 Jan 2003 12:48:23 -0600 Subject: [albatross-users] add_session_vars() - ignore References: <027c01c2c6eb$cf1b1cf0$dd64a8c0@danbergan> Message-ID: <02b101c2c6fd$d5e3d920$dd64a8c0@danbergan> I think I have already figured out my problem. I don't believe it had anything to do with where I was calling add_session_vars(). I think it had more to do with not quite understanding the order of processing. I put in some logging statements and I found that my del_session_vars() wasn't being called when I thought it was being called! on to tackling more complex stuff... Dan Bergan ----- Original Message ----- From: "Dan Bergan" To: Sent: Tuesday, January 28, 2003 10:39 AM Subject: [albatross-users] add_session_vars() > Hello, > > I'm a newbie playing around with my first app and I'm having some problems with > add_session_vars(). It seems like when I call ctx.add_session_vars('foo') from > within page_display(), then the variable does not get added to the session. > During later processing on another page, I try to access ctx.locals.foo and I > get: > Attribute Error. Vars instance has no attribute 'foo'. > > But, when I do the same call to add_session_vars() from page_process(), I have > no problem. (And, yes, I am creating ctx.locals.foo.) Am I doing something > wrong, or is this by design? > > By the way, I am using the RandomModularSessionApp. > > Thanks for your help! > Dan Bergan > > > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users > From andrewm at object-craft.com.au Wed Jan 29 09:52:18 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 29 Jan 2003 09:52:18 +1100 Subject: [albatross-users] SessionFileAppMixin has no session_age In-Reply-To: Message from Michael Barrett of "Tue, 28 Jan 2003 00:07:22 -0800." <20030128080722.GA81263@daboyz.org> References: <20030127172802.GA73707@daboyz.org> <20030128005311.E94E43C1F4@coffee.object-craft.com.au> <20030128080722.GA81263@daboyz.org> Message-ID: <20030128225218.E800D3C1F4@coffee.object-craft.com.au> >I was actually looking for a way to make the sessions last longer. >Wouldn't it just be a matter of turning up the expire time on the cookie? > >I pretty much want to make it so that if someone logs into my site, and >clicks the 'remember me' button it does just that and lets them log in. >Say it keeps the session for about a week. Ah! Currently we set no "Max-Age" on the cookie, so it lasts until the user closes the browser. So, yes, setting an explicit Max-Age would help in your application, and the SessionFile mixin in perfect, as the sessions are persistent (the SessionServer's sessions are stored in memory, so if the server is restarted, they are lost - this will be rectified one day, but should be considered a "feature" until them... 8-). The problem is, we don't expose the cookie machinery to the application. If you look in sessionfile.py, SessionFileContextMixin, you'll see how we're setting the cookie. You could sub-class and replace load_session with a version that sets the max-age on the resulting cookie. We need to put some thought into making the cookie available to the developer. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From mike at daboyz.org Wed Jan 29 19:36:31 2003 From: mike at daboyz.org (Michael Barrett) Date: Wed, 29 Jan 2003 00:36:31 -0800 Subject: [albatross-users] SessionFileAppMixin has no session_age In-Reply-To: <20030128225218.E800D3C1F4@coffee.object-craft.com.au> References: <20030127172802.GA73707@daboyz.org> <20030128005311.E94E43C1F4@coffee.object-craft.com.au> <20030128080722.GA81263@daboyz.org> <20030128225218.E800D3C1F4@coffee.object-craft.com.au> Message-ID: <20030129083631.GA64467@daboyz.org> Ok, I'm not sure if this is kosher, but I went ahead and edited the sessionfile.py to have the feature I wanted. I've gone ahead and attached a diff of what I did. I think the way I did it won't break any other uses of the classes I edited. Anyways, have a look and let me know if you can think of any problems with this. Thanks Andrew for helping me pin down where the 'problem' was. ###### Begin Diff 13a14 > import time 28c29 < def __init__(self): --- > def __init__(self, session_ttl=None): 30a32 > self.__session_ttl = session_ttl 62a65,66 > if self.__session_ttl: > c[self.app.ses_appid()]['expires'] = time.strftime('%a, %d-%b-%Y %H:%M:%S GMT',time.gmtime(time.time()+self.__session_ttl)) 148c152 < def __init__(self, app): --- > def __init__(self, app, session_ttl=None): 151c155 < SessionFileContextMixin.__init__(self) --- > SessionFileContextMixin.__init__(self, session_ttl) #### End DIFF On Wed, Jan 29, 2003 at 09:52:18AM +1100, Andrew McNamara wrote: > >I was actually looking for a way to make the sessions last longer. > >Wouldn't it just be a matter of turning up the expire time on the cookie? > > > >I pretty much want to make it so that if someone logs into my site, and > >clicks the 'remember me' button it does just that and lets them log in. > >Say it keeps the session for about a week. > > Ah! Currently we set no "Max-Age" on the cookie, so it lasts until the > user closes the browser. So, yes, setting an explicit Max-Age would help > in your application, and the SessionFile mixin in perfect, as the sessions > are persistent (the SessionServer's sessions are stored in memory, so if > the server is restarted, they are lost - this will be rectified one day, > but should be considered a "feature" until them... 8-). > > The problem is, we don't expose the cookie machinery to the application. If > you look in sessionfile.py, SessionFileContextMixin, you'll see how we're > setting the cookie. You could sub-class and replace load_session with a > version that sets the max-age on the resulting cookie. > > We need to put some thought into making the cookie available to the > developer. > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- From andrewm at object-craft.com.au Wed Jan 29 21:10:18 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Wed, 29 Jan 2003 21:10:18 +1100 Subject: [albatross-users] SessionFileAppMixin has no session_age In-Reply-To: Message from Michael Barrett of "Wed, 29 Jan 2003 00:36:31 -0800." <20030129083631.GA64467@daboyz.org> References: <20030127172802.GA73707@daboyz.org> <20030128005311.E94E43C1F4@coffee.object-craft.com.au> <20030128080722.GA81263@daboyz.org> <20030128225218.E800D3C1F4@coffee.object-craft.com.au> <20030129083631.GA64467@daboyz.org> Message-ID: <20030129101019.02E4B3C1F4@coffee.object-craft.com.au> >> if self.__session_ttl: >> c[self.app.ses_appid()]['expires'] = time.strftime('%a, %d-%b-%Y %H:%M:%S GMT',time.gmtime(time.time()+self.__session_ttl)) I'm certainly no cookie expert, but the RFC (2109) suggests that Expires is the "old way" and that Max-Age should be used instead (which gives the cookie age in seconds). I don't know if there are any problems either way, although people are forever misparsing date strings, so the Max-Age makes more sense. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From mike at daboyz.org Thu Jan 30 05:21:11 2003 From: mike at daboyz.org (Michael Barrett) Date: Wed, 29 Jan 2003 10:21:11 -0800 Subject: [albatross-users] SessionFileAppMixin has no session_age In-Reply-To: <20030129101019.02E4B3C1F4@coffee.object-craft.com.au> References: <20030127172802.GA73707@daboyz.org> <20030128005311.E94E43C1F4@coffee.object-craft.com.au> <20030128080722.GA81263@daboyz.org> <20030128225218.E800D3C1F4@coffee.object-craft.com.au> <20030129083631.GA64467@daboyz.org> <20030129101019.02E4B3C1F4@coffee.object-craft.com.au> Message-ID: <20030129182111.GA55147@daboyz.org> You're more of a cookie expert than myself it seems :) Anyways, I changed the code to use this new RFC instead of the old one I was looking at. Makes it that much cleaner since I don't have to use the time module at all anymore. ### Start DIFF 28c28 < def __init__(self): --- > def __init__(self, session_ttl=None): 30a31 > self.__session_ttl = session_ttl 62a64,65 > if self.__session_ttl: > c[self.app.ses_appid()]['Max-Age'] = self.__session_ttl 148c151 < def __init__(self, app): --- > def __init__(self, app, session_ttl=None): 151c154 < SessionFileContextMixin.__init__(self) --- > SessionFileContextMixin.__init__(self, session_ttl) ### End DIFF Thanks again for your help Andrew. On Wed, Jan 29, 2003 at 09:10:18PM +1100, Andrew McNamara wrote: > >> if self.__session_ttl: > >> c[self.app.ses_appid()]['expires'] = time.strftime('%a, %d-%b-%Y %H:%M:%S GMT',time.gmtime(time.time()+self.__session_ttl)) > > I'm certainly no cookie expert, but the RFC (2109) suggests that Expires > is the "old way" and that Max-Age should be used instead (which gives > the cookie age in seconds). I don't know if there are any problems either > way, although people are forever misparsing date strings, so the Max-Age > makes more sense. > > -- > Andrew McNamara, Senior Developer, Object Craft > http://www.object-craft.com.au/ > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- From andrewm at object-craft.com.au Thu Jan 30 13:01:55 2003 From: andrewm at object-craft.com.au (Andrew McNamara) Date: Thu, 30 Jan 2003 13:01:55 +1100 Subject: [albatross-users] Re: masking email addresses in archives / do not let archives be crawled In-Reply-To: Message from "Axel Kollmorgen" of "Thu, 30 Jan 2003 01:08:44 BST." <028901c2c7f4$6202bf10$0f0a90d4@what.do.you.care> References: <028901c2c7f4$6202bf10$0f0a90d4@what.do.you.care> Message-ID: <20030130020155.8961F3C32B@coffee.object-craft.com.au> >i just found that a) the list is indexed by google and that b) email >addresses appear unmasked in the archives. as this is quite spam-prone, >and as i don't like to be spammed, i would really like to ask you to > >a) mask email addresses in archives so that they cannot be automatically >extracted. this is easily done by setting ARCHIVER_OBSCURES_EMAILADDRS = >1 in mm_cfg.py [1] > >and / or > >b) do not let robots crawl the archives. if this is done to make them >searchable - there are external search tools and internal patches that >are easy to apply available [2] Thanks for picking this up, and sorry about the inconvenience - I've implemented option A (searching the archives is generally useful) and rebuilt the archives. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ From mike at daboyz.org Thu Jan 30 20:15:06 2003 From: mike at daboyz.org (Michael Barrett) Date: Thu, 30 Jan 2003 01:15:06 -0800 Subject: [albatross-users] al-values inside al-input Message-ID: <20030130091506.GA62395@daboyz.org> Hi, I currently have this bit of code in one of my templates: It doesn't seem to work. Instead of displaying the value of 'username' inside the field, it instead displayes . Is there anyway to work around this? It worked before when I used regular input tags, rather than al-input, but I'd rather use al-input. Thanks. -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- From houston at mediapulse.com Fri Jan 31 00:24:56 2003 From: houston at mediapulse.com (Daryl Houston) Date: Thu, 30 Jan 2003 08:24:56 -0500 Subject: [albatross-users] al-values inside al-input Message-ID: Try: D ===================== Daryl L. L. Houston Software Developer/E-commerce Specialist Mediapulse, Inc. 800.380.4514 865-482-4455 ext. 21 -----Original Message----- From: Michael Barrett [mailto:mike at daboyz.org] Sent: Thursday, January 30, 2003 4:15 AM To: albatross-users at object-craft.com.au Subject: [albatross-users] al-values inside al-input Hi, I currently have this bit of code in one of my templates: It doesn't seem to work. Instead of displaying the value of 'username' inside the field, it instead displayes . Is there anyway to work around this? It worked before when I used regular input tags, rather than al-input, but I'd rather use al-input. Thanks. -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- _______________________________________________ Albatross-users mailing list Albatross-users at object-craft.com.au https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users From mike at daboyz.org Fri Jan 31 04:07:29 2003 From: mike at daboyz.org (Michael Barrett) Date: Thu, 30 Jan 2003 09:07:29 -0800 Subject: [albatross-users] al-values inside al-input In-Reply-To: References: Message-ID: <20030130170729.GB34138@daboyz.org> Thanks for everyone's help on this. On Thu, Jan 30, 2003 at 08:24:56AM -0500, Daryl Houston wrote: > Try: > > > > D > > > ===================== > Daryl L. L. Houston > Software Developer/E-commerce Specialist > Mediapulse, Inc. > 800.380.4514 > 865-482-4455 ext. 21 > > > > > > > -----Original Message----- > From: Michael Barrett [mailto:mike at daboyz.org] > Sent: Thursday, January 30, 2003 4:15 AM > To: albatross-users at object-craft.com.au > Subject: [albatross-users] al-values inside al-input > > > Hi, I currently have this bit of code in one of my templates: > > > > It doesn't seem to work. Instead of displaying the value of > 'username' inside the field, it instead displayes expr='username'>. Is there anyway to work around this? It worked > before when I used regular input tags, rather than al-input, but I'd > rather use al-input. > > Thanks. > -- > > ________________________________________________________________________ > Mike Barrett | "I used to read, now I go to raves." > mike at daboyz.org | -- Random MUNI Rider, speaking > www.daboyz.org | to my friend Allison. > > ------------------------+----------------------------------------------- > _______________________________________________ > Albatross-users mailing list Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users > _______________________________________________ > Albatross-users mailing list > Albatross-users at object-craft.com.au > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users -- ________________________________________________________________________ Mike Barrett | "I used to read, now I go to raves." mike at daboyz.org | -- Random MUNI Rider, speaking www.daboyz.org | to my friend Allison. ------------------------+----------------------------------------------- From djc at object-craft.com.au Fri Jan 31 10:16:17 2003 From: djc at object-craft.com.au (Dave Cole) Date: 31 Jan 2003 10:16:17 +1100 Subject: [albatross-users] al-values inside al-input In-Reply-To: <20030130091506.GA62395@daboyz.org> References: <20030130091506.GA62395@daboyz.org> Message-ID: > Hi, I currently have this bit of code in one of my templates: > > It doesn't seem to work. Instead of displaying the value of > 'username' inside the field, it instead displayes expr='username'>. Is there anyway to work around this? It worked > before when I used regular input tags, rather than al-input, but I'd > rather use al-input. The problem is that you cannot use Albatross tags to construct other Albatross tags. Why? That was a design decision which was taken to reduce the complexity of the template parser and template execution code. Was that a good decision? I don't really know. It was just one of many decisions that was made when building Albatross. I am not even sure that fixing this limitation would be a good thing. Imagine the nasty templates you could build if the limitation were removed. - Dave -- http://www.object-craft.com.au From gnb at itga.com.au Fri Jan 31 10:28:32 2003 From: gnb at itga.com.au (Gregory Bond) Date: Fri, 31 Jan 2003 10:28:32 +1100 Subject: [albatross-users] al-values inside al-input In-Reply-To: Your message of 31 Jan 2003 10:16:17 +1100. Message-ID: <200301302328.KAA07802@lightning.itga.com.au> > The problem is that you cannot use Albatross tags to construct other > Albatross tags. I wonder if it's possible to automatically support a fooexpr attribute for every foo attribute? As I mentioned to Mike, most times you need to do this there is a fooexpr you can use, but not always.... From neel at mediapulse.com Fri Jan 31 10:29:46 2003 From: neel at mediapulse.com (Michael C. Neel) Date: Thu, 30 Jan 2003 18:29:46 -0500 Subject: [albatross-users] al-values inside al-input Message-ID: Remember you are not required to use the al-tags, I do find that sometimes a standard tag can do something better than trying to force the toolkit to do it. For example have a form submit to anther albatross form (i.e. new page object) is cumbersom with a forced action tag in al-form, but not with the normal form tag. If you really want the below, you could just use a normal input tag: Although the using of the expr argument is likely the best (allthough if username is defined in ctx.locals, you don't even need that). I think the choice to not allow nesting al tags is a good one, this is not perl after all. Mike -----Original Message----- From: Dave Cole [mailto:djc at object-craft.com.au] Sent: Thursday, January 30, 2003 6:16 PM To: Michael Barrett Cc: albatross-users at object-craft.com.au Subject: Re: [albatross-users] al-values inside al-input > Hi, I currently have this bit of code in one of my templates: > > It doesn't seem to work. Instead of displaying the value of > 'username' inside the field, it instead displayes expr='username'>. Is there anyway to work around this? It worked > before when I used regular input tags, rather than al-input, but I'd > rather use al-input. The problem is that you cannot use Albatross tags to construct other Albatross tags. Why? That was a design decision which was taken to reduce the complexity of the template parser and template execution code. Was that a good decision? I don't really know. It was just one of many decisions that was made when building Albatross. I am not even sure that fixing this limitation would be a good thing. Imagine the nasty templates you could build if the limitation were removed. - Dave -- http://www.object-craft.com.au _______________________________________________ Albatross-users mailing list Albatross-users at object-craft.com.au https://www.object-craft.com.au/cgi-bin/mailman/listinfo/albatross-users From djc at object-craft.com.au Fri Jan 31 10:50:28 2003 From: djc at object-craft.com.au (Dave Cole) Date: 31 Jan 2003 10:50:28 +1100 Subject: [albatross-users] al-values inside al-input In-Reply-To: <200301302328.KAA07802@lightning.itga.com.au> References: <200301302328.KAA07802@lightning.itga.com.au> Message-ID: >>>>> "Gregory" == Gregory Bond writes: >> The problem is that you cannot use Albatross tags to construct >> other Albatross tags. Gregory> I wonder if it's possible to automatically support a fooexpr Gregory> attribute for every foo attribute? As I mentioned to Mike, Gregory> most times you need to do this there is a fooexpr you can Gregory> use, but not always.... Andrew and I have been tossing around ideas along these lines for a while now (probably over a year). We are on our second major variation now. We still haven't decided whether it would be a good idea or not. Short description of the way the parser works:: The parser is regex based. It looks for tags which start with 'blah blah into your templates. The parser would see the ' blah blah blah blah * What do we do when the enclosed expression returns None? I say we just suppress the attribute in the output. So the above would be: blah blah blah blah rather than: : or: : or: : - Dave -- http://www.object-craft.com.au From gnb at itga.com.au Fri Jan 31 11:03:47 2003 From: gnb at itga.com.au (Gregory Bond) Date: Fri, 31 Jan 2003 11:03:47 +1100 Subject: [albatross-users] al-values inside al-input In-Reply-To: Your message of 31 Jan 2003 10:50:28 +1100. Message-ID: <200301310003.LAA19221@lightning.itga.com.au> > * Implement a generic tag class to handle all tags that are not > currently Albatross tags. > * Inside Albatross tags we would implement functionality which > processes any attribute which is prefixed by 'al-' as a Python > expression. Whoa, that's much more ambitious than I had in mind.... and it would probably change the way things are done with albatross templates quite dramatically. I fear for backwards compatibility in this case. I was considering something a bit more modest: - Each al- tag class already knows what attributes they are interested in. - The tag classes use has_attrib() and get_attrib() to access them - These two functions (and others like write_attribs_except()) can be changed to look up "foo", and if that doesn't exist, look up & evaluate "fooexpr". - This could be pretty much backward compatible to applications, tho the tag classes would need a bit of work. Leave alone the expr attributes (al-value et al), remove the special case handling of nameexpr, valueexpr etc (lots of places) and let the default mechanism kick in. Greg. From djc at object-craft.com.au Fri Jan 31 11:37:56 2003 From: djc at object-craft.com.au (Dave Cole) Date: 31 Jan 2003 11:37:56 +1100 Subject: [albatross-users] al-values inside al-input In-Reply-To: <200301310003.LAA19221@lightning.itga.com.au> References: <200301310003.LAA19221@lightning.itga.com.au> Message-ID: >>>>> "Gregory" == Gregory Bond writes: >> * Implement a generic tag class to handle all tags that are not >> currently Albatross tags. >> * Inside Albatross tags we would implement functionality which >> processes any attribute which is prefixed by 'al-' as a Python >> expression. Gregory> Whoa, that's much more ambitious than I had in mind.... and Gregory> it would probably change the way things are done with Gregory> albatross templates quite dramatically. I fear for backwards Gregory> compatibility in this case. Where the current nameexpr, valueexpr, ... attributes are identical to the behaviour proposed by the al- attributes, the current attributes would be retained for backwards compatibility. By adding the new behaviour we would not be breaking anything which currently exists, we would just be adding a more consistent scheme for doing the same thing while providing the capability to any other tag. Gregory> I was considering something a bit more modest: Gregory> - Each al- tag class already knows what attributes they are Gregory> interested in. Gregory> - The tag classes use has_attrib() and get_attrib() to Gregory> access them Gregory> - These two functions (and others like Gregory> write_attribs_except()) can be changed to look up "foo", and Gregory> if that doesn't exist, look up & evaluate "fooexpr". Gregory> - This could be pretty much backward compatible to Gregory> applications, tho the tag classes would need a bit of work. Gregory> Leave alone the expr attributes (al-value et al), remove the Gregory> special case handling of nameexpr, valueexpr etc (lots of Gregory> places) and let the default mechanism kick in. You might be right. We have not done much more than speculate on a scheme which might reduce the current complexity of templates and their collection of individually handled attributes. The code to implement the generic stuff might be too nasty to be worth it. - Dave -- http://www.object-craft.com.au