[Checkins] SVN: zope3book/trunk/source/ - Added virtual-hosting
Baiju M
baiju.m.mail at gmail.com
Sun Feb 22 22:22:51 EST 2009
Log message for revision 97124:
- Added virtual-hosting
- Minor realignment
Changed:
U zope3book/trunk/source/content-components.rst
U zope3book/trunk/source/getting-started.rst
U zope3book/trunk/source/index.rst
A zope3book/trunk/source/virtual-hosting.rst
-=-
Modified: zope3book/trunk/source/content-components.rst
===================================================================
--- zope3book/trunk/source/content-components.rst 2009-02-23 00:13:20 UTC (rev 97123)
+++ zope3book/trunk/source/content-components.rst 2009-02-23 03:22:50 UTC (rev 97124)
@@ -1,25 +1,37 @@
Content Components
==================
+
Introduction
------------
-See this example::
+Of course it is essential for any serious Zope 3 developer to know
+how to implement new content objects. Using the example of a ticket
+collector, this chapter will outline the main steps required to
+implement and register a new content component in Zope 3. This
+chapter is the beginning of the development of TicketCollector
+content type and everything that is to it.
+A content component is the component which holds the data of the
+application. See this example::
+
>>> from zope import interface
>>> class IPerson(interface.Interface):
... name = interface.Attribute("Name")
+
>>> class Person(object):
... interface.implements(IPerson)
... name = None
+
>>> jack = Person()
>>> jack.name = "Jack"
-Here `jack` is a content component. So a content component is nothing but an
-object which provides a particular interface. As said in the previous chapter,
-use ``zope.schema`` to define fields of interface. The above interface can be
-declared like this::
+Here `jack` is a content component. So, a content component is
+nothing but an object which provides a particular interface. As
+mentioned in the previous chapter, use ``zope.schema`` to define
+fields of interface. The above interface can be declared in a better
+way like this::
>>> from zope import interface
>>> from zope import schema
@@ -31,14 +43,18 @@
... default=u"",
... required=True)
-If you are developing an enterprise application content will be the most
-important thing you have to organize first. To learn Zope 3 application
-development with content components, this chapter introduce a simple
-ticket/issue collector application.
+If you are developing an enterprise application, content components
+are the most important thing you have to organize first. To learn
+Zope 3 application development with content components, this chapter
+will continue the ticket collector application.
-First look at the user stories, this book will implement these stories in
-coming chapters.
+User stories
+------------
+
+First look at the user stories, this book will implement these
+stories in coming chapters.
+
1. Individual small ticket collector for each project. Many collectors can
be added to one running zope.
@@ -50,64 +66,71 @@
This chapter starts a simple implementation of ticket collector.
-As stated above, our goal is to develop a fully functional, though not
-great-looking, web-based ticket collector application. The root object will be
-the ``Collector``, which can contain ``Ticket`` objects from various users.
-Since you want to allow people to respond to various tickets, you have to allow
-tickets to contain replies, which are ``Comment`` objects.
+As stated above, our goal is to develop a fully functional, though
+not great-looking, web-based ticket collector application. The root
+object will be the ``Collector``, which can contain ``Ticket``
+objects from various users. Since you want to allow people to
+respond to various tickets, you have to allow tickets to contain
+replies, which are ``Comment`` objects.
-That means you have two container-based components: The ``Collector`` contains
-only tickets and can be added to any Folder or container that wishes to be able
-to contain it. To make the ticket collector more interesting, it also has a
-description, which briefly introduces the subject/theme of the discussions
-hosted. ``Tickets``, on the other hand should be only contained by ticket
-collector. They will each have a summary and a description. And last
-``Comment`` should be only contained by tickets.
+That means you have two container-based components: The ``Collector``
+contains only tickets and can be added to any Folder or container
+that wishes to be able to contain it. To make the ticket collector
+more interesting, it also has a description, which briefly introduces
+the subject/theme of the discussions hosted. ``Tickets``, on the
+other hand should be only contained by ticket collector. They will
+each have a summary and a description. And last ``Comment`` should
+be only contained by tickets.
-This setup should contain all the essential things that you need to make the
-object usable. Later on you will associate a lot of other meta-data with these
-components to integrate them even better into Zope 3 and add additional
-functionality.
+This setup should contain all the essential things that you need to
+make the object usable. Later on you will associate a lot of other
+meta-data with these components to integrate them even better into
+Zope 3 and add additional functionality.
-The most convenient place to put your package is ``$HOME/myzope/lib/python``.
-To create that package, add a directory using::
+The most convenient place to put your package is
+``$HOME/myzope/lib/python``. To create that package, add a directory
+using::
$ cd $HOME/myzope/lib/python/
$ mkdir collector
on GNU/Linux.
-To make this directory a package, place an empty __init__.py file in the new
-directory. In GNU/Linux you can do something like::
+To make this directory a package, place an empty __init__.py file in
+the new directory. In GNU/Linux you can do something like::
$ echo "# Make it a Python package" >> collector/__init__.py
-but you can of course also just use a text editor and save a file of this name.
-Just make sure that there is valid Python code in the file. The file should at
-least contain some whitespace, since empty files confuse some archive programs.
+but you can of course also just use a text editor and save a file of
+this name. Just make sure that there is valid Python code in the
+file. The file should at least contain some whitespace, since empty
+files confuse some archive programs.
-From now on you are only going to work inside this ``collector`` package, which
-should be located at ``$HOME/myzope/lib/python/collector``.
+From now on you are only going to work inside this ``collector``
+package, which should be located at
+``$HOME/myzope/lib/python/collector``.
Interfaces
----------
-The very first step of the coding process is always to define your interfaces,
-which represent your external API. You should be aware that software that is
-built on top of your packages expect the interfaces to behave exactly the way
-you specify them. This is often less of an issue for attributes and arguments
-of a method, but often enough developers forget to specify what the expected
-return value of a method or function is or which exceptions it can raise or
-catch.
+The very first step of the coding process is always to define your
+interfaces, which represent your external API. You should be aware
+that software that is built on top of your packages expect the
+interfaces to behave exactly the way you specify them. This is often
+less of an issue for attributes and arguments of a method, but often
+enough developers forget to specify what the expected return value of
+a method or function is or which exceptions it can raise or catch.
-Interfaces are commonly stored in an ``interfaces`` module or package. Since
-our package is not that big, you are going to use a file-based module; therefore
-start editing a file called ``interfaces.py`` in your favorite editor.
+Interfaces are commonly stored in an ``interfaces`` module or
+package. Since our package is not that big, you are going to use a
+file-based module; therefore start editing a file called
+``interfaces.py`` in your favorite editor.
-In this initial step of our application, you are only interested in defining one
-interface for the ticket collector itself and one for a single ticket, which
-are listed below (add these to the file ``interfaces.py``)::
+In this initial step of our application, you are only interested in
+defining one interface for the ticket collector itself and one for a
+single ticket, which are listed below (add these to the file
+``interfaces.py``)::
from zope.interface import Interface
from zope.schema import Text, TextLine, Field
@@ -166,8 +189,8 @@
containers(ITicket)
-If you want a hierarchy of comments, the ``IComment`` and ``ICommentContained``
-can be changed like this::
+If you want a hierarchy of comments, the ``IComment`` and
+``ICommentContained`` can be changed like this::
class IComment(Interface):
"""Comment for Ticket"""
@@ -186,20 +209,21 @@
containers(ITicket, IComment)
-See the ``IComment`` interface calls ``contains`` function with ``.IComment``
-as argument. And in ``ICommentContained`` interface, ``IComment`` is also
-added. But for simplicity these interfaces are not used in this chapter.
+See the ``IComment`` interface calls ``contains`` function with
+``.IComment`` as argument. And in ``ICommentContained`` interface,
+``IComment`` is also added. But for simplicity these interfaces are
+not used in this chapter.
Unit tests
----------
-Unit testing is explained in another chapter_ . Here you can see some
-boiler-plate code which helps to run the doctest based unittests which you will
-write later. Since `Collector` and `Ticket` objects are containers, this code
-also run common tests for containers. By convention write all unit test files
-under `tests` directory. But doctest files are placed in the package directory
-itself.
+Unit testing is explained in another chapter_ . Here you can see
+some boiler-plate code which helps to run the doctest based unittests
+which you will write later. Since `Collector` and `Ticket` objects
+are containers, this code also run common tests for containers. By
+convention write all unit test files under `tests` directory. But
+doctest files are placed in the package directory itself.
.. _chapter: /ZopeGuideUnitTesting
Modified: zope3book/trunk/source/getting-started.rst
===================================================================
--- zope3book/trunk/source/getting-started.rst 2009-02-23 00:13:20 UTC (rev 97123)
+++ zope3book/trunk/source/getting-started.rst 2009-02-23 03:22:50 UTC (rev 97124)
@@ -29,14 +29,14 @@
~~~~~~~~~
To install Python, you will be required to install gcc, g++ and other
-development tools in your system. A typical installation of Python can
-be done like this:
+development tools in your system. A typical installation of Python
+can be done like this:
::
- $ wget -c http://www.python.org/ftp/python/2.4.5/Python-2.4.5.tar.bz2
- $ tar jxvf Python-2.4.5.tar.bz2
- $ cd Python-2.4.5
+ $ wget -c http://www.python.org/ftp/python/2.5.4/Python-2.5.4.tar.bz2
+ $ tar jxvf Python-2.5.4.tar.bz2
+ $ cd Python-2.5.4
$ ./configure --prefix=/home/guest/usr
$ make
$ make install
Modified: zope3book/trunk/source/index.rst
===================================================================
--- zope3book/trunk/source/index.rst 2009-02-23 00:13:20 UTC (rev 97123)
+++ zope3book/trunk/source/index.rst 2009-02-23 03:22:50 UTC (rev 97124)
@@ -12,6 +12,7 @@
interfaces
component-architecture
testing
+ virtual-hosting
browser-resouces
browser-pages
content-components
Added: zope3book/trunk/source/virtual-hosting.rst
===================================================================
--- zope3book/trunk/source/virtual-hosting.rst (rev 0)
+++ zope3book/trunk/source/virtual-hosting.rst 2009-02-23 03:22:50 UTC (rev 97124)
@@ -0,0 +1,104 @@
+Setting Up Virtual Hosting
+==========================
+
+Introduction
+------------
+
+One of the most common tasks in the Zope world is to hide Zope behind
+the Apache web server in order to make use of all the nice features
+Apache provides, especially SSL encryption.
+
+Configuration
+-------------
+
+Apache and other Web servers are commonly connected to Zope via
+rewrite rules specified in virtual hosts. Zope needs to interpret
+these requests correctly and provide meaningful output. You might
+think this is easy because you just have to point to the right URL of
+the Zope server. But this is only half the story. What about a URL
+that points to another object? To handle that situation, you need to
+tell Zope what the true virtual hosting address is. In Zope 3 this
+is accomplished using a special namespace called `vh`, which
+specifies the public address.
+
+Before you can start setting up a virtual hosting environment on your
+server, you need to do the following:
+
+1. Make sure Zope 3 is running at http://localhost:8080/site/ or more
+ generically at http://destinationurl:port/path-to-site/.
+
+2. Make sure Apache is running at http://www.example.com:80/ or more
+ generically at http://publicurl:port/
+
+Zope 3 uses its URL namespace capability to allow virtual hosting, so
+that no special component or coding practice is required, which means
+virtual hosting is always available. Generally, namespaces are
+specified using `++namespace++` as one element of the URL. For the
+`vh` namespace, for example, you have `++vh++Public-URL++`. The `++`
+at the end of the URL is specific to the vh namespace. It signals
+the end of the public URL.
+
+The namespace approach has the advantage that you can never lock
+yourself out due to misconfiguration. Some Zope 2 virtual hosting
+solutions have this problem and cause unnecessary headaches. In Zope
+2 you also have to add an additional object. Zope 3 does not use any
+service or utility for this task, which makes virtual hosting support
+a very core functionality.
+
+However, from an Apache 1.3 point of view, the setup of Zope 3 is
+very similar to that of Zope 2. In the httpd.conf file--usually
+found somewhere in /etc or /etc/httpd--you insert the following
+lines::
+
+ Listen 80
+
+ <VirtualHost *:80>
+ ServerAdmin guest at example.com
+ RewriteEngine On
+ RewriteLog /path/to/rewrite.log
+ RewriteLogLevel 9
+ RewriteRule ^/(/?.*) \
+ http://localhost:8080/++vh++http:example.com:80/++/$1 [P,L]
+ </VirtualHost>
+
+In the preceding code block, note the following:
+
+* Line 1: You set up the Apache server for the default port 80.
+* Line 3: You declare all incoming requests on port 80 as virtual
+ hosting sites.
+* Lines 4-10: These are all specific configuration instructions for
+ the virtual host at port 80.
+* Line 9: The virtual host is known as www.example.com to the outside
+ world.
+* Line 7: You define the location of the error log.
+* Line 10: You turn on the Rewrite Engine, basically telling Apache
+ that this virtual host will rewrite and redirect requests.
+* Line 11-13: The code in these lines should really appear on one
+ line. It defines the actual rewrite rule, which says If you find
+ the URL after the hostname and port to begin with /site, then
+ rewrite this URL to
+ http://localhost:8080/site/++vh++http:www.example.com:80/site/++
+ plus whatever was behind /site. For example,
+ www.example.com:80/site/hello.html is rewritten to
+ http://localhost:8080/site/++vh++http:www.example.com:80/site/++/hello.html.
+
+Note that the part after `++vh++` must strictly be of the form
+`(protocol):(host):(port)/(path)` Even if the port is 80 (the
+default), you have to specify it.
+
+At this point you are done setting up Apache. It's easy, isn't it?
+All you need to do now is restart Apache so that the changes in
+configuration will take effect.
+
+Nothing special needs to be configured on the Zope 3 side. Zope is
+actually totally unaware of the virtual hosting setup. Note that you
+do not have to map the URL www.example.com/ to `localhost:8080/`; you
+can choose any location on the Zope server you like.
+
+You can now combine the preceding setup with all sorts of other
+Apache configurations as well (for example, SSL). You just use port
+443 instead of 80 and enable SSL.
+
+Note: One of the current problems in Zope 3 is that the XML
+navigation tree in the management interface does not work with
+virtual hosting because of the way it treats a URL.
More information about the Checkins
mailing list