[Zope3-dev] Re: Mini proposal: simpify presentation-lookup api

[Jim Fulton]

Casey Duncan wrote:
> On Thu, 01 Apr 2004 14:52:45 -0500
> Jim Fulton <jim at zope.com> wrote:
> 
> 
>>Tres Seaver wrote:
>>
>>>Jim Fulton wrote:
> 
> [..]
> 
>>>-1 to 'objectsandrequest';  if the request is special, and required,
>>>and must be in a specific position, then it should not be "lumped"
>>>with the objects. 
>>
>>That's a reasonable argument ...
> 
> 
> I agree, I think it's unintuitive that the request gets thrown in there
> *and* it must be last.
>  
> 
>> > Why not:
>>
>>>    def getPresenter(request, interface, objects=(), name='',
>>>                     context=None):
>>>        """..."""
>>>
>>>Because presenters are *always* adapting requests to an interface,
>>>but *may* take into account other objects, and *may* have a name,
>>>this seems cleaner.  We could move the interface to be first, if
>>>that makes it clearer.
>>
>>I prefer either what I proposed or:
>>
>>     def getPresenter(objects, request, interface, name='',
>>                      context=None):
> 
> 
> This seems reasonable, although Tres' interface makes it a tad bit
> clearer that objects is a sequence and may be empty. The latter is the
> key distinction there. I think this is ugly::
>  
>   getPresenter((), request, interface)
> 
> compared to::
> 
>   getPresenter(request, interface)
> 
> Granted I don't know how common the latter will be in practice.
>  
> 
>>because:
>>
>>- We rarely have no objects
> 
> 
> Apparently not very.

How so? In what way is it apparent.  Application (presentation) code hardly every
looks up resources.

> 
>>- We adapt the objects first -- that is, objects have more impact
>>   on adapter selection than does the request
> 
> 
> Ok, but it does seem to muddy up the case where there aren't any
> objects.

Not as roginally proposed.

 > Since objects is optional, it seems best that it be an optional
> argument regardless of how that affects the order. Otherwise that is not
> immediately clear.

Optional or empty, take your pick. I don't like "optional', because it forces
me to put the rgument in the wrong place.

> 
>>- I want to make this look like an adapter lookup:
>>
>>     def getMultiAdapter(objects, interface, name='', context=None)
>>
>>It's most common to have 1 object, other than the request.  Lumping
>>the object with the request avoids:
>>
>>     view = getPresenter((x, ), request, someinterface):
>>
>>I like:
>>
>>     view = getPresentation((x, request), someinterface)
>>
>>because it's alot like:
>>
>>     adapter = getMultiAdapter((x, y), someinterface)
> 
> 
> I sense that connection may not be as valuable to more casual users.

We're talking about developers. Most of the time they are making these
calls, they are getting subviews that provide a particular interface. They
*should* be thinking in terms of adaptation.

 > If
> the common case is a single object, I propose two methods::
> 
>     def getPresenter(object, request, interface, name='', context=None):
> 
> and 
> 
>     def getPresenterMulti(objects, request, interface, name='',
> context=None):

That starts get to back to what we have now.

I really prefer what I proposed.

> Names notwithstanding.
> 
> 
>>Note that we can't use regular adapters here because presentors are
>>"skinned", meaning we take skinning into account when we look them up.
> 
> 
> Why can't there just be presentation adapters that know about skinning
> instead of a different-but-similar concept/API?

Because the adapters dont know about skins, any more than skin methods do
in the CMF. The presentation service gets a skin, figures out what layers it
has and the searches the layers, just like in the CMF (except that there are
far fewer layers). It's all about the lookup mechanism.  The things being looked
up don't care.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org