[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