The current $placeholder syntax for CGI parameters is more verbose than it could be. Currently, you'd do (untested):
$request.field("fieldName")
The normal response would be, "Extract the field in Python code and put the value in a searchList variable." However, the BatchHandling proposal wants to get a certain parameter from within the template, and that's clearly where the code belongs, in order to keep all batch-related info together.
I'm not sure what a better syntax would be. Something like $field.fieldName would be cleanest. But what to name the top-level method?
There are other considerations. If we make a special method for $request.field, people will wonder why $request.fields, .hasField, .value ..., .cookie ..., .session don't get a similar privilege. My response is that $field would be called a lot more often. But obviously, other web developers may call one of the other methods more often.
I'm not necessarily sure we should provide a special method for getting CGI parameters, just looking for more discussion.
-- MikeOrr - 13 Nov 2001
This is one of the places where using Cheetah in Webware will be significantly different than using it in other environments. So if we do create a standard Cheetah way of doing it, then it might be transferable to a CGI environment, etc.
Something which I've wanted, but Chuck has not wanted, is for more namespaces -- not just from Cheetah, but also from Python. Query string fields are one case, and there are others.
So I'd say that we don't have to implement hasField, etc., because Python already implements all of these. That is, by using the standard dictionary interface, you have everything you need: .has_key, .get, assignment, deletion. Attribute access can be a shortcut when you have hardwired field names (but doesn't have the full flexibility of HTML/HTTP, while the dictionary interface does).
All this stuff would be implemented in the servlet mixin, so it wouldn't sully the rest of Cheetah with HTTP/HTML/Webware notions.
-- IanBicking - 13 Nov 2001
How about a compiler setting (or Template constructor argument) legalFields (list of strings)? Then in the constructor, if legalFields is not empty, add a new dictionary to the searchList containing those field values, copied from self.request.field(theFieldName, None). If Webware is not available, set all fields to None.
Advantages: * Less clutter in the template. To look up a field, simply: $field. * None means missing field. Real field values are strings. None is automatically converted to '' on output. If you need to map None to 0: $getVar($theField, 0). * Unlike adding self.request.fields() to the searchList, this strategy prevents the security hole of the user accidentally/intentionally overriding an important attribute/method by specifying an illegal field name. * The template can still do $request.field(theField) if it wishes, to do special processing (e.g., verify file size before file upload).
This concept could also be extended to session and cookie values.
-- MikeOrr - 29 Nov 2001