+1
Thanks,
Caty
On Tue, Nov 29, 2016 at 12:44 PM, Eduard Moraru <enygma2002(a)gmail.com>
wrote:
+1
This would obviously work only for non-terminal/nested pages.
You might also want to think about handling excludes (i.e. all parent types
*except* this and that), and probably the case when you have both includes
and excludes.
Also, the create UI (among others) would need to change a bit on the parent
selector (once you select a template provider with such restrictions),
probably by filtering the tree modal to show only pages of the restricted
type.
Thanks,
Eduard
On Tue, Nov 29, 2016 at 12:24 PM, Vincent Massol <vincent(a)massol.net>
wrote:
On 29 Nov 2016, at 10:23, Marius Dumitru Florea
<
mariusdumitru.florea(a)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?
If you need it then it means there’s a need (even though possibly not a
very common one). The only downside I see is the complexity it adds for
the
user. We may want to think about an Advanced
section in the template
provide UI screen and move advanced options there.
Thanks
-Vincent
Thanks,
Marius