[Zope3-dev] Re: form action

[Shane Hathaway]

Guido van Rossum wrote:
> [Steve A]
>>Perhaps there's a way for the existing JobBoardTraverser to tell the 
>>Request what view it has chosen for its Job, so that the Request can 
>>generate an appropriate base?
>>
> 
> Who knows?
> 
> I'm hoping that we'll get default views.

You know, this reminds me of the meeting we (Guido, Tim, Jim, Todd, 
myself, and maybe one or two more) had more than a year ago (I think it 
was in Falls Church) about the design of the new page templates.

Everything was basically clear except for TALES namespaces.  We couldn't 
figure out how to balance explicit and implicit names.  On the implicit 
extreme was DTML-like behavior.  On the explicit extreme was requiring 
every expression to be a path expression starting from a set of standard 
names that could not be changed.  DTML-like implicitness was not an 
option, so we assumed we had to go the very explicit route.

Then you, Guido, stepped in and explained a happy medium.  Make page 
templates have local and global namespaces, just like Python.  The 
global namespace would have "built-in" names like "here" and "request"; 
the local namespace would be empty until you define a variable.  All 
name lookups would look in locals then globals.  We weren't sure at 
first that this solution truly escaped the problems that DTML namespaces 
had, but we went ahead with it anyway.  I'm sure glad we did it this 
way--thank you.

So now we have a similar problem with browser URLs. 
http://localhost:8080/joblist takes you to a job list object, but when 
you traverse past it, how can the server be sure of what you're asking for?

Let's say the summary view is the default view of a job list and when 
you visit http://localhost:8080/joblist/ , you see the default method of 
the summary view.  Let's say the summary view also has a method called 
"edit", and there is also a view of job boards registered under the name 
"edit".  How do you distinguish them?  Maybe we just say that's not 
really a problem?

A Python parallel exists--a local name can shadow a global name.  In 
practice, though, names like "type" and "str" frequently conflict, but 
it's usually not a problem.  If it is, you can just change the name of 
the local variable and forget about it.  Locals will never magically 
become globals in future versions of Python.

So maybe we should search the methods of the default view first, then 
search for views?  That would be somewhat similar to locals and globals.

Shane