Let suppose that in Magnolia's Page application you have few pages with instances of component "A" which have property dialog. These pages are published to Public server.
later you decide to change structure of this properties (add fields or for example change image field to array of images)
to do so you would modify component's dialog yaml file (add/modify fields) and component's template ftl file to render these changes
Question: - will this destroy previously created pages with instances of component "A"? i.e. if you need to modify component's properties it's better to create new component instead of modify existing?
It's fine to modify existing component, as long as you take care of the fact that existing instances will not have any values for newly added properties/fields. So in template you need to expect that you might get empty values and provide good defaults to cover that case. So technically, you can modify the component just fine.
Whether it is better to create new component or modify existing one depends more on the business needs. Is it desired pages to see new component look & get new fields in pages that already use the component or are those changes relevant just for new pages in which component will be used?
Another consideration is the more components you have, the harder it would be for editor to pick the right one from the ever growing list. However the more functionality you cram into single component, the more complex and difficult to test it would become and harder it would be to replace it with something else in the future.
Related
Is there a way to include a css file with a view model and not a view?
I've tried looking at the nativescript documentation and have not been able to find the answer
This view model is used/presented in a number of different views so adding the css classes to each view folders css file works but makes it harder to maintain as I now have duplicate css classes floating about in different folders.
Alternatively i could put it in the global css file however this can quickly become too large of a file if i need to do this for multiple view models/ styles.
Use case:
A list of items that get validated in an async manner which will change css class based on status (simple use case example background-color changes to: white/red/yellow/green).
please note that I am coding a non-angular app.
i need your help, I have created in Share a new type folder, called "TanFolder". it's on documentLibrary. I would like, when i create this folder, three other folders will be created automatically within it
Example: every time i create a TanFolder three folders will be automatically created in this tanFolder
the problem is that, I do not know where I need to make code changes
thank you
Several approaches are possible. It depends on the use case.
You can use space templates. These are defined in Data dictionary/Space templates and can be added in any site using the Create button in the toolbar. Just create a folderstructure once inside the space templates folder and you can reuse it every time. No code changes needed.
Or you can create a custom Rule for your new content type which executes a javascript that creates the subfolders every time a new TanFolder is created. Would require just a small javascript. The rest is condiguration.
A third approach is to use Alfresco Behaviours. This requires some java code and a bean declaration. If you are starting with Alfresco I would try the first two approaches first.
Can I publish component presentation without adding it to a page? The answer seems to be yes. I have a component that is not on any pages. I published just that component and the component presentation ended up at my destination, but where is the component picking up the template? Is it picking it up via the LinkedSchema tab in the template? I did link the schema used for the component to a template.
Thanks
You guessed right. A component is published as a dynamic component presentation (so without a page) if there are one or more component templates that are:
a. linked to the schema the component is based on
b. marked as 'publish as a dynamic component'
Yes, that's right. When you create a component template, you specify the linked schemas which can use this template. Publishing a component with out adding to a page is called dynamic component presentation. In component template general tab, you could specify this as "Published as dynamic component" for the field component presentations based on this template. If you have value as "Publish embedded on a page", your component presentation is static meaning you have to associate this component with page to get it published. Dynamic component presentations makes use of content broker database to query the data and to display it in website. However components embedded on a page would be static and would be served from file system (instead of database). Hope it helps!
When you clone a default component in the libs folder to your apps one, it's supposed to override the former, but for me it's duplicating the component's options in the sidekick.
I made a duplicate of libs/foundation/components/parsys/ and moved it to apps/-site-/components/content so that I could add functionality to it. However, when I view the Columns component in the sidekick (which is the /parsys/colctrl/ component) it duplicates my options. I now have "Two Columns", "Three Columns", and "Column Control" list twice.
Ideas?
To override the stock component (instead of create a new component with the same functionality) you have to have the same path but with /apps instead of /libs
Example for parsys - copy it from
/libs/foundation/components/parsys
to
/apps/foundation/components/parsys
An even better way is to create a new component at /apps/foundation/components/parsys and only override the parts you want to change.
If you change the path, you're basically creating a new component - CQ5 has no way of associating the two. It works on a path basis to overlay the /apps on top of /libs.
Hope this helps,
Antony
You will want to use the sidekick's Design Mode to remove the foundation components from the list of candidate components for your pages. See Gabriel Walt's answer to this question: Adobe CQ5's sidekick is empty (no components shown).
Since you've duplicated the component it shows up twice in sidekick -- but you can add the duplicate to a different component group other than "general". In the .content.xml file for the component add componentGroup="Your Component Group" and your component will then show up there; the original will still show in the general component group.
I want to change some of the built-in styles contained in a Plone 4 installation, and a reading of the docs tells me that the best way to do this is to copy the base_properties.props file to SOMEWHERE in the file tree, and then to modify it.
A thorough search of this Plone system shows two base_properties.props files, neither of them in the file tree of my custom skin. So, I guess the first problem is to figure out WHICH of these files is active. I am not sure - how to tell easily?
The next problem is WHERE to copy this file into my custom skin file tree. The existing folders are: Skins\custom_images, Skins\custom_js, Skins\custom_styles, Skins\custom_templates. Should the base_properties file then go in the Skins\ root?
I want to change the defaults for things like evenRowBackgroundColor - without modifying the main base_properties file, as I gather that will make site maintenance a bit more difficult down the road.
Sorry if this is rudimentary, but I find myself spending lots of time figuring out how Plone works - and not too much time actually doing any styling...
In a default Plone 4 installation neither of the base_properties.props files is active, because the default "Sunburst" theme doesn't use base properties.
If you're using the Classic theme, then you want to copy base_properties.props from the classic_styles skin layer in the plonetheme.classic egg.
As for the question of which folder to copy into, I would probably put it in custom_styles, since it is related to the styles applied. It doesn't really matter though as long as these custom skin layers are ordered above the layer that you are copying the file from. To check on the order of the layers, go to portal_skins in the ZMI and click on the Properties tab. This lists the layers of each skin, in order of precedence.
As David Glick says:"To check on the order of the layers, go to portal_skins in the ZMI and click on the Properties tab. This lists the layers of each skin, in order of precedence."
But you want to select the default skin for which you are using basic properties and save it at the bottom. I couldn't get the Sumburst Theme to work so I went classic and used that as default and modified it's basic properties.
What are the full paths of the files that you found? That should give you a clue as to which one you should use.
skins/custom_styles is the preferred location although all of them will work.