[MGNLSTK-407] Make template hierarchy configurable (as opposed to pluggable) Created: 30/Jun/09  Updated: 23/Jan/13  Resolved: 30/Dec/11

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: concept
Affects Version/s: 1.1
Fix Version/s: 1.5

Type: New Feature Priority: Major
Reporter: Christian Ringele Assignee: Christian Ringele
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLSTK-691 Glossary Letter Template not availabl... Closed
is depended upon by MGNLSTK-436 Make inplace templating more usable Closed
relation
is related to MGNLSTK-546 template availability: add the class ... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

Explanation:
When creating in Website a new page, a template has to be chosen by the dropdown. STK limits what can be chosen by its hierarchy level & parent template type:

  • First level only a template choose able with category 'home'
  • Second level (below home) only a 'section' template can be added.
  • On third level (below first section) 'section' and 'content' templates can be added.

I want to rise here a discussion, if this should be dynamically configurable over the site configuration or not:

  • This behavior is defined in the class TemplateAvailability.java
  • For making a small change of this behavior, the class 'TemplateAvailability' has to be overwritten.

One use case is for example:

  • In Burger it should be allowed, to add a article page directly to the home page, without having a section page in between.

Wouldn't it make sense, to have this definable directly in the site configuration?



 Comments   
Comment by Christian Ringele [ 01/Jul/09 ]

To be more precise:
If it would make sense to provide this as a configuration, for example within the site configuration.
So that there is no need to overwrite the TemplateAvailability.java.

One 'pro' argument:
If users can define over configuration of template new categories, this mechanism should be configurable too.
Or otherwise adding a new template category, a JavaClass adaption is needed.

Comment by Philipp Bärfuss [ 28/Jul/09 ]

I don't understand. The template availability is configured under /site/templates/availability

Are we talking about a more fine grained configuration? Then the title of the issue would be misleading.

Comment by Christian Ringele [ 12/Aug/09 ]

@PH: Yes, the title was missleading.
I changed the title and added a more precise explanation of what i meant.
I hope it's now more clear.

Comment by Christian Ringele [ 12/Aug/09 ]

Second use case:
Alvaro came yesterday to me, asking how this behavior could be changed.
A client, which tried to build within Magnolia/STK (not using an IDE) a site, asked this.

STK is built up the way, that you can configue your site and edit the templates&resources within STK. NO need of an IDE for that.
But changing the the 'dopdown behavior' described above needs a Java class subclassing/overwriting.

Comment by Christian Ringele [ 14/Sep/09 ]

I talked on the conference with Aperto about this use case.
The struggled with this too meaning:
When demonstrating to customers and on customer try outs it was unhandy and hard to understand for the customer, that customized categories don't show up, and that this behavior can only be changed by Java code.

Comment by Christian Ringele [ 30/Dec/11 ]

Closed to our experience, that:

  • STK site definition has already enough configurations
  • And stringer: a recursive configuration in a tree view is more confusing then helping.
Generated at Mon Feb 12 07:26:43 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.