[Zope3-Users] Alternatives to macros

Stephan Richter srichter at cosmos.phy.tufts.edu
Thu Sep 14 06:46:56 EDT 2006


On Wednesday 13 September 2006 16:58, ksmith93940-dev at yahoo.com wrote:
> I'm investigating alternatives to macros, the following appears to work,
> but does anyone see anything particularly wrong or limiting with this
> implementation?

For the "simpler" case, this implementation looks good. What Juergen does is 
to make the content a viewlet manager/content provider as well. The 
disadvantage is that you have to write two classes for each page, namely the 
view and the content viewlet. The big advantage, on the other hand, is that 
we can (a) reuse any view component, and (b) have multiple viewlets 
contribute to the content.

Here is an example at how it would look for us (ignoring the nav stuff, which 
is ok):


base.py
---------

class BaseView(object):
    """The base view for all views in my project."""
    interface.implements(IMyProjectView)

    __call__ = ViewPageTemplateFile('master.pt')

class MainView(BaseView):
    """The main view used for the main index page."""
    interface.implements(IMyProjectMain)


search.py
----------

class SearchView(BrowserView):
    # Often a special interface is needed for viewlet registrations
    # We might not need this, since you can register stuff for a class, 
    # though there are cases we found where it did not work.
    implements(ISearchView)

class SearchViewlet(Viewlet):
    ...

configure.zcml
-----------------

<page
    name="search.html"
    for="*"
    class=".search.SearchView"
    permission="project.Search"
    />

<viewlet
    name="search"
    for="*"
    view=".interfaces.ISearchView"
    manager=".interfaces.IContentManager"
    class=".search.SearchViewlet"
    template="search.pt"
    permission="project.Search"
    />

This is just work in progress. We are still experimenting with it a lot. A 
couple of problems that need to be addressed:

(1) When using the "provider" TALES expression, we still have the infamous 
update/render bug. Jeff Shell has already provided a solution to this 
problem, and I will be roughly implementing it in a backward-compatible way 
in the next days in Zope 3's content provider package.

(2) We want to use named templates, because otherwise new skins cannot 
override templates and we have to re-implement all views. Juergen agreed to 
do this actually today, so if this poses an unexpected problem, we will 
report on that.

(3) Another issue we have is that both view(let) classes and templates are 
located in layers. It is our opinion that only view(let) classes should be 
located in the layer and the templates should actually go into skins. Named 
templates will allow us to make this separation as well.

(4) The view classes are currently pretty lame. We often only need them for 
interface assignments (and later for listing content providers when (1) is 
implemented). We will probably a custom ZCML directive to support this use 
case better. We will see.

Okay, that's it for now. Thanks goes to Juergen Kartnaller for helping me 
writing this response.

Note: I am using this message to document our new design for lovely systems at 
the same time. ;-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training


More information about the Zope3-users mailing list