AW: [Zope3-dev] Re: AW: override metadirectives before use themnotafterwards

[Dominik Huber]

> > All this futures I could implement without any problems in
> a new skin
> > except the changes in the contents.pt template. It needs just a
> > javascript:oncklick event on the img tag of a objects image.
>
> Right, so that is a true limitation to the current skin
> mechanism that I am
> not happy with either. I ran into similar problems when doing
> the original
> ZWiki code. I have no good answer for this.

I try to catch that use case:

Different applications are using one central content view. This view
uses a 'private'
contents.pt (resource) to visualize the content view. To provide anohter
'extending' skin the 'private' template should be changed (extended)
because it does not covers all requirements to implement additional
features.

To introduce this new skin today, all existing applications (directives)
refering to this content view must be overridden (zcml-hard-wired). An
that seems a little bit painful... and it does not encurage distributing
skin packages independently at all.

Before containerViews we had the same problem: Creating specific Adding
view but copy/paste add.pt's into the own packages was producing a
similar problem. Using pages/views instead of containerViews leads to an
equal redundancy because the physical resource is referenced serveral
times (zcml-hard-wired).

Generalized, it is the following problem:
Switch 'private' resources (members) of a heavy used (referenced)
'default' component so that all applications refering this component
also use the switched 'private' resources. Those 'private' resources are
only 'semi private' because they represent a 'default' implementations
of the zope3 framework (in our case container framework). Therefore they
should not be zcml-hard-wired.

Today this requirement is properly solved for regular component lookup
via interfaces and class specifications but not for skinning and
templating resources for example our content.pt.

Many attributes of page/views-directives allow 'hard links' only but
'soft links' often would be more appropriate to avoid
zcml-hard-wired-redundancy.

IMO we would need one zcml-indirection more refering private 'resources'
comparable to addform.name to addMenuItem.view:

  <browser:addform
      ...
      name="AddOrder.html"
      ...
      />

  <browser:addMenuItem
      ...
      view="AddOrder.html"
      />

So it would be easy to overwrite a single 'private' resource directive
without touching any meta-directive. To obtain more privateness it would
be cool to introduce private resource which can share equal names
because they are looked up in a context determined by the referenced
class (unlike existing global resources):

  <browser:privateResource
      name="contentresource"
      template="content.pt"
	class="zope.app.container.browser.contents.Contents"
      />

  <browser:view
 	class="zope.app.container.browser.contents.Contents"
      privateResource="contentresource"
      ...
      />

Also configured adding views could use the component(class) context to
lookup resources:

  <browser:privateResource
      name="addresource"
      template="add.pt"
	class="zope.app.container.browser.adding.Adding"
      />

  <browser:view
     name="+"
     for="zopeproducts.messageboard.interfaces.IMessageBoard"
     class="zope.app.container.browser.adding.Adding"
     ...
     >
     <browser:page name="index.html"  privateResource="addresource" />
     <browser:page name="action.html" attribute="action" />
  </browser:view>

regards,
Dominik