Hello Marius,
I think the topic of dynamic configuration of available templates is a very
good topic.
The only problem I see with the solution above is that it might cover only
a subset of the dynamic templates that we might want to configure, and once
we add this mechanism it will be harder to take it back to replace it with
a more generic one. So it would interesting to make a collection of
usecases for dynamic template configuration that we have, to see how many
of them we can cover with the mechanism you proposed (you called the thread
"Brainstorming" :) )
The usecases I had so far or that I can think of:
* template should be available only in documents that have a specific name,
under a grandparent in the tree which is typed (in my case, I had subtrees
dedicated to departments, with an object to configure departments, and
then, in the children of these departments a page always had the same name
(say, "Ideas") and here the Idea template had to be available. This usecase
can be reduced to your case, if we create a class for the Ideas homepage
and restrict the ideas template to this class
* template should be available under a parent but only first level. E.g.
Ideas can be created, they are created as non-terminal because regular
pages need to be linkable under, but an Idea should not be creatable under
an Idea. This would need a different mechanism, what you proposed is not
enough. This usecase can also be reduced to your usecase, provided that the
parentType is about the direct parent (and not ancestor).
* template should be available in a subtree (all descendants) of a page
with a given type, not only as a direct child.
* Edy mentioned in a mail blacklisting, I think I had that case too (having
a page that is the exception to the general rule on the wiki, rather than
the other way around)
* preventing blank XWiki pages from being created in a subtree, only
allowing a structured page (from a template) to be created in a given place
in the tree (kind of like the "add new application entry" of AWM, but
through the + button)
Note that, for the first 2 cases, reducing them to your usecase would mean
to create a class only for this, for binding the provider to it as a
parent. This is not something that an App within minutes does, for example,
although it covers the roughly the same usecase (non structured page is the
parent of multiple structured pages).
One of the ideas I had at some point was allowing a parent to configure the
available templates under it, and not the other way around, but I don't
have much more details about this (would they be preferences?, would it be
an object?, etc).
I would have to think more about this before giving a final answer,
Anca
On Tue, Nov 29, 2016 at 10:23 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:
> Hi devs,
>
> I have an XWiki application that creates two types of pages. Let's call
> them Category and Procedure. The application has two template providers
> that allow the users to create Categories and Procedures anywhere on the
> wiki using the Create Page menu. I would like to restrict the creation like
> this:
>
> * You can create a new Category page either as a top level page or as a
> child of an existing Category page
> * You can create a new Procedure page only as a child of an existing
> Category or Procedure page
>
> Category -> ... Category -> Procedure -> ... -> Procedure
>
> One solution to achieve this is to add a new property to the template
> provider, e.g. "parentType", that specifies the type of pages (XClass
> references) that are allowed as parent. We would use a Database List with
> multiple selection and relational storage. We can use the empty string to
> represent "no parent" (i.e. top level page). An empty list would mean no
> parent type restriction.
>
> Category template provider: {parentType: ["CategoryClass", ""]}
> Procedure template provider: {parentType: ["CategoryClass",
> "ProcedureClass"]}
>
> Do you think this is useful? Do you see any problem with this solution? Is
> it worth implementing?
>
> Thanks,
> Marius
>
