[Zope3-Users] Re: Intended scope of viewlets?
Alec Munro
alecmunro at gmail.com
Wed Oct 11 10:05:27 EDT 2006
Thanks again. I think I understand why I was having difficulty with
this. It seems that under this model, views are tied directly to
skins, and if you wish to change skins, you change the template
registration, and probably some CSS resource registrations, rather
than simply specifying another skin using ++skin++.
I suppose, however, that I could create a lower level layer that I did
all of my skin-independent view registrations on.
I think I will try to write up all of my experiences with viewlets and
post it somewhere, as it seems like they are very powerful once you
can understand how to properly separate concerns with them.
Alec
On 10/10/06, Jürgen Kartnaller <juergen at kartnaller.at> wrote:
> Hi Alec.
>
> Alec Munro wrote:
> > One more thing. When using this masterpage idea, what is the pattern
> > for creating new pages? For example, I would traditionally have:
> >
> > MyObject/SubjectOne.html
> > MyObject/SubjectTwo.html
> > MyObject/SubjectThree.html
> >
> > Registered with:
> >
> > <page
> > for="IMyObject"
> > name="SubjectOne.html"
> > template="subjectone.pt"
> > />
> >
> > ...
> >
> > Where "subjectone.pt" would probably start with something like the
> > following:
> >
> > <html metal:use-macro="views/standard_macros/view">
> >
> > Obviously, the above no longer applies, so what's the equivalent? My
> > initial thought, if I am sticking as close to the above paradigm as
> > possible, would be to have registrations for each that all reference
> > the same class, being the one that implements the interface my
> > masterpage is registered for. Something like the following:
> >
> > <page
> > for="IMyObject"
> > name="SubjectOne.html"
> > class=".MySkin.SimplePage"
> > />
> >
> > <page
> > for="IMyObject"
> > name="SubjectTwo.html"
> > class=".MySkin.SimplePage"
> > />
> >
> > ...
> >
> > In some ways, this makes sense to me, but it leaves me unsure how to
> > properly differentiate the content on each page, without implementing
> > something on each ViewletManager that detects the name of the page
> > requested, and returns the appropriate content. Unless of course I can
> > register Viewlets or ViewletManagers to specific page names?
>
> Thats what the view parameter in the viewlet directive is doing :)
>
> >
> > My guess is that the above pattern simply isn't applicable to the use
> > of viewlets, and there is something else I should be using. I will
> > investigate uses of viewlets, but if anyone knows the answer offhand,
> > I would very much appreciate it.
>
> Simply derive a new view class from SimplePage and use that class when
> registering a new page.
>
> class AnotherPage(SimplePage):
> pass
>
> Now you can register a new page. Note taht we do not need to define the
> template because it is already defined for SimplePage.
>
> <page
> for="IMyObject"
> name="SubjectTwo.html"
> class=".MySkin.AnotherPage"
> permission="..."
> />
>
> You can now register your viewlets on that class (page) :
> <viewlet
> name="anotherViewlet"
> for="IMyObject"
> view=".MySkin.AnotherPage"
> manager="..."
> class="..."
> layer="your skin"
> permission="..."
> />
>
> Also note that all viewlets registered for SimplePage are also visible
> in the new page. You register globally visible viewlets on your SimplePage.
>
> Its simple and powerful, isn't it ?
>
> The most important thing you must see is the ability to register a
> viewlet on the context, the view, the manager and the request. This
> gives you a lot of control over the viewlet.
>
>
> Here is the code I'm using for my viewletmanager to have more control
> over the visibility of viewlets. I use this manager im my main template.
>
> class ContentViewletManager(WeightOrderedViewletManager):
> interface.implements(IContentViewletManager)
>
> def filter(self, viewlets):
> viewlets = super(ContentViewletManager, self).filter(viewlets)
> return [(name, viewlet) for name, viewlet in viewlets
> if getattr(viewlet, 'available', True)]
>
> If the viewlet provides the property 'available' it can control if it is
> visible or not. Among other things I use this often to have a dependency
> on user login. IUnauthenticatedPrincipal.providedBy(self.request.principal)
>
>
> >
> > Thanks again,
> >
> > Alec Munro
> >
> >
> >
> > On 10/10/06, Alec Munro
> > <alecmunro at gmail.com> wrote:
> >> 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
> >> >
> >> >
> >> >
> >> >
> >>
>
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>
More information about the Zope3-users
mailing list