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

Sat Oct 7 02:37:17 EDT 2006

Hi Alec

Alec Munro 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>

exactly

> 
> 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?

What you need is up to your application.

You can define a header manager which the changes its content/viewlets 
depending on the page viewed.

> 
> Finally, are there any best practices for packaging in viewlet-based
> templating? I'm currently creating this in my.project.browser.skin.

Our current structure is :

project.browser.layer.<packages for the view implementations>
   Here we provide the view code and the viewlet registrations.
project.browser.skin
   Here we provie the templates and the template registrations using 
z3c.viewtemplate.

> How about the viewlet manager names, should they be my.project.*,
> my.project.browser.*, or something different?

We use the interface name as the manager name.

> 
> 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
>>