AW: [Zope-dev] Doc strings of IContentProvider

2007-11-11 Thread Roger Ineichen
> Betreff: [Zope-dev] Doc strings of IContentProvider

Hi Thomas

> While trying to implement the outcome of that zope3-dev 
> discussion on pagelets being content providers, I noticed 
> that the doc strings for IContentProvider talk about how 
> content providers are to be looked up:
> They specify (informally) that content providers are 
> discriminated by context, request, and view. Also, the 
> documentation of the __parent__ attribute states that the 
> parent is a view.
>
> To my understanding, the interface should only specify how an 
> object behaves, not how it is obtained. Moreover, I suspect 
> that it might be enough to require the presence of a parent 
> for the sake of the security context (as stated in the doc 
> string) without specifying that it must be a view. The way it 
> is now, a view whose parent is something other than a view 
> can never be its own content provider. As an example, this 
> includes pagelets. Unless this is a conscious design choice, 
> IMHO the interface's documentation should be worded more liberally.

The IContentProvider interfaces is a marker interface which 
describes what a component must support that it get collected
by the Tales Expression. We didn't define the __init__ signature
because we didn't know if there are other usecases which will
need different adaption later and it's also not common to
restrict the __init__. But we should do that if we change 
something.

This means the IContentProvider interface is not designed 
for general porpose. It's the provide interface for the TALES
expression collection concept!

e.g.
provider = zope.component.queryMultiAdapter(
(context, request, view), interfaces.IContentProvider, name)

Every other interpretation of IContentProvider is irrelevant
or just something that should be defined with another interface.


The IPagelet is not a content provider.
A Pagelet is a enhanced BrowserPage pattern which offers
support for a layout and content interface by useing
the adapter registry instead of the use-macro pattern.

And it uses the provider pattern for doing a recursive
call for calling the layout template from the renderer.

The PageletRenderer provides the IContentProvider 
interfaces and the IPagelet provides the IBrowserPage
interface.

I'm not really sure what you are trying to do or improve.

I'm fine if you like to improve the documentation, but
note, the IContentProvider is there for to describe
what a object must provide that the TALES Expression
concept works. Of corse the IContentProvider can be used 
without the TALES expression concept. But the TALES expression 
does not work with out the IContentProvider interface.

This means any change to IContentProvider must still be 
valid for the TALES exrpression *implementation*.

I hope that helps to understand our motivation at the
time we implemented this.

Thomas,
Any new ideas are welcome, the description above doesn't
mean we can't improve something.

Regards
Roger ineichen

> --
> Thomas
> 
> 
> 
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
> 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Doc strings of IContentProvider

2007-11-11 Thread Fred Drake
On Nov 11, 2007 1:34 PM, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> To my understanding, the interface should only specify how an object
> behaves, not how it is obtained.

That's my understanding as well.

The interface should express how a provider of the interface behaves;
larger pictures should be documented in README.txt or other
documentation files.  In some cases, a "this is how it work" might be
appropriate, and in others it may be more reasonable to describe
"here's how it was designed to work."  But both of those go beyond the
interfaces themselves.

> Moreover, I suspect that it might be
> enough to require the presence of a parent for the sake of the security
> context (as stated in the doc string) without specifying that it must be a
> view. The way it is now, a view whose parent is something other than a
> view can never be its own content provider. As an example, this includes
> pagelets. Unless this is a conscious design choice, IMHO the interface's
> documentation should be worded more liberally.

I'm not knowledgeable enough about the pagelet and viewlet models to
have a meaningful opinion on this.


  -Fred

-- 
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Doc strings of IContentProvider

2007-11-11 Thread Thomas Lotze
While trying to implement the outcome of that zope3-dev discussion on
pagelets being content providers, I noticed that the doc strings for
IContentProvider talk about how content providers are to be looked up:
They specify (informally) that content providers are discriminated by
context, request, and view. Also, the documentation of the __parent__
attribute states that the parent is a view.

To my understanding, the interface should only specify how an object
behaves, not how it is obtained. Moreover, I suspect that it might be
enough to require the presence of a parent for the sake of the security
context (as stated in the doc string) without specifying that it must be a
view. The way it is now, a view whose parent is something other than a
view can never be its own content provider. As an example, this includes
pagelets. Unless this is a conscious design choice, IMHO the interface's
documentation should be worded more liberally.

-- 
Thomas



___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )