[Zope3-Users] Re: Intended scope of viewlets?

Tue Oct 10 09:21:09 EDT 2006

You were correct, because my skin was inheriting from
z3c.layer.minimal.IMinimalBrowserLayer, which as best I can tell,
doesn't inherit from the default layer (there's probably a ZCML
directive to set this somewhere though), my
pages/templates/viewlets/etc weren't available to be looked up. I made
my skin inherit from IDefaultBrowserLayer, and everything's peachy.

Thanks everyone, for all your help so far.

Alec

On 10/7/06, ksmith93940-dev at yahoo.com <ksmith93940-dev at yahoo.com> wrote:
>
> I think the layer attribute may be missing.
>
> <browser:page
>     name="my.project.index.html"
>     for="*"
>     class=".myskin.SimplePage"
>     permission="zope.Public"
>     layer=".interfaces.MySkin"
>     />
>
> <browser:template
>     template="myskin_master.pt"
>     for=".interfaces.ISimplePage"
>     layer=".interfaces.MySkin"
>     />
>
> Kevin Smith
>
> ----- Original Message ----
> From: Alec Munro <alecmunro at gmail.com>
> To: Jürgen Kartnaller <juergen at kartnaller.at>
> Cc: zope3-users at zope.org
> Sent: Friday, October 6, 2006 11:39:23 AM
> Subject: Re: [Zope3-Users] Re: Intended scope of viewlets?
>
> I think I must be missing something about the way skins work now. I've
> created a master page that I can load when I don't specify a skin, but
> when I do specify a skin (++skin++MySkin), it is unable to find the
> page (404). Here's a rough approximation of my ZCML:
>
> <interface
>     interface=".interfaces.MySkin"
>     type="zope.publisher.interfaces.browser.IBrowserSkinType"
>     name="MySkin"
>     />
>
> <browser:page
>     name="my.project.index.html"
>     for="*"
>     class=".myskin.SimplePage"
>     permission="zope.Public"
>     />
>
> <browser:template
>     template="myskin_master.pt"
>     for=".interfaces.ISimplePage"
>     />
>
> There's lots more, and if any of it would be relevant, let me know,
> but this seems like it's the crucial part. I know it is finding the
> skin itself successfully, because the error message is not the
> standard Rotterdam one. The skin I'm using is currently just inherits
> from z3c.layer.minimal.
>
> I'll keep on trying things, but it's all kind of a shot in the dark right now.
>
> Thanks,
>
> Alec
>
>
> On 10/6/06, Alec Munro <alecmunro at gmail.com> wrote:
> > Hi Jürgen,
> >
> > So, just to give a concrete example for my case, I might replace this
> > (Metal-based):
> >
> > <body>
> >
> > <div id="Navigation">
> >   <div metal:define-slot="navigation">
> >     Nav tree needs a wee bit of work.
> >   </div>
> > </div>
> >
> > <div id="Content">
> >   <div metal:define-slot="body">
> >    Some Content
> >   </div>
> > </div>
> >
> > </body>
> >
> > with this (viewlet-based):
> >
> > <body>
> >
> > <div id="Navigation">
> >     <span tal:replace="structure provider:my.project.navigation">
> >       Nav tree needs a wee bit of work.
> >     </span>
> > </div>
> >
> > <div id="Content">
> >   <span tal:replace="structure provider:my.project.content">
> >     Some Content
> >   </span>
> > </div>
> >
> > </body>
> >
> > With seperate viewlet managers for "navigation" and "content", or any
> > other types of views I would expect to have on this page? Would a
> > "header" viewlet manager also be sensible, say if I wanted a title
> > that changed format depending on what type of content was being
> > viewed?
> >
> > Finally, are there any best practices for packaging in viewlet-based
> > templating? I'm currently creating this in my.project.browser.skin.
> > How about the viewlet manager names, should they be my.project.*,
> > my.project.browser.*, or something different?
> >
> > Probably some of these questions aren't relevant to the work you are
> > doing on viewlets, but I find it helpful to try to follow industry
> > practices as closely as possible, especially on something I don't have
> > much experience with, so I am easily able to follow tutorials, and
> > people who are helping me can more easily understand what I am trying
> > to do.
> >
> > Thanks very much for your help so far, I am excited about implementing
> > viewlets in our upcoming project.
> >
> > Alec
> >
> > On 10/5/06, Jürgen Kartnaller <juergen at kartnaller.at> wrote:
> > > Hi Alec.
> > >
> > > Alec Munro wrote:
> > > > Hi List,
> > > >
> > > > I'm just getting up to speed with viewlets, having read a thread here
> > > > and there in the past about them. I've installed the examples provided
> > > > on this list, and while I believe I understand how they work, I don't
> > > > understand in what circumstances they are most useful. The viewlets in
> > > > the examples are all very small, such as retrieving an formatting a
> > > > single piece of information about an object. However, from some of the
> > > > posts to this list, I get the impression they are also being used for
> > > > more complex items, like navigation menus.
> > >
> > > Menus are a perfect example for the use of viewlets.
> > > Have a look at z3c.menu. This package contains a base implementation for
> > > menus based on viewlets.
> > >
> > > > Is there a recommended scope? Can they be described in a way such as
> > > > "develop your templates up to point X, then use a viewlet for
> > > > development of further depth?".
> > > >
> > > > In my case, I am developing a new skin for a project, and my
> > > > experience with metal says to make the entire HTML page a macro with
> > > > slots for content and navigation. Is there a comparable viewlet-based
> > > > paradigm?
> > >
> > > Yes there is one, see below
> > >
> > > >
> > > > Also, am I correct in stating that when working with viewlets, the
> > > > only complete HTML page will be the primary skin file, with all
> > > > viewlets based on snippets of HTML?
> > >
> > > Thats exacly what we at Lovely Systems do and it works perfectly :)
> > >
> > > We have one base template which is used for all pages. Instead of
> > > defining slots to be filled by other templates it contains viewlet managers.
> > > We then provide different view classes to be able to register our
> > > viewlets for the pages of the application.
> > > The view classes are empty classes they are just providing the class
> > > name or if they provide additional functionality they also provide an
> > > interface.
> > > It is then possible to register the viewlets for specific pages.
> > > The most important thing on viewlets is that they are adapters on the
> > > *context*, the *request*, the *view* and the *manager*.
> > >
> > > The viewlet solution is an extremely productive way to implement a
> > > complex application.
> > >
> > > Make sure you read this :
> > > http://blogs.lovelysystems.com/srichter/2006/09/20/the-skin-browser-and-lovely-systems-new-development-workflow/
> > >
> > > Stephan Richter describes here our use of the viewlet concept and our
> > > development workflow. The most important part was the development of the
> > > package z3c.viewtemplate. This package makes it possible to separate the
> > >   development of the HTML page from the implementation of the python
> > > view class. The package is not yet perfect but gives us what we need
> > > right now but it needs a better integration into forms and viewlets.
> > > Expect more in the near future!
> > >
> > > In our applications really everything is done using viewlets, there is
> > > no single use of fill-slot in the hole application!
> > >
> > > >
> > > > My questions are fairly broad-ranging, I know, but I have thus far
> > > > been unable to find a straightforward explanation of viewlets, in
> > > > terms of how they relate to general site development.
> > >
> > > All I can tell you now is : USE VIEWLETS, USE VIEWLETS, USE VIEWLETS,
> > >
> > >
> > > Jürgen
> > >
> > > _______________________________________________
> > > Zope3-users mailing list
> > > Zope3-users at zope.org
> > > http://mail.zope.org/mailman/listinfo/zope3-users
> > >
> >
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>
>
>
>