[Checkins] SVN: bluebream/website/docs/v1.0/manual/ rename chapter
Baiju M
baiju.m.mail at gmail.com
Sat Feb 13 05:36:36 EST 2010
Log message for revision 108976:
rename chapter
Changed:
U bluebream/website/docs/v1.0/manual/index.rst
A bluebream/website/docs/v1.0/manual/skinning.rst
D bluebream/website/docs/v1.0/manual/skinsandlayers.rst
-=-
Modified: bluebream/website/docs/v1.0/manual/index.rst
===================================================================
--- bluebream/website/docs/v1.0/manual/index.rst 2010-02-13 10:34:44 UTC (rev 108975)
+++ bluebream/website/docs/v1.0/manual/index.rst 2010-02-13 10:36:36 UTC (rev 108976)
@@ -22,14 +22,7 @@
configuration
startup
functionaltesting
- advancedviews
- skinsandlayers
- i18nl10n
- basicsecurity
+ skinning
schema
form
- authentication
- annotation
- traverser
- event
- catalog
+
Copied: bluebream/website/docs/v1.0/manual/skinning.rst (from rev 108974, bluebream/website/docs/v1.0/manual/skinsandlayers.rst)
===================================================================
--- bluebream/website/docs/v1.0/manual/skinning.rst (rev 0)
+++ bluebream/website/docs/v1.0/manual/skinning.rst 2010-02-13 10:36:36 UTC (rev 108976)
@@ -0,0 +1,250 @@
+Skinning
+========
+
+.. warning::
+
+ This documentation is under construction. See the `Documentation
+ Status <http://wiki.zope.org/bluebream/DocumentationStatus>`_ page
+ in wiki for the current status and timeline.
+
+Introduction
+------------
+
+It is often required to build web applications with equal/similar
+features, but different look and feel. Variation of look and feel
+can be simple or complex. It can be either just an exchange of a CSS
+file and some images. Sometimes, you will be required to reconfigure
+the application to have different user interface components, such as
+widgets, tables etc. Also you will be required to mix and match user
+interface components from multiple packages.
+
+The level of customization of Zope (2 and 3) has been a strong point
+for years. Initially the user interface was customized relying on
+implicit acquisition, where it was simply a matter of adding an
+object higher in the object path to customize the user interface.
+Since implicit acquisition is often hard to debug, the CMF introduced
+the concept of skins, where a skin describes the look and feel of a
+site. Skins could acquire from other skins explicitly.
+
+In Zope 3 the concept of skins was reconsidered and re-implemented to
+use the component architecture.
+
+There are two terms associated with skinning named, `layer` and
+`skin`. Before proceeding, it would be better to understand the
+meaning of these two terms in Zope 3 skinning.
+
+Layers
+~~~~~~
+
+* Define the "feel" of a site
+
+* Contain presentation logic
+
+* Common artifacts: pages, content providers, viewlet managers, and
+ viewlets
+
+* Developed by Zope 3 Python developers
+
+
+Skins
+~~~~~
+
+* Define the "look" of a site
+
+* Common artifacts: templates and resources (CSS, Javascript, etc.)
+
+* Use layers to retrieve the data for templates
+
+* Developed by HTML and Graphic Designer/Scripter
+
+
+Layers versus skins
+~~~~~~~~~~~~~~~~~~~
+
+* Both are implemented as interfaces
+
+* BlueBream does not differentiate between the two
+
+* In fact, the distinction of layers defining the "feel" and skins
+ the "look" is a convention. You may not want to follow the
+ convention, if it is too abstract for you, but if you are
+ developing application with multiple look and feel, I strongly
+ suggest using this convention, since it cleanly separates concerns.
+
+* Both support inheritance/acquisition
+
+This is realized through a combination of interface inheritance and
+component lookup techniques. This book will discuss this in more
+detail later.
+
+Skins are directly provided by a request
+
+
+Core skins
+----------
+
+* Access skin using ++skin++Name after the server root
+
+* Core Skins that are part of the repository
+
+ - Rotterdam -- the default skin shown
+
+ - Boston -- a newer skin featuring viewlets
+
+ - Basic -- a skin with no layout styles
+
+ - Debug -- based on Rotterdam, shows debug information upon
+ failures
+
+* Try http://localhost:8080/++skin++Boston
+
+Unfortunately, it is hard to reuse the UI components developed for
+these skins, since they still rely on the not so flexible macro
+pattern. Thus, it is better if you start from scratch. This will
+also avoid a lot of the overhead that comes with the over-generalized
+core skins.
+
+
+A new skin
+----------
+
+* Views registered for default layer by default
+ zope.publisher.interfaces.browser.IDefaultBrowserLayer
+
+* Default layer contains a lot of things you do not need (security
+ concerns)
+
+* Since pretty much everything in zope.app is registered into the
+ default layer, it has an uncontrollable amount of junk in it. It
+ is very hard to verify that all those registrations fulfill your
+ security needs. Another problem is that views might be available
+ that you do not want to be available.
+
+* Always want to develop skins from scratch
+
+* Some registrations in the default layer are very useful
+
+* Examples of those useful registrations include error views,
+ traversal registrations, and widgets.
+
+
+Setting up a layer
+~~~~~~~~~~~~~~~~~~
+
+Write an interface for the layer that inherits the minimal layer::
+
+ from zope.publisher.interfaces.browser import IBrowserSkinType
+
+ class IHelloWorldLayer(IBrowserSkinType):
+ """Hello World Application Layer"""
+
+
+Change all page, viewletmanager, and viewlet directives to specify
+this layer:
+
+ layer=".interfaces.IHelloWorldLayer"
+
+Once you changed those registrations, the helloworld.html page is not
+available anymore in the core skins. The templates by themselves do
+not matter.
+
+
+Using layer
+~~~~~~~~~~~
+
+Registering views and resources is not any different now, but you can
+simply register them on the skin directly::
+
+ <browser:resource
+ name="zope3logo.gif"
+ file="images/zope3logo.gif"
+ layer=".interfaces.IBasicSkin"
+ />
+
+As you can see, you don't have to create an extra layer just to
+create a custom skin. You were also able to use standard Component
+Architecture ZCML directives instead of custom ones whose special
+syntax the developer needs to remember additionally.
+
+A typical ``browser:page`` with with layer specified is like this::
+
+ <browser:page
+ for="*"
+ name="dialog_macros"
+ permission="zope.View"
+ layer=".interfaces.IBasicSkin"
+ template="dialog_macros.pt"
+ />
+
+
+Setting up a skin
+~~~~~~~~~~~~~~~~~
+
+Skins are technically interfaces defined using ``zope.interface``
+package. To create a custom skin it is always better to inherit from
+a standard layer or another skin interface. It is by convention that
+skins will be created in sub-package named ``skin`` in your
+``browser`` package of your main package. For example, if your
+package name is ``foo``, then ``foo.browser.skin`` will be the skin
+package, but this is not mandatory. Your skin interfaces can be
+defined in ``foo.browser.skin.interfaces``.
+
+Write an interface for each new skin that inherits the Hello World
+application layer::
+
+ class IBasicSkin(IHelloWorldLayer):
+ """Basic Skin for Hello World App."""
+
+To register this you can use ``interface`` and ``utility`` directives
+in ``zope`` namespace. The type of the ``IShanghaiSkin`` skin is
+``zope.publisher.interfaces.browser.IBrowserSkinType``. Here is a
+sample ``configure.zcml``::
+
+ <interface
+ interface=".interfaces.IBasicSkin"
+ type="zope.publisher.interfaces.browser.IBrowserSkinType"
+ />
+
+ <utility
+ component=".interfaces.IBasicSkin"
+ provides="zope.publisher.interfaces.browser.IBrowserSkinType"
+ name="BasicSkin"
+ />
+
+As a shortcut, you can also just use the ``interface`` directive and
+pass the new name parameter. The following one directive has the
+same effect as the two above regarding the skin registration::
+
+ <interface
+ interface=".interfaces.IBasicSkin"
+ type="zope.publisher.interfaces.browser.IBrowserSkinType"
+ name="BasicSkin"
+ />
+
+Register all templates for this skin by adding the layer attribute::
+
+ layer=".interfaces.IBasicSkin"
+
+
+Using the skin
+~~~~~~~~~~~~~~
+
+Access it via: http://localhost:8080/++skin++BasicSkin
+
+Hide skin traversal step by using Apache's Virtual Hosting feature
+
+To change the default skin to something else use:
+
+ <browser:defaultSkin name="BasicSkin" />
+
+Simply specifying the browser:defaultSkin directive in your
+configuration file will not work, since it has been specified in
+zope/app/zcmlfiles/browser.zcml already. You can either change the
+skin at this location or use the zope:includeOverrides directive,
+which will override the any included directives.
+
+
+Summary
+-------
+
+This chapter introduced skinnig in BlueBream.
Deleted: bluebream/website/docs/v1.0/manual/skinsandlayers.rst
===================================================================
--- bluebream/website/docs/v1.0/manual/skinsandlayers.rst 2010-02-13 10:34:44 UTC (rev 108975)
+++ bluebream/website/docs/v1.0/manual/skinsandlayers.rst 2010-02-13 10:36:36 UTC (rev 108976)
@@ -1,250 +0,0 @@
-Skinning
-========
-
-.. warning::
-
- This documentation is under construction. See the `Documentation
- Status <http://wiki.zope.org/bluebream/DocumentationStatus>`_ page
- in wiki for the current status and timeline.
-
-Introduction
-------------
-
-It is often required to build web applications with equal/similar
-features, but different look and feel. Variation of look and feel
-can be simple or complex. It can be either just an exchange of a CSS
-file and some images. Sometimes, you will be required to reconfigure
-the application to have different user interface components, such as
-widgets, tables etc. Also you will be required to mix and match user
-interface components from multiple packages.
-
-The level of customization of Zope (2 and 3) has been a strong point
-for years. Initially the user interface was customized relying on
-implicit acquisition, where it was simply a matter of adding an
-object higher in the object path to customize the user interface.
-Since implicit acquisition is often hard to debug, the CMF introduced
-the concept of skins, where a skin describes the look and feel of a
-site. Skins could acquire from other skins explicitly.
-
-In Zope 3 the concept of skins was reconsidered and re-implemented to
-use the component architecture.
-
-There are two terms associated with skinning named, `layer` and
-`skin`. Before proceeding, it would be better to understand the
-meaning of these two terms in Zope 3 skinning.
-
-Layers
-~~~~~~
-
-* Define the "feel" of a site
-
-* Contain presentation logic
-
-* Common artifacts: pages, content providers, viewlet managers, and
- viewlets
-
-* Developed by Zope 3 Python developers
-
-
-Skins
-~~~~~
-
-* Define the "look" of a site
-
-* Common artifacts: templates and resources (CSS, Javascript, etc.)
-
-* Use layers to retrieve the data for templates
-
-* Developed by HTML and Graphic Designer/Scripter
-
-
-Layers versus skins
-~~~~~~~~~~~~~~~~~~~
-
-* Both are implemented as interfaces
-
-* BlueBream does not differentiate between the two
-
-* In fact, the distinction of layers defining the "feel" and skins
- the "look" is a convention. You may not want to follow the
- convention, if it is too abstract for you, but if you are
- developing application with multiple look and feel, I strongly
- suggest using this convention, since it cleanly separates concerns.
-
-* Both support inheritance/acquisition
-
-This is realized through a combination of interface inheritance and
-component lookup techniques. This book will discuss this in more
-detail later.
-
-Skins are directly provided by a request
-
-
-Core skins
-----------
-
-* Access skin using ++skin++Name after the server root
-
-* Core Skins that are part of the repository
-
- - Rotterdam -- the default skin shown
-
- - Boston -- a newer skin featuring viewlets
-
- - Basic -- a skin with no layout styles
-
- - Debug -- based on Rotterdam, shows debug information upon
- failures
-
-* Try http://localhost:8080/++skin++Boston
-
-Unfortunately, it is hard to reuse the UI components developed for
-these skins, since they still rely on the not so flexible macro
-pattern. Thus, it is better if you start from scratch. This will
-also avoid a lot of the overhead that comes with the over-generalized
-core skins.
-
-
-A new skin
-----------
-
-* Views registered for default layer by default
- zope.publisher.interfaces.browser.IDefaultBrowserLayer
-
-* Default layer contains a lot of things you do not need (security
- concerns)
-
-* Since pretty much everything in zope.app is registered into the
- default layer, it has an uncontrollable amount of junk in it. It
- is very hard to verify that all those registrations fulfill your
- security needs. Another problem is that views might be available
- that you do not want to be available.
-
-* Always want to develop skins from scratch
-
-* Some registrations in the default layer are very useful
-
-* Examples of those useful registrations include error views,
- traversal registrations, and widgets.
-
-
-Setting up a layer
-~~~~~~~~~~~~~~~~~~
-
-Write an interface for the layer that inherits the minimal layer::
-
- from zope.publisher.interfaces.browser import IBrowserSkinType
-
- class IHelloWorldLayer(IBrowserSkinType):
- """Hello World Application Layer"""
-
-
-Change all page, viewletmanager, and viewlet directives to specify
-this layer:
-
- layer=".interfaces.IHelloWorldLayer"
-
-Once you changed those registrations, the helloworld.html page is not
-available anymore in the core skins. The templates by themselves do
-not matter.
-
-
-Using layer
-~~~~~~~~~~~
-
-Registering views and resources is not any different now, but you can
-simply register them on the skin directly::
-
- <browser:resource
- name="zope3logo.gif"
- file="images/zope3logo.gif"
- layer=".interfaces.IBasicSkin"
- />
-
-As you can see, you don't have to create an extra layer just to
-create a custom skin. You were also able to use standard Component
-Architecture ZCML directives instead of custom ones whose special
-syntax the developer needs to remember additionally.
-
-A typical ``browser:page`` with with layer specified is like this::
-
- <browser:page
- for="*"
- name="dialog_macros"
- permission="zope.View"
- layer=".interfaces.IBasicSkin"
- template="dialog_macros.pt"
- />
-
-
-Setting up a skin
-~~~~~~~~~~~~~~~~~
-
-Skins are technically interfaces defined using ``zope.interface``
-package. To create a custom skin it is always better to inherit from
-a standard layer or another skin interface. It is by convention that
-skins will be created in sub-package named ``skin`` in your
-``browser`` package of your main package. For example, if your
-package name is ``foo``, then ``foo.browser.skin`` will be the skin
-package, but this is not mandatory. Your skin interfaces can be
-defined in ``foo.browser.skin.interfaces``.
-
-Write an interface for each new skin that inherits the Hello World
-application layer::
-
- class IBasicSkin(IHelloWorldLayer):
- """Basic Skin for Hello World App."""
-
-To register this you can use ``interface`` and ``utility`` directives
-in ``zope`` namespace. The type of the ``IShanghaiSkin`` skin is
-``zope.publisher.interfaces.browser.IBrowserSkinType``. Here is a
-sample ``configure.zcml``::
-
- <interface
- interface=".interfaces.IBasicSkin"
- type="zope.publisher.interfaces.browser.IBrowserSkinType"
- />
-
- <utility
- component=".interfaces.IBasicSkin"
- provides="zope.publisher.interfaces.browser.IBrowserSkinType"
- name="BasicSkin"
- />
-
-As a shortcut, you can also just use the ``interface`` directive and
-pass the new name parameter. The following one directive has the
-same effect as the two above regarding the skin registration::
-
- <interface
- interface=".interfaces.IBasicSkin"
- type="zope.publisher.interfaces.browser.IBrowserSkinType"
- name="BasicSkin"
- />
-
-Register all templates for this skin by adding the layer attribute::
-
- layer=".interfaces.IBasicSkin"
-
-
-Using the skin
-~~~~~~~~~~~~~~
-
-Access it via: http://localhost:8080/++skin++BasicSkin
-
-Hide skin traversal step by using Apache's Virtual Hosting feature
-
-To change the default skin to something else use:
-
- <browser:defaultSkin name="BasicSkin" />
-
-Simply specifying the browser:defaultSkin directive in your
-configuration file will not work, since it has been specified in
-zope/app/zcmlfiles/browser.zcml already. You can either change the
-skin at this location or use the zope:includeOverrides directive,
-which will override the any included directives.
-
-
-Summary
--------
-
-This chapter introduced skinnig in BlueBream.
More information about the checkins
mailing list