From: Paul B. <pa...@in...> - 2000-12-18 11:34:25
|
Geoff Talvola wrote: > Chuck Esterbrook wrote: > > > On the one hand, using _action_Foo_ eliminates the need to map button > > titles to method names. On the other hand, this means that Page must > > always do this: > > > > for key in self.request().fields().keys(): > > if key.startswith('_action_'): > > # handle action > > > > e.g., every request requires the construction of keys() and a linear > > search through them to determine if this request is using the "action > > feature". Mandatory linear searches scare me. > > Couldn't you write it so it only had to do a linear search on the > results of actions(); i.e. > > for action in self.actions(): > if request.hasField('_action_%s' % action): > # handle action > > That way you only pay a penalty proportional to the number of actions > defined on your page. This would surely be acceptable, since you aren't going to want to know about unhandled _action_*_ inputs anyway. As for the linear complexity aspect, I don't really think that this would be a problem in practice. Whilst people may have hundreds or even thousands of fields on a form, they are less likely to have hundreds or even thousands of submit buttons, and even if they did, I wouldn't necessarily envisage a massive performance hit. > > It's actually a bummer. I wish <input type=submit> had a "title=" > > argument. Yes, this was a particularly badly thought out aspect of the HTML specification. > > I guess we could avoid the linear search if we tapped into the > > translation of the query string to a dictionary. I don't know how easy > > that is; we're using the cgi module. > > I say, make it as easy as possible for the developer; optimization can > come later if necessary. This makes actions easier to implement and > more understandable in my opinion, so I say let's do it. I agree. If we can't have a common set of action names, then in the publication of a "document" in a number of different languages, the developer is required to maintain a dictionary mapping action labels to action names in addition to the numerous editions of the document. This clearly introduces some "fragility" into the system, since maintenance of each edition involves the adjustment of more than one component in the system, namely the source code and the document texts. I don't see why adding a new language to those already supported should necessarily require modification of the source code as well as the creation of a new edition of the document. Regards, Paul |