[Zope3-Users] Re: Intended scope of viewlets?
Jürgen Kartnaller
juergen at kartnaller.at
Tue Oct 10 15:09:45 EDT 2006
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
>> >
>> >
>> >
>> >
>>
More information about the Zope3-users
mailing list