What is the purpose of allowed parents and allowed children property while creating a cq template?
The description in documentation simply says "Path of a component that is allowed to be a parent of this component"/"Path of a component that is allowed to be a child of this component".
What is the importance of these properties?
These properties allows you to set some contract of structure of pages in you project.
For example:
you have 3 templates (and corresponding pages with this templates):
template-1: allowedChildren="[template-2]"
template-2: allowedChildren="[template-3]"
template-3: allowedChildren="[]"
Then in siteadmin, you will be able to create:
under page with template "template-1" only pages with template "template-2",
under page with template "template-2" only pages with template "template-3",
under page with template "template-3" you will not be able to create any page.
Related
I'm trying to create separate templates for webpages with either a single or a double column structure. Currently my webpage only has one template, placed on the root page which is used by all its subpages.
However, I cannot find the template in myextension/Resources/Private/Templates as this folder is empty. Where is the template located in my extension and where should I add the alternative template?
I assume you use "fluid_styled_template"? Then the templates are in that respective core directory, in "Resources/Private".
If you want to manipulate them, copy them to your sitePackage into "Resources/Private/Extension/fluid_styled_content" (that at least is one of the recommended ways where to place it) and override the TypoScript that "fluid_stlyed_content" provides.
templateis not unique in TYPO3 context. we have:
typoscript records, maybe also as files which are included in a record or by PHP
HTML files, which are define a markup for parts of the website
they can be differed in
Marker-Templated. The old and less and less used kind with markers and subparts as placeholders for data defined in typoscript
Fluid templates. The modern kind with control structures and data objects
with the statemant
my webpage only has one template, placed on the root page
it is not clear what you mean:
records are defined in pages -> typoscript templates
maybe you mean in the root page a template is selected. that could mean HTML templates, probably fluid templates as the path myextension/Resources/Private/Templates matches the usual structure for fluid templates.
assuming fluid templates:
Templates are search in a list of folders. This list is managed in typoscript.
Any usage has it's own list and the list of your main/page template probably is at page.10.templatePaths. You can look for it in the TSOB (Typoscript Object browser)
If the list consists of one entry only you have only the basic config.
As the list of folders is consulted each time a template (,partial, layout) is accessed and only that file with matching name in the folder with highest priority is taken you can add your folders with higher numbers in the list so you do not need to change the original files (use copies in your folder to modify) or add files to the original folder (inside of other extensions).
So you need two things:
create your template file in an appropriate folder
(ext:myextension/Resources/Private/Templates sounds good)
and add this folder to the list of folders for these templates
(e.g. page.10.templatePaths.20 = EXT:myextension/Resources/Private/Templates)
When generating forms with the form module the corresponding yaml files get stored in fileadmin/user_upload.
Now I want to integrate those yaml files into my sitepackage and thus into my CVS. Where is the correct place for them? In the example extension they are stored in Resources/... while I would think they have to go into Configuration/Yaml
And how do I configure the form extension to search them in that place?
While it's basically a matter of taste where exactly one saves his form definitions, I try to separate form configuration and form definitions.
From the official documentation:
[...] the form configuration allows you to define:
which form elements, finishers, and validators are available,
how those objects are pre-configured,
how those objects will be displayed within the frontend and backend.
In contrast, the form definition describes the specific form,
including
all form elements and their corresponding validators,
the order of the form elements within the form, and
the finishers which are fired as soon as the form has been submitted.
Furthermore, it defines the concrete values of each property of the mentioned aspects.
So, for more clarity I save all form configuration in a sitepackage under Configuration/Yaml/ and the form definitions under Resources/Private/Forms, neighbouring the templates.
I wrote a full tutorial how to use custom templates with EXT:form, which also includes the answers to your question.
In short:
Register YAML configuration with TypoScript in your extension root folder as ext_typoscript_setup.txt (as recommended1)
plugin.tx_form.settings.yamlConfigurations {
100 = EXT:my_extension/Configuration/Yaml/CustomFormSetup.yaml
}
module.tx_form.settings.yamlConfigurations {
100 = EXT:my_extension/Configuration/Yaml/CustomFormSetup.yaml
}
CustomFormSetup.yaml – setting up a new storage path
TYPO3:
CMS:
Form:
persistenceManager:
allowedExtensionPaths:
10: EXT:my_extension/Resources/Private/Forms/
allowSaveToExtensionPaths: true
allowDeleteFromExtensionPaths: true
1TypoScript inside an ext_typoscript_setup.txt is automatically loaded in both frontend and backend of your TYPO3 installation directly after installing your extension. This differs from other TypoScript files, which have to be included manually, e.g. as static templates. See official Form Framework documentation.
I'd suggest Resources/Private/Forms for your form definitions. The form extension clarifies how to register additional form definition paths.
In AEM speak - what is the exact conceptual difference between between currentstyle and currentdesign objects available after including the tag in template / component?
Just to add some clarify to what's already here:
Global content (that is, component values that are common across multiple instances of the same template) are stored as "styles" and edited via a "design dialog".
They are stored as follows:
/etc/designs/<design>/jcr:content/<template>/<component>
So, for the component logo in the template homepage, using the default design:
currentStyle is /etc/designs/default/jcr:content/homepage/logo
currentDesign is /etc/designs/default
currentStyle is of type com.day.cq.wcm.api.designer.Style(1) whereas currentDesign is an instance of com.day.cq.wcm.api.designer.Design (2).
The Design object contains information about the design that is used with the current object, it is most of the time set in the cq:designPath property of the page's template.
If you have the Design object, you can get Style objects for each included Cell(3) from it. On the other hand you can get the surrounding Design, if you have the Style.
So the Design is something like a container object for the Styles used in the included Cells.
In this path
/etc/designs/geometrixx/jcr:content/page/image
image is a Cell, the design path is /etc/designs/geometrixx and the Style object attached to the Cell object has two properties: maxHeight and maxWidth.
(1): https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/index.html?com/day/cq/wcm/api/designer/Design.html
(2): https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/index.html?com/day/cq/wcm/api/designer/Style.html
(3): https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/index.html?com/day/cq/wcm/api/designer/Cell.html
I would say it is more like:
/etc/designs/<design>/jcr:content/<resource-type-of-page>/<component>
so that different templates having the same page resource type will share the same style
I'm currently using TYPO3 6.1.8-dev to build a flux/fluidpages (GitHub Master) powered template and managed to have it running on the root pages, though, I have issues with the sub-pages, in terms of value inheritance.
I've implemented the following scenario:
A Flux Flexform Configuration is used, if there is no TypoScript override variable set, retrieved from TS Setup.
The Flexform fields have the following names:
gridsettings.topRow_use (checkbox)
gridsettings.topRow_cols (select)
After the Flexform Configuration, I use these fields to build the backend grid, after I mix in some static values of a TypoScript configuration with:
{v:iterator.merge(a:'{gridsettings}', b:'{tssettings}') -> v:var.set(name:'gridsettings')}
This works for every page with explicit settings in the page properties, but not for sub-pages, which should just inherit the parents settings.
In the case of sub-pages the gridsettings array is null, and only my TS settings are visible.
I'd like to have the convenience to just create a new sub-page, and add content to the inherited backend-layout grid without any further interaction in the page settings.
How can I solve this issue?
Two parts to this:
1) To solve the problem that you manually must merge TS with FlexForm settings, use the prefix settings. in all your field names. This special, reserved variable name will be used by both Extbase and Fluid without requiring you to transfer it, and your FlexForm settings will be merged (on top of) your TS settings.
2) Inheritance requires the exact same page template on parent and child page, or that child page sets parent decides as option for which template to use. There could be other causes for failing inheritance (for example, the use of default on any of your fields - since you don't include your Flux form structure this is impossible to determine) but mismatching parent/child template is the most common. Also, make sure your Flux is up-to-date; there have been bugfixes recently related to inheritance.
I have added a new selection type field "Theme" in page properties>Basic.
Now if I add a new page using the same template in WCM, there also I
am getting the option "Theme", which is quite obvious.
Is there any way by which I can hide the field in child page?
P.S this is happening because I am using the same template for the child page.
You can't use the same template and have the page property dialogs be different.
What you can do is overload the dialog
create a new template and corresponding resourceType component that
inherit from your current.
copy the dialog, or tab that you want to be different from the lowest parent of the component. Make sure the dialog is the only node under the component.
Make the changes you want to the dialog.
You would then have to include code in the page jsp to get the parent page property something like:
// if the parent page is always a certain level below the root you can use
// currentPage.getAbsoluteParent(3); to get the third page down from the top
// of the current path tree.
Page parentPage = currentPage.getParent();
ValueMap parentPageProperties;
if (parentPage != null) {
parentPageProperties = parentPage.getProperties();
}
// This tries to get the property 'theme' from the current page. If that fails
// then it tries to get the property from the parent page. If that fails it
// defaults to blank.
theme = properties.get("theme", parentPageProperties.get("theme", ""));
A quick solution would also be to create a second set of template / page component. Let's assume you've got template A, that uses page component B as resource type:
Create template X and play with allowedParents allowedChildren and allowedPaths properties so that the two are exclusive (actual solution depends on your content architecture)
Give X same title as A
Create page component Y that extends B, and defines it's own dialog
Make Y's dialog re-use any tabs from B using xtype=cqinclude (see foundation page's dialog for reference)