[Zope3-dev] Re: issue 216

Roman Roelofsen r.roelofsen at tuxed.de
Wed Mar 23 14:16:08 EST 2005


Hi Roger,
Hi Derrick,

thanks a lot for your answers!

Roman

> Hi Derrick
>
> > -----Original Message-----
> > From: zope3-dev-bounces+dev=projekt01.ch at zope.org
> > [mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] On
> > Behalf Of Derrick Hudson
> > Sent: Tuesday, March 22, 2005 11:12 PM
> > To: zope3-dev at zope.org
> > Subject: [Zope3-dev] Re: issue 216
> >
> > On Tue, Mar 22, 2005 at 06:51:23PM +0100, Roman Roelofsen wrote:
> > | Hi Roger,
> > |
> > | thanks for your reply.
> > |
> > | > > ~ So, what do you think about my approach?
> > | > > ~ Is there a better, more "zopeish" way?
> > | >
> > | > Yes, add a own skin, there you can provide whatever you like.
> > | > Hm, that's not right. If you inherit your skin from the
> >
> > rotterdam layer
> >
> > | > you will inherit all views and pages.
> > |
> > | But if I define my user_views, etc. in my custom skin, my
> >
> > view compontents
> >
> > | wouldn´t be useable in other zope instances which are using
> >
> > a different skin.
> > [snip example]
> >
> > The way I understand it, you should put your views in a layer.  Then
> > you include that layer in the skin(s) that you want the view to exist
> > in.
> >
> > I suppose you could also register your views in more than one
> > layer/skin so that you have both a complete custom skin and also a
> > piece that fits in the Rotterdam (or whatever) skin.
> >
> > (however, I haven't tried any of this yet :-), I may be mistaken)
>
> That's correct
>
> > [...]
> >
> > | Different users should use different skins?
> >
> > It makes sense to me, since different categories of users should see
> > the system differently.  Eg Zope2 has the ZMI for site developers and
> > admins, and then an app (a custom app, or CMF/Plone/etc.) provides its
> > own views that the end-user will see.
> >
> > | Is "skin" then still the correct word? I always understood a Zope3
> > | skin as the
> > | last polish step for my whole site.
> >
> > Sort-of.  I guess it depends on how you do your development.
> >
> > One model is to knock together cheesy views and put them in the ZMI
> > (currently Rotterdam skin) just to exercise and test your code.
>
> This is recommended for reuasable components. This makes your
> componentn independent form a skin.
>
> > Once
> > the data and logic work, you could then focus on the presentation to
> > the users.  Another model is to do the presentation first as a set of
> > mock-ups, and then fill in the implementation to support the views.
>
> This can you do if you develop components for just one project
> and reuse is not important.
>
> > A
> > third model is to do both more-or-less in parallel.
> >
> > At any rate, my understanding is as follows:
> >     + a skin is the unit of choice a user/admin has for choosing the
> >         appearance of the UI
> >     + a skin is merely an ordered set of layers
> >     + layers contain the various views, menus, and what-not that
> >         comprise the UI of the system
> >
> > If I am correct, then this means that by putting all of your stuff
> > into cohesive layers, you then have the flexibility to
> > include the views
> > in whatever skins you so desire.  Furthermore, I believe you can
> > create a skin using inheritance, so hypothetically you could create a
> > MyContactRotterdam skin that inherits from Rotterdam and adds your
> > MyContactLayer layer to it, so you get both the existing Rotterdam
> > stuff and your custom contact views.
>
> Correct
>
> Regards
> Roger Ineichen
>
> > HTH,
> > -D
> >
> > --
> > What good is it for a man to gain the whole world, yet forfeit his
> > soul?  Or what can a man give in exchange for his soul?
> >         Mark 8:36-37
> >
> > www: http://dman13.dyndns.org/~dman/            jabber:
> > dman at dman13.dyndns.org
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub:
> http://mail.zope.org/mailman/options/zope3-dev/r.roelofsen%40tuxed.de


More information about the Zope3-dev mailing list