The old-style ad_form-based category handling (as used for ::xowiki::Page) has several shortcomings: These categories are inserted in every edit page, on every page, the same categories are used, the display style and position can't be changed, when multiple category trees are used, this is a pain.
Therefore, form pages don't follow this hard-coded approach, but allow to include arbitrary categories from arbitrary category trees. The control for category mappings is per-form, and not by xowiki instances. By creating instances of form with category mapping, only these pages of an xowiki instance will have these categories included. The display style is controlled via the form-field class (can be subclassed by applications), it allows the developer to show the category mapping as well in the view mode, etc. When exporting pages to different OpenACS instances, the categories trees will be created at the target machine, when not available there, etc.
Assume we have a category tree "audience" defined. One can use this category tree for form-field classes derived from "enumeration" (having options, i.e. label /internal value pairs), such as such as "checkbox", "radio", or "select") by setting "category_tree=audience" in the form constraints. In these cases, the category tree is used as a source for filling the options. When saving such a page, the usual category mapping / notification etc. will happen. One can certainly use several of these category fields per page.
Example:
Form:
<form>
@myselect1@
@myselect2@
</form>
Form constraints
myselect1:select,default=advanced,category_tree=audience
myselect2:checkbox,horizontal=true,default=advanced,category_tree=audience
@cr_fields:hidden
When more control is needed, one can use this approach as well in xowf, where e.g. the display of categories can be different per state in the life-cycle of the page, or per role of the user, etc.
Does this help?
