[Zope3-dev] implementing title_or_id

[Garrett Smith]

> -----Original Message-----
> From: Steve Alexander
> Sent: Friday, April 11, 2003 8:36 AM
=20
> Look at how the ISized adapters work.
>=20
> ./src/zope/app/interfaces/size.py
> ./src/zope/app/container/size.py
> ./src/zope/app/size.py

This is a great (and practical) example of adapters. I have a note to
use it in some docs.

> > - When "plugging" in new functionality meant to be used only in page
> > templates, is the preferred approah to use a view, as in option 2
above?
>=20
> Why should this be used only in page templates?

This is an artificial constraint...

I'm coming at the problem from a web designer's perspective (not sure of
the formal actor name here). Taking ISized, for example, as a web
designer, I might want to change the size formatting (or even
implementation) of an object type's size. But I don't want to replace
any existing functionality -- i.e. I'm not interested in more/different
implementations of ISized, just in adding something new. Here's what I'd
expect to have to do:

 - create a Python module that implements the functionality in some form

 - modify my project's configure.zcml to "hook up" some
function/adapter/whatever so that I can use the new functionality in
page templates

 - use the new functionality in page templates

I've done exactly this with the context_utils view.

Since this problem is really meant to target web designers, I
constrained the use to page templates. Under this scenario, my thinking
is that 'view' is more appropriate than 'adapter', per MVC convention.

> This spelling of "getting a view on an object" is deprecated:
>=20
>  >   2 - tal:content=3D"views/context_utils/title_or_id"
>=20
> Instead, use this spelling:
>=20
>  >   2 - tal:content=3D"context/@@/context_utils/title_or_id"

Just curious...how is deprecation being handled in Zope 3 at this stage?
I would have expected this to have been pulled altogether, given the
early stage of development. If there's a fair amount of deprecation, is
there a good way to spot/avoid it?

> If something is like an adapter, but depends on the request and the=20
> object, then use a view for it.
> In this case, I'm not sure that it depends on the request,=20
> only on the object. So, use an adapter for it.

Is there more of an "is a" way to differentiate the use of views and
adapters? E.g. does use of 'request' imply a UI (or externally
interfacing) component and therefore a view?

> It would be great if these things were documented :-/

I'm compiling all of these answer and will convene at some point with
Stephan to figure out how best to publish them.

-- Garrett Smith