Great XLink Primer

Melonfire have a great xlink primer.

Plone and Subversion

When making a plone product in subversion, setup the repository thus:

package.module/trunk/package.module/package/module

This will allow you to checkout your product into the src directory:

http://svn.example.com/svn/package.module/trunk/package.module

Don't forget to do this after running bootstrap.py but before running the buildout.

Create a custom content type in Plone3

paster create -t plone <somepackage.somemodule>

Then edit the buildout.cfg to record the egg in the:

eggs section,(somepackage.somemodule)
develop eggs section (src/somepackage.somemodule)
and the instance zcml section (to put the zcml slug in)
then:-

./bin/buildout -o

Create the initiailize function in the somepackage.somemodule.__init__.py file. Other examples say this is also the place where you can create a MessageFactory object.

The initialize function makes reference to the content object being created so you need to have that created.

$> mkdir content
$> cd content
$> touch contentthing.py

Also, it is suggested in the Optilude book that you create a config.py file to contain various constants to enable easier future reference.

The body of the contentthing.py breaks down into a few sections.

Firstly you define a schema for the content type. The schema defines the what parts the content type has, and what type of thing those parts are. The schema begins by copying the already existing general purpose schema using atapi.ATContentTypeSchema.copy() and to this you then add your own, using atapi.Schema().

