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 <[EMAIL PROTECTED]> 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@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
