[Zope3-Users] Handling deletion rights ?

2006-10-06 Thread Thierry Florac





 Hi,

I have folders in my Zope3 application, which can contain sub-folders as well as content objects.
Sub-folders are handled by a manager.
Content objects are handled by contributors.

I can easilly give access rights for managers and contributors so that each of them can only create given objects.
But what concerning deletion ? How can I prevent a contributor from removing a sub-folder ?

Thanks for any help,




 Thierry Florac
-- 



 Chef de projet intranet/internet
 Office National des Forts - Dpartement Informatique
 2, Avenue de Saint-Mand
 75570 PARIS Cedex 12
 Ml : [EMAIL PROTECTED]
 Tl. : +33 01.40.19.59.64
 Fax. : +33 01.40.19.59.85








___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


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

2006-10-06 Thread Alec Munro

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


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

2006-10-06 Thread Alec Munro

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 [EMAIL PROTECTED] 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 [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 

[Zope3-Users] Seeking a ZCML Example for a CSSViewlet

2006-10-06 Thread Jeff Rush
I've got viewlets working fine (really cool too!) but I'm stumped on getting a
CSSViewlet declared.  Googling doesn't show anyone using CSSViewlets but
hopefully someone who implemented it might clarify.

The doc files show how to do it with pure Python and the utility function
viewlet.viewlet.CSSViewlet but I need it using ZCML.  I'm trying:

  browser:viewlet
name=success.css-link
manager=.interfaces.IStylingLinks
permission=zope.Public
media=screen
rel=css
class=zope.viewlet.viewlet.CSSResourceViewletBase
/

This bypasses the utility function and generates an error about there being no
 'index' attribute, which is the small template file containing the
parameterized HTML link tag, in the result class.

So I give it a template file, although I really hate putting such a full path
in my component ZCML file:

template=/usr/share/zope-3.3.0-py2.4/lib/python/zope/viewlet/css_viewlet.pt


And now it errors out about a missing '_path' class attribute, which is passed
into the utility function.

I've also thought about passing in the utility function via a 'factory='
parameter but the viewlet directive doesn't support such a parameter.  And
I've tried just passing in the utility function on a 'class=' parameter,
figuring maybe it just wants a callable.  No luck, it wants a real class to
pass into type() for instantiation.

It's only seven lines of ZCML but I sure can't see how to use it properly.
Next I'll just roll my own ZCML directive but it seems there ought to be a way
to use CSSViewlet as intended and I'm just missing it.

Help please?

-Jeff
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] Seeking a ZCML Example for a CSSViewlet

2006-10-06 Thread Darryl Cousins
On Fri, 2006-10-06 at 20:29 -0500, Jeff Rush wrote:
 I've got viewlets working fine (really cool too!) but I'm stumped on getting a
 CSSViewlet declared.  Googling doesn't show anyone using CSSViewlets but
 hopefully someone who implemented it might clarify.

 Help please?
 
 -Jeff

Hi Jeff,

I do it like this (forgetting where the boilerplate came from - thanks
to someone).:

python code::

BRSPublicLayerLayoutCSSViewlet = 
zope.viewlet.viewlet.CSSViewlet('style/layout.css', 'all')

configure zcml::

  browser:viewlet
  name=layout.css
  for=*
  manager=barrysmithgallery.layer.public.ICSS
  permission=zope.Public
  class=..BRSPublicLayerLayoutCSSViewlet
  layer=barrysmithgallery.layer.public.IBRSPublicBrowserLayer
  weight=2
  /

And the manager:

python code::


class ICSS(zope.viewlet.interfaces.IViewletManager):

configure zcml::

  browser:viewletManager
  name=barrysmithgallery.layer.public.ICSS
  provides=barrysmithgallery.layer.public.ICSS
  layer=barrysmithgallery.layer.public.IBRSPublicBrowserLayer
  permission=zope.Public
  /

And it gets into main template::

 tal:block replace=structure provider:barrysmithgallery.layer.public.ICSS /

Hope this helps.

Best regards,
Darryl

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users