Archetypes and ATContentTypes, part 2: Templates and customization slots

Created January 25, 2007 by

We will now look at how these schemas are called by the edit templates, and point out slots and hooks which Archetypes have left for customization.

Let us return to our Image type: selecting this type in portal_types and looking at properties will show that atct_edit is the default editing form, as it is for all ATContent Types. There is only one line in atct_edit, calling the master macro in the base_edit template. The main function of this macro is to call other macros for different parts of the page: most of these macros are located in the edit_macros file"

  • the top slot gets filled by edit_macros/topslot
  • javascript is looked after by archetypes_custom_js/macros/javascript_head
  • css: edit_macros/css
  • header,description, body,footer all in edit_macros.

So, let’s take a closer look at some of the macros in edit_macros:

Macros in edit_macros

  • header generates document actions like print, rss ect via the document actions macro and generates a title for the edit form with the name ‘Edit (Content Type)’
  • byline generates the byline, via the document_byline macro
  • archetypes_schemata_links: not sure what this bit does yet 🙂
  • typedescription returns the description of the content type, which will appear at the top of the page under the title. It can be edited in portal_types without customizing, but the resulting edit will only appear in the ‘add item’ listng and not the edit form where you want it.
  • body: This is where the main action happens: for us, the interesting part of this macro is:
<metal:block define-slot="extra_top" />

        <metal:block define-slot="widgets">
          <tal:fields repeat="field fields">
            <metal:fieldMacro use-macro="python:here.widget(field.getName(), mode='edit')" />
          </tal:fields>
        </metal:block>

        <metal:block define-slot="extra_bottom" />

If we look at the above piece of code, it is essentially asking us to go through each field of the image schema and get its widget (For more on schemas and widgets, see part 1). Note the two slots ‘extra-top’ and ‘extra-bottom’ if you want to put something above or below the image widgets without changing the template.

The body macro also contains a good bit to do with sending the form, and the buttons. It contains a block defining Previous, Next (these automatically appear if there is more than one page in the edit form) Save and Cancel buttons. There is also a slot called ‘extra-buttons’ if you need to make any more buttons for your form, so you can make them in another template.

Whilst Archetypes does have a range of customization slots, one cannot make any easily reversible customizations to the schema as one might with a page template, as the files containing the schema are not stored on the zodb.

One is then left with the prospect of defining a new Archetype derived from your old one, either in a new product or as part of an existing one. Then in Extension/Install.py the portal_types tool can be manipulated to use the new type, or alternatively you can set that the old type can be just not globally allowed while the new type would be. Before you run into that course of action, there might be extra hooks for customization I havent found: for example, Villiam pointed out a post_validate hook for validators.

I am very grateful to Villiam Segeda, our resident Archetypes expert, for teaching me what little I know.

Comments are closed.