Stereotype overview
Overview of all stereotypes you can use. (Note 2005-08-25: stereotypes are complete, but there are some empty descriptions). This pages is autogenerated with 'python UMLProfile.py'. UPDATED 2007-01-19 (svn trunk).
class
- CMFMember
- The class will be treated as a CMFMember member type. It
will derive from CMFMember's Member class and be installed as a
member data type. Note that you need to install the separate
CMFMember product. Identical to
<<member>>. - archetype
- Explicitly specify that a class represents an Archetypes type. This may be necessary if you are including a class as a base class for another class and ArchGenXML is unable to determine whether the parent class is an Archetype or not. Without knowing that the parent class in an Archetype, ArchGenXML cannot ensure that the parent's schema is available in the derived class.
- btree
- Like
<<folder>>, it generates a folderish object. But it uses a BTree folder for support of large amounts of content. The same as<<large>>. - content_class
- TODO
- doc_testcase
- Turns a class into a doctest class. It must subclass a
<<plone_testcase>>. - field
- TODO
- folder
- Turns the class into a folderish object. When a UML class contains or aggregates other classes, it is automatically turned into a folder; this stereotype can be used to turn normal classes into folders, too.
- hidden
- Generate the class, but turn off "global_allow", thereby making it unavailable in the portal by default. Note that if you use composition to specify that a type should be addable only inside another (folderish) type, then "global_allow" will be turned off automatically, and the type be made addable only inside the designated parent. (You can use aggregation instead of composition to make a type both globally addable and explicitly addable inside another folderish type).
- interface_testcase
- Turns a class into a testcase for the interfaces.
- large
- Like
<<folder>>, it generates a folderish object. But it uses a BTree folder for support of large amounts of content. The same as<<large>>. - member
- The class will be treated as a CMFMember member type. It will
derive from CMFMember's Member class and be installed as a member
data type. Note that you need to install the separate CMFMember
product. Identical to
<<CMFMember>>. - mixin
- Don't inherit automatically from "BaseContent" and so. This
makes the class suitable as a mixin class. See also
<<archetype>>. - odStub
- Prevents a class/package/model from being generated. Same as
<<stub>>. - ordered
- For folderish types, include folder ordering support. This will allow the user to re-order items in the folder manually.
- plone_testcase
- Turns a class into the (needed) base class for all
other
<<testcase>>and<<doc_testcase>>classes inside a<<test>>package. - portal_tool
- Turns the class into a portal tool.
- python_class
- Generate this class as a plain python class instead of as an Archetypes class.
- remember
- The class will be treated as a remember member type. It will derive from remember's Member class and be installed as a member data type. Note that you need to install the separate remember product.
- setup_testcase
- Turns a class into a testcase for the setup, with pre-defined common checks.
- stub
- Prevents a class/package/model from being generated.
- testcase
- Turns a class into a testcase. It must subclass a
<<plone_testcase>>. Adding an interface arrow to another class automatically adds that class's methods to the testfile for testing. - tool
- Turns the class into a portal tool. Similar to
<<portal_tool>>. - variable_schema
- Include variable schema support in a content type by deriving from the VariableSchema mixin class.
- vocabulary
- TODO
- vocabulary_term
- TODO
- widget
- TODO
- zope_class
- Generate this class as a plain Zope class instead of as an Archetypes class.
dependency
- value_class
- Declares a class to be used as value class for a certain
field class (see
<<field>>stereotype).
interface
- z2
- Generates a Zope 2 Interface inheriting from Zope.Interface.Base.
- z3
- Generate this interface class as zope 3 interface. This will inherit from zope.interface.Interface.
method
- action
- Generate a CMF action which will be available on the object. The tagged values "action" (defaults to method name), "id" (defaults to method name), "category" (defaults to "object"), "label" (defaults to method name), "condition" (defaults to empty), and "permission" (defaults to empty) set on the method and mapped to the equivalent fields of any CMF action can be used to control the behaviour of the action.
- form
- Generate an action like with the
<<action>>stereotype, but also copy an empty controller page template to the skins directory with the same name as the method and set this up as the target of the action. If the template already exists, it is not overwritten. - portlet
- Create a simple portlet page template with the same name as the method. You can override the name by setting the "view" tagged value on the method. If you add a tagged value "autoinstall" and set it to "left" or "right", the portlet will be automatically installed with your product in either the left or the right slot. If the page template already exists, it will not be overwritten.
- portlet_view
- Create a simple portlet page template with the same
name as the method. You can override the name by setting the "view"
tagged value on the method. If you add a tagged value "autoinstall"
and set it to "left" or "right", the portlet will be automatically
installed with your product in either the left or the right slot. If
the page template already exists, it will not be overwritten. Same
as
<<portlet>>. - view
- Generate an action like with the
<<action>>stereotype, but also copy an empty page template to the skins directory with the same name as the method and set this up as the target of the action. If the template exists, it is not overwritten.
model
- odStub
- Prevents a class/package/model from being generated. Same as
<<stub>>. - stub
- Prevents a class/package/model from being generated.
package
- odStub
- Prevents a class/package/model from being generated. Same as
<<stub>>. - stub
- Prevents a class/package/model from being generated.
- tests
- Treats a package as test package. Inside such a test package,
you need at a
<<plone_testcase>>and a<<setup_testcase>>.