Personal tools
Skip to content. | Skip to navigation
The PloneSoftwareCenter testing harness should only be used and deployed by power users.
Introduction ============ Archetypes is a developers framework for rapidly developing and deploying rich, full featured content types within the context of Zope/CMF and Plone. Archetypes is based around the idea of an `Active Schema`. Rather than provide a simple description of a new data type, Archetype schemas do the actual work and heavy lifting involved in using the new type. Archetype Schemas serve as easy extension points for other developers as project specific components can be created and bound or you can choose among the rich existing set of features. Features -------- * Simple schemas with working default policy. * Power and flexibility with lowered incidental complexity. * Full automatic form generation * Unique Ids for objects * Object References/Relationships * Per Type cataloging in one or more catalogs Documentation ------------- Major resource for documentation is located at plone.org.
AT Content Types ================ Installation ------------ Please read INSTALL.txt for a list of requirements before installing this product. ATContentTypes requires new versions of Python, Zope, Plone and Archetypes. Make sure you've updated all products. Reporting bugs / feature requests --------------------------------- Please use the Plone bug tracker at http://dev.plone.org/plone and use the Content Types component! Comparing CMF types with ATContentTypes --------------------------------------- This is a very rough and short list of differences between the old CMF types and the new ATContentTypes types. * Archetypes: All types are written with Archetypes and have all features default Archetypes based types have like: - autogenerated edit forms based on the schema - referenceable - Easily enhanceable by subclassing or adding fields to the schema - Transformations like restructured text, python source code highlighting, pdf to html, office to html and many more. - plugable validation of fields * Clean and documented API. * Translateable using LinguaPlone. * Dynamic Views: All types are using the new dynamic view FTI that allows you to choose the view template per instance. You can configure the templates in the portal_types tool. This features is used to turn an ordinary folder into a photo album by simple switching to a different view. * Permissions per type and feature: Every type has its own add permission and all features like template mixin have their own modify permission, too. * Numerous small adjustments and enhancements to all types for example: - Images can be rotated through the web and have exif informations - News Items have an image plus caption - Events have a body text - Documents have a history tab to show the last changes as an unified diff view using the ZODB history.
This package provides some further fields and widgets for Archetypes as used by Plone. Most generic are the RecordField/Widget (effectively handling a dictionary) and the RecordsField/Widget (handling a list of records). The most advanced application thereof are the FormattableName(s) fields and widgets. To demonstrate their usage, there are demo content types called ‘WorkingGroup’ and ‘FormattbleNameDemo’ which can be installed using the packages ‘demotypes’ profile. To enable the types after install, go to portal types and make them implicitly addable or include them in some folderish type’s ‘allowed_content_types’.
Introduction ============ ATReferenceBrowserWidget is an add-on to Archtetypes. It adds a new reference widget that allows you to search or browse the portal when creating references. This new widget inherits from the standard reference widget so you can use all it's properties. When you use this widget, there are two buttons presented for each widget. One that opens a popup-window that let's you do the search/browsing and one that let's you clear the reference or selected references (will be in effect after the form's Save). The popop window basically consists of two parts. The top half is a search form and the bottom half is the browser/search results part. Both parts can be turned off or on using the widget's properties. The search part has additional configuration in the widget (see properties below). Properties ---------- The popup window can be configured using the following widget properties: * default_search_index: when a user searches in the popup, this index is used by default * show_indexes: in the popup, when set to True, a drop-down list is shown with the index to be used for searching. If set to False, default_search_index will be used. * size: in case of single-select widget, the default is set to 30. In case of multi-select, default is 8. * available_indexes: optional dictionary that lists all the indexes that can be used for searching. Format: {'<catalog index>':'<friendly name'>, ... } The friendly name is what the end-users sees to make the indexes more sensible for him. If you do not use this property then all the indexes will be shown (I think nobody should allow this to happen!). * allow_search: shows the search section in the popup * allow_sorting: allows you change the order of referenced objects (requires multiValued=1) * allow_browse: shows the browse section in the popup * startup_directory: directory where the popup opens. Optional. When omitted, the current folder is used or in the case where a property refwidget_startupdirectories under site_properties is found it is searched for a startup_directory. Property is a lines field having the following format:: path1:path2 path1 is the path where all widgets being under it set startup_directory to path2 if no startup_directory is set. * startup_directory_method: the name of a method or variable that, if available at the instance, will be used to obtain the path of the startup directory. If present, 'startup_directory' will be ignored. * restrict_browsing_to_startup_directory: allows you to restrict the breadcrumbs ('allow_browse' property) to contents inside the 'startup_directory' only. So you are not able to walk up in the hierarchy. (default: 0 = disabled) * image_portal_types: specify a list of image portal_types. Instances of these portal types are being previewed within the popup widget * image_method: specifies the name of a method that is added to the image URL to preview the image in a particular resolution (e.g. 'mini' for thumbnails) * show_review_state: allows you to display the workflow state for objects (off by default) * show_path: display the relative path (relative to the portal object) of referenced objects * only_for_review_states: items are only referencable if their workflow state matches the ones a specified (default: None = no filtering by workflow state) * history_length: enable a history feature that show the paths of the last N visited folders (default : 0 = no history) * force_close_on_insert: closes the popup when the user choses insert. This overrides the behavior in multiselect mode. * base_query: defines query terms that will apply to all searches, mainly useful to create specific restrictions when allow_browse=0. Can be either a dictonary with query parameters, or the name of a method or callable available in cotext that will return such a dictionary. This add-on comes with an example content type that uses this widget. You can enable the installation of the type by uncommenting the appropriate line in Install.py under Extension. See ATReferenceBrowserDemo.py. Design notes ------------ Both the templates (widget and popup) are prototypes. There are still some inline styles, especially in the popup because I didn't want to tweak with plone's css stuff and I didn't want to do hacking and tricking to incorporate a stylesheet myself.So, that's still a point of interest. Furthermore I made some design decisions. Right now, in the popup window, all objects are shown (when browsing) and objects that may be referenced to are bold and the other objects are greyed out. I chose to show the non-referenceable objects too because they may be an important part of the context that help the user search for the desired objects to browse to. Another thing that I chose for is that in case of a multi-value widget, the popup remains open so that you can continue to add references without having to reopen the popup over and over again. Problem is that you have to close the window yourself. This may change if it turns out to be an annoyance. A thing that is more related to forms in general is that the items in the multiselect listbox need to be selected before Save is clicked otherwise only the selected items are submitted. That kinda sucks usability-wise because now the user basically has to make two selections: first by choosing the items in the popup and secondly by selecting them again in the listbox. Right now I made it so that the items are selected by default but if the user starts clicking in the list, then there might be an issue. Btw, the inandout widget has the same problem. Best would be to select all the items in a script just before the form is submitted so that the complete list is submitted. But that requires changes in the base_edit form I think. But it's something to think about since there are now already two widgets that needs to be prepared like this (inandout and this one, haven't looked at picklist though, could have the same problem). Anyway, have fun with it and if you have suggestions please let me know. If you see problems, please fix them when you can.