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.
Related
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.
I really liked modular architecture by smacss.com/book/categorizing. But in real project I stumbled on simple case (as I thought).
ok, what I got:
1) I created a folder structure for my css-files by smacss:
Base
Layout
Module
State
Theme
2) In folder Module I've made a file with base modal windows styles, like this:
Base
Layout
Module/modal/modal.css
State
Theme
3) But I have a few types of modal windows with common styles (which I separated in modal.css - colors, borders, positions etc), but they have their own parameters. First window is very simple with two buttons, second has a lot of different content.
Question is: where should I put styles for these two windows?
a) Create folders for them as modules:
Module/modal/modal.css
Module/confirm/confirm.css
Module/product/product.css
b) or create for each css-file and put them in Base folder?
Base/confirm.css
Base/product.css
Module/modal/modal.css
I would be glad to get any advice. thank you
the main reason to use SMACCS is to organize your CSS files, therefore, there are a lot of approaches which totally depends on your project.
According to the author, as long as you keep the concept of SMACSS in your mind, you then are able to modify your project as you wish. So, what I recommend you is to have a look at your project and check your folders and files and just do whatever it makes sense more not only for you but also for other developers in the team or in the future while reading your code.
There are only two main goals that you should bear in mind:
A Base rule is applied to an element using an element selector, a
descendent selector, or a child selector, along with any
pseudo-classes. It doesn’t include any class or ID selectors. It is
defining the default styling for how that element should look in all
occurrences on the page.
and
a Module is a more discrete component of the page. This is the
meat of the page. Modules sit inside Layout components. Modules can
sometimes sit within other Modules, too. Each Module should be
designed to exist as a standalone component.
so, with this clear definition, you know now that if your rules should be standalone put them under the Module, however, if they are going to work as default to the elements so put them under the Base. In contrast, to me Product or Modal all can be Module and they are not Base as base are clearly stated as default element rules like I said on top.
I am just concern that you have written CONFIRM which looks like a State rules and I assume it can be placed under State folder.
A state is something that augments and overrides all other styles. For
example, an accordion section may be in a collapsed or expanded state.
A message may be in a success or error state.
I strongly recommend you, read SMACCS book or website one more time and have a look at one of the Jonathan Snook workshop that can be found on Youtube. It will help you to understand more and make a better decision.
My goal is to have more themes for my application and if possible, bundle them with the application itself, not load them at runtime using IStyleManager.loadStyleDeclarations().
Using the theme command-line option, you can have more than one "compile-time theme" bundled with your application according to docs:
theme filename [...] Specifies a list of theme files to use with this application. Theme files can be SWC files with CSS files inside them or CSS files.
However, I wasn't able to find an example how to actually do that (use the += syntax on command line?) and switch between those themes at runtime. What API should I use?
Using the theme command-line option, you can have more than one
"compile-time theme" bundled with your application according to docs:
Yes, You can add additional themes using the += in your command line.
I do exactly this for the Flextras mobile demos; including both the generic Spark theme with the Mobile theme to create the app.
However, both themes will be attempted to be used. I believe the second takes precedence. That means for every class where you want to use the "other theme" you have to specify that theme be used manually. This could get pretty complex very quickly; and you'll have to re-create a lot of spark skins in your application. I've done some work for a client around this who wanted to use our mobile DropDownList in both their normal application and in a mobile application from the same code base. I think the appropriate skin is conditionally applied at runtime using CSS; however we had to create a skin for the "non-mobile use" that explicitly specified the non-mobile skins for the individual elements (Such as the scroll bars)
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.
I have built a basic theme for my Flex app. I would like to add support for additional predefined themes. By default, app has a theme and I would like it to change when user selects a theme from dropdown list. This can be done by loading a swf file using styleManager. However, all the skins have colors hard-coded in them. So, in order to achieve this I would have to duplicate skins and change value of the colors.
Is there a better way of doing this? Can I just have a skin that will change color values dynamically based on user selection?
The best way is to move all hard coded colors from skin to the css.
You will have to update your custom skins to take advantage of that.
so if you have a <SolidStoke color="0xff0000" />
you need to replace it by <SolidStroke color="{getStyle('yourCssPropertyName')} />
Another way to do it is to write your skins so they have references to their host components (see [1]). Then you extend the current host components so that they have properties for each color you want to specify (e.g. instead of using , you'd use with borderColor and fillColor as new properties).
Honestly, though, Florian's answer is probably the better way to go.
[1] - http://www.adobe.com/devnet/flex/quickstarts/skinning_components.html#host