Once the schema has been defined it has to be finalized. This requires hints as to whether or not the schema is folder-like, and whether or not conversations can be moved (don't understand this part).

After the schema is in place one may then move on to define the content type class proper.

The class inherits from base.ATCTContent.

The class has a schema attribute. It should be no surprise that the schema is set to the one just created. The class is also given a portal_type attribute. This value is a string value, presumably used for UI purposes. The class also calls the zope.interface.implements() method. Previously you will have defined a zope style interface for the product. I did this, although I set the interface to pass. I'm not sure why the zope interface is required when there is already an Archetypes schema. Perhaps they are just preparing for the future?

The class is next given a series of attributes. These attributes are made to have the same names as those created in the schema, but are all initialized using methods such as atapi.ATFieldProperty().

Finally, after trhe class has been defined, the module registers the class thus:
atapi.registerType(<classname>, PROJECTNAME)

At this stage, if you try to install the content type to plone, you should find that the restart succeeds, and that the product appears in the product section of the ZMI. However, the product will be invisible to Plone.

We make the product visible to plone by going the the package's configure.zcml file and using the generic setup extension profile mechanism. A good example of this is on page 71 of the Professional Plone Development book.

Restarting zope at this point will allow the product to appear in the "Add New Products" section of the "Site Setup" page in the Plone interface.

Installing the product should proceed without error. The next hurdle will be that the product is not present in the "Add new ..." drop down menu in the Plone user interface.

We make the product appear as addable in the UI by the simple expedient of going to the profile/defaults/types/<sometype>.xml and ensure that global_allow property is set to true.

Mysite PDF on Plone, Zope and the CMF has a useful description on page 14 of the role of layers and skins:

This is a concept to extend name/method look up that the CMF adds to Zope. I like to think of this as having multiple
different search paths to choose from. Suppose you have a number of folders (or layers as they are called in the
context of skinning) f1, f2, ..., fn holding different versions of the same set of methods (but there is no need to
have each method in each folder). Now you define a skin by saying: for skin A first look in f1 , then look in f2 , then
in f3 whereas skin B might be defined as: first look in f2 , then in f3 , then in f1 and so on. That way you can
provide, e.g., different designs to choose from (for example by having different style sheets in the different folders).
But the concept is more powerful than to just provide different designs. In principle you can use it to provide multiple
object behaviour , meaning that you can make objects behave differently in response to particular method calls if the
method is implemented to do different things in the different skin folders.
Under the hood, the skins tool works by extending the acquisition context of all objects within a CMF site. But you
cannot tell this from looking at the URL in your browser, because this is done "silently" when traversing a so-called
SkinnableObjectManager , a class that the PloneSite class itself inherits from.

There is also a useful discussion from Andy McKay's book, referenced here, on skins and layers.

Set Debug Mode in Plone

Firstly, set the debug option in buildout.cfg to on (or do this directly in the zope.conf file).

Secondly, from the Zope Management Interface screens look for three tools:-

• portal_css
• portal_javascript
• portal_kss

In each case, tick the box to enable debug/development mode.

Buildout Options

When you run:-

./bin/buildout -h

this is what you get:-

Usage: buildout [options] [assignments] [command [command arguments]]

Options:

  -h, --help

     Print this message and exit.

  -v

     Increase the level of verbosity.  This option can be used multiple times.

  -q

     Decrease the level of verbosity.  This option can be used multiple times.

  -c config_file

     Specify the path to the buildout configuration file to be used.
     This defaults to the file named "buildout.cfg" in the current
     working directory.

  -U

     Don't read user defaults.

  -o
  
    Run in off-line mode.  This is equivalent to the assignment 
    buildout:offline=true.

  -O

    Run in non-off-line mode.  This is equivalent to the assignment 
    buildout:offline=false.  This is the default buildout mode.  The
    -O option would normally be used to override a true offline
    setting in a configuration file.

  -n

    Run in newest mode.  This is equivalent to the assignment
    buildout:newest=true.  With this setting, which is the default,
    buildout will try to find the newest versions of distributions
    available that satisfy its requirements.

  -N

    Run in non-newest mode.  This is equivalent to the assignment 
    buildout:newest=false.  With this setting, buildout will not seek
    new distributions if installed distributions satisfy it's
    requirements. 

  -D

    Debug errors.  If an error occurs, then the post-mortem debugger
    will be started. This is especially useful for debuging recipe
    problems.

Assignments are of the form: section:option=value and are used to
provide configuration options that override those given in the
configuration file.  For example, to run the buildout in offline mode,
use buildout:offline=true.

Options and assignments can be interspersed.

Commands:

  install [parts]

    Install parts.  If no command arguments are given, then the parts
    definition from the configuration file is used.  Otherwise, the
    arguments specify the parts to be installed.

    Note that the semantics differ depending on whether any parts are
    specified.  If parts are specified, then only those parts will be
    installed. If no parts are specified, then the parts specified by
    the buildout parts option will be installed along with all of
    their dependencies.

  bootstrap

    Create a new buildout in the current working directory, copying
    the buildout and setuptools eggs and, creating a basic directory
    structure and a buildout-local buildout script.

  init

    Initialize a buildout, creating a buildout.cfg file if it doesn't
    exist and then performing the same actions as for the buildout
    command.

  setup script [setup command and options]

    Run a given setup script arranging that setuptools is in the
    script's path and and that it has been imported so that
    setuptools-provided commands (like bdist_egg) can be used even if
    the setup script doesn't import setuptools itself.

    The script can be given either as a script path or a path to a
    directory containing a setup.py script.
    

Plone 3 Setup

One time only

Get python 2.4 something.

$> wget http://peak.telecommunity.com/dist/ez_setup.py
$> python ez_setup.py
$> easy_install ZopeSkel

• PEAK


• ZopeSkel

Do this for each project

paster create -t plone3_buildout 

• Paster

At this point you are asked lots of questions for example about
the path where zope/plone is to be or is already installed
the user name/password for the install, the port number etc.
and some options about debug settings.
This information is used ot build the buildout.cfg file.

After this runs, you have a bootstrap.py file, and src and product directories, and a buildout.cfg file and a var file, all of which are empty.

Then:

cd 
python bootstrap.py

After running bootstrap you have an eggs folder, a develop-eggs folder, a parts folder, and a bin folder. The eggs folder contains some of the PEAK tools:- the setuptools egg and the zc.buildout eggs. The bin folder contains the buildout executable. The parts folder is empty, as is the develop-eggs folder.

• zc.buildout

You are now ready to run the buildout, but at this point it may be worthwhile reviewing the buildout to see if any changes are merited. Possibly none are. Also note, you can run the build out over and over again and it will not eat your Data.fs file, the holy of holies of zope/plone development.