Set allowed Components in Sourcecode of the Template | Community
Skip to main content
B
Bxxs93
October 16, 2015
Solved

Set allowed Components in Sourcecode of the Template

  • October 16, 2015
  • 3 replies
  • 1005 views

Is there a posibillity to define which components are allowed to place into the Page ? I mean that i could define in the sourcecode of the template, which components the user can use so that i dont have to use anymore the design mode and the Paragraph System for that.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by aschermuly

Hey folks,

I am no friend of the design mode in CQ5. In my opinion it gives too much power to the authors of the system at runtime. If you allow authors to control the inclusion hierarchy via design mode, you might end up with a number of support requests complaining, that component A does not work in the context of parsys X or multicol Y or caroussel Z on template T and so on. The point is, you want to first define which component is allowed in which context and then test exactly that before delivering the software. Nothing more, nothing less. And speaking of testing: Of course you want to test in a test-stage, right? And then? How do you promote your -tested- software package from test to production? Are you going to rebuild the tested design on the production stage by clicking through the design mode? Apparently not..

Thinking of it that way, CQ design is part of the your custom CQ source code, will be versioned in your SCM and packaged and delivered together with your JSP-, Java-, and configuration code. If you agree so far... well just see design as sourcecode. You can import/export it with VLT or use similar techniques such as the Maven Vault Plugin to upload it into your local DEV-system while developing in your favourite IDE.

There are two drawbacks with this approach:

1. The VLT exported XML of the design really looks nasty. But you will get used to it ;-)

2. You cannot use the design mode for anything (more) useful anymore. The design maintained on the production will get overriden when deploying a package containing an "/etc/design" path.

I have seen quite a lot of CQ5 projects. None of it uses the design mode as intended by Adobe, but instead implementing their own inheritance scheme within "/content" for global configurations. Most often not as complex as the "original". But then - hey it's  too complex to comprehend anyway. At leas for the occasional authors i have met.

Though I have quite a strong opinion about that feature I'd like to see a lively discussion on that topic.

Regards

 

Achim

3 replies

aschermuly
aschermulyAccepted solution
October 16, 2015

Hey folks,

I am no friend of the design mode in CQ5. In my opinion it gives too much power to the authors of the system at runtime. If you allow authors to control the inclusion hierarchy via design mode, you might end up with a number of support requests complaining, that component A does not work in the context of parsys X or multicol Y or caroussel Z on template T and so on. The point is, you want to first define which component is allowed in which context and then test exactly that before delivering the software. Nothing more, nothing less. And speaking of testing: Of course you want to test in a test-stage, right? And then? How do you promote your -tested- software package from test to production? Are you going to rebuild the tested design on the production stage by clicking through the design mode? Apparently not..

Thinking of it that way, CQ design is part of the your custom CQ source code, will be versioned in your SCM and packaged and delivered together with your JSP-, Java-, and configuration code. If you agree so far... well just see design as sourcecode. You can import/export it with VLT or use similar techniques such as the Maven Vault Plugin to upload it into your local DEV-system while developing in your favourite IDE.

There are two drawbacks with this approach:

1. The VLT exported XML of the design really looks nasty. But you will get used to it ;-)

2. You cannot use the design mode for anything (more) useful anymore. The design maintained on the production will get overriden when deploying a package containing an "/etc/design" path.

I have seen quite a lot of CQ5 projects. None of it uses the design mode as intended by Adobe, but instead implementing their own inheritance scheme within "/content" for global configurations. Most often not as complex as the "original". But then - hey it's  too complex to comprehend anyway. At leas for the occasional authors i have met.

Though I have quite a strong opinion about that feature I'd like to see a lively discussion on that topic.

Regards

 

Achim

smacdonald2008
smacdonald2008
October 16, 2015

See this AEM topic that talks about different props that you can set:

http://dev.day.com/docs/en/cq/current/developing/components.html

Hope this helps. 

J
Adobe Employee
JustinEd3Adobe Employee
Adobe Employee
October 16, 2015

Achim-

FWIW, I think (and this me, not Adobe, speaking/writing) that it really depends upon the organization. For many organizations, putting design settings in version control is absolutely the right solution. But even if it isn't, it is almost (always?) never appropriate to give *all* authors write access to design settings. Usually we create a group called "site-administrators" or "content-administrators" or something like that. As to your point about putting design settings in version control, my rough guess is that I do this half of the time. When I do this, all authors are locked out of design mode in production (because, to your point, any changes they do make will get blown away at the next code deployment). Personally, I don't consider this to be contrary to the intention of the product - design settings store template-level configuration and that's still the case.

Justin

Terms & ConditionsAccessibility statement

Loading footer...