I am currently in the process of migrating a Vaadin 8 application over to Vaadin 12. The look and feel should be used by the user and changed on Login or via a button press.
In Our Vaadin 8 application we had 2 themes (a dark and a light one), each with their own SASS/CSS and some shared properties. The user was able to switch it using the setTheme() Method. When a click to the switching button happened, the Look and Feel just changed. In Vaadin 12 the Theming follows a different approach and I am struggling to find a good way to implement this feature in Vaadin 12.
Let's say we don't want to create a whole new Theme and just want to use customized LUMO. I can set the Theme/Variant through the #Theme Annotation. The Downside: The Theme will be fixed at Runtime.
Also i could just write some code to apply variants to my application and components. (like in the dynamic styling chapter: https://vaadin.com/docs/flow/element-api/tutorial-dynamic-styling.html )
The Downside: It won't be very practicable to iterate through each element and apply the variant.
My question now:
What is the best way to achieve a switch between to themes at runtime? (customized light- and dark variants of Lumo or any other theme).
Would I just create 2 HTML Files (for compatibility) containing CSS and then somehow override the currently used File through a dynamic import?
I hope my question is clear and someone can point me to the right direction.
If you are only interested in toggling between light and dark, then you can just add/remove dark at a very high place in the DOM. E.g. the element of the UI is usually the body or at least very high up.
E.g.:
new Checkbox("Use Dark Theme").tap{
addValueChangeListener{ cb ->
getUI().ifPresent(){ ui ->
def themeList = ui.getElement().getThemeList()
if (cb.value) {
themeList.add(Lumo.DARK)
} else {
themeList.remove(Lumo.DARK)
}
}
}
}
edit
As asked in the comments of another answer:
To change the colors in a theme, you can override the used colors. This is the example how to change the text color for light and dark Lumo theme:
html {
--lumo-body-text-color: red;
}
[theme~="dark"] {
--lumo-body-text-color: yellow;
}
It's relatively easy to switch between two different variants of the same theme, e.g. the dark and light variants of Lumo. To do this, you only need to toggle the corresponding theme attribute on the <html> element. There's no direct access to that element from the server, but you can do it with a small snippet of JavaScript: ui.getPage().executeJavaScript("document.documentElement.setAttribute($0, $1)", "theme", "dark");
Depending on circumstances, you can or must apply the changes to the <body> element instead. In that case, you can either switch out .documentElement for .body in the JS snippet or directly use ui.getElement().setAttribute("theme", "dark") in Java.
Switching between two different base themes, e.g. Lumo vs Material is a much more complicated affair. For each component, there can only be one base theme loaded in the browser at the same time, and reloading the page is the only way of getting rid of the one that is already loaded. For each component that is used for Flow, the framework takes care of loading the right theme import in addition to the base import that doesn't have any styling. To make things even more complicated, the theme designated using #Theme is automatically included in the application's production bundle. To be able to use multiple base themes, you'd also have to somehow produce multiple different bundles and also somehow configure Flow to use the right bundle depending on circumstances.
Related
I would like to do custom theme variations for my Vaadin 20 app. For that I am going to give custom values to Lumo CSS variables available, like --lumo-base-color and --lumo-primary-color. The problem is that I can't find an extensive list of variables that are available.
My questions are:
Where can I find a list of all the variables that are themeable?
Is there a good theme example with a lot of these variables set, that I could use as an example?
This is an excellent question, as it is often a best practice to start customization of the application on high level by redefining values of the Lumo CSS variables.
Take for example elements like ComboBox drop down button, text field clear icon, DatePicker popup button all use variable --lumo-contrast-60pct. It is easy to define its value in shared global css, and the new color will be consistently used by all the components. This is better approach than defining a custom css per component basis. See example below, where original graphite grey color has been changed to blue.
In the design system foundation documentation, each sub-section will list the available variables.
Additionally, if you inspect the <html> element in your browser development tools, you can see them listed there also.
In the Lumo theme editor demo you can change as many styles as you wish. It then lets you download a file that lists all the variables that you changed.
Another option is going to https://start.vaadin.com, where you can also customize some aspects of the theme, and the downloaded application will include those definitions.
In your running application, you could paste something like the following ugly snippet into your DevTools console to output all the Lumo custom variables and their current value:
[...document.styleSheets].forEach((sheet) =>
[...sheet.cssRules]
.filter((rule) => rule.type === 1)
.forEach((rule) =>
[...rule.style]
.filter((style) => style.startsWith("--lumo"))
.forEach((style) => console.log(style + ": " + rule.style.getPropertyValue(style)))
)
);
This will spam your console with something like
--lumo-border-radius-s: 1em
--lumo-base-color: hsl(214, 35%, 21%)
--lumo-tint-5pct: hsla(214, 65%, 85%, 0.06)
--lumo-tint-10pct: hsla(214, 60%, 80%, 0.14)
...
You might want to adjust the snippet to produce something more useful, depending on if you want to just use it as reference, or copy & paste into your theme.
UPDATE : I made a new test project from scratch and this one DID apply the style inside the default platform marker on my mainform on windows and android, so the behaviour seen below might have something todo with rest of my project..I will do some more testing.( I have 1 style 'backgroundstyle' with rectangle brush fill color set to red )
UPDATE 2 : As soon as I added 1 specific style for e.g. android platform, none of the 'default' platform styles are considered anymore. Mainform suddenly not red anymore.
In an heroic attempt to make a good styling design for my proof of concept multi-platform application, I'm was investigating the stylebook more closely.
In general, separating the styling from the application logic is of course, very welcome. Although I'm more unsure if the fmx implementation of this principle is, sofar, optimal ( I'm losing myself in finding out which property of which styleresource I need to change to get what I want for anything beyond simple text or rectangles....but that might be up to me. ).
I also understand that each target platform has it's own habits , and it's good practice to stick to them ( at least, if you want to be part of the hurd :-) . But I would say that , e.g. my main application colors is something that I decide, and should be consistent across platforms. It seems that in order to achieve that, I need to change that, possibly , on all the multiple individual style --resources-- ( everywhere a fill color is / might be specified in each of the 190 styles in the list and also in all the bitmaps in the bitmap map, and this for each scale and each sourcelinkname.. ) and , again, this for every target platform...The result is usually that I stick to the 'premium' out of the box styles :-)
I had hoped that the 'default' platform marker would come to the rescue, and have this platform for all of the styles, and BY EXCEPTION, have only some platform specific styles repeated and changed, if really required on that platform. The documentation says :
Note: There is also the "Default" platform marker. FireMonkey application loads > the Default style when the application cannot find the matching styles for the > current platform.
But it doesn't seem to work this way. e.g. on android these default styles ( in runtime ) are always ignored and revert to the embedded platform specific style but in windows the styles are indeed used... ( in the IDE at design time, the same default style is shown as I expect for every platform that I choose -- ) In my example, I simply use the mainform background color ( = backgroundstyle brush fill color ) as an easy test setup : change the brush fill color on the 'backgroundstyle'
for the default platform and run it on windows / android ).
So what is the purpose of the default platform in the stylebook ? Is there something I do not understand ? Or is it a bug ? Is there a way to use one set of styles across platform via the stylebook ?
If not, could you create and deploy a single style file and load at runtime and have it used on all platforms ?
( should there be a platform marker in this style file ? Would the styles be ignored if not 'really' the correct target platform ...)
As a result, I find myself doing a lot of runtime styling in code afterall because I'm really sure it will be platform consistent, but that's not really the purpose I guess....
It seems that that when you set the stylebook property 'UseStyleManager' to true, then that ( first ) style is indeed ...used :-) , regardless of the platform .
It also means that when your style container does not contain the right styling resources, your components are probably invisible !
But when they are available, they are rendered consistently across all platforms.
It might be personal preference to have only have 1 single style ( definition ) and whenever needed, make the exception . But in my experience sofar, going through and working with the list of style resources is time consuming, so the lesser 'sets' I need to verify, the better.
If I still would need an different style for a specific platform, I would need to overwrite the stylelookup name at runtime for that component on that specific platform and of course also add that specific stylelookup name to my default style container ( Simply adding a new platform to your stylebook and using the same lookupname will not work because it's ignored in this setup ).
I have a problem using the filelist / upload element of TYPO3 at the current new version 7.6.2. I want to use the title or description part instead of the filename while rendering the list.
I found lots of information on that and in TYPO3 version 6.x it worked with:
tt_content.uploads.20.renderObj = COA
tt_content.uploads.20.renderObj.20.1.data = file:current:title
tt_content.uploads.20.renderObj.30 >
When I insert this lines into the TS of the page where I want to use the filelist it does not work with the new css_styled_content for 7.x.
When I include "CSS Styled Content TYPO3 v6.2 (css_styled_content)" to the setup of the template, the filelist works (but other parts of page not).
Therefore the question: Do you know if there are some changes in rendering the filelist at 7.x?
Thanks for your help
Markus
The reason why you can't change the name => title anymore is that you included Fluid Styled Content ext which is required i.e. for rendering the Text & Media CEtype. It massively overrides the CSS styled content and replaces (almost) whole TS declarations with Fluid templates/layouts/partials from typo3/sysext/fluid_styled_content/Resources/Private folder. I.e.: in typo3/sysext/fluid_styled_content/Resources/Private/Templates/Uploads.html:29 there is {file.name} used which should be more advanced condition...
To change it:
Copy all folders from typo3/sysext/fluid_styled_content/Resources/Private to your custom destination i.e.: fileadmin/fluid_styled_content/Private (this is for avoiding loosing of your changes after system upgrade.
It can be any other path, for an instance you can create your custom ext and put it into typo3conf/ext/yourext/Resources/Private/...
Go to your TypoScript template > Constant Editor > Category: Content and set new paths in these fields:
Path of Fluid Templates... - fileadmin/fluid_styled_content/Private/Templates
Path of Fluid Partials... - fileadmin/fluid_styled_content/Private/Partials
Path of Fluid Layouts... - fileadmin/fluid_styled_content/Private/Layouts
After that go to fileadmin/fluid_styled_content/Private/Templates/Uploads.html:29 and replace the code:
{file.name}
with:
<f:if condition="{file.title}"><f:then>{file.title}</f:then><f:else>{file.name}</f:else></f:if>
As you can see this way you can also change other CEtypes and their typical settings (i.e. add the responsive classes if working with RWD).
On the other hand take a look there are some drawbacks of this solution, i.e. default layouts repeats the <div id="c123">... which is invalid :/
P.S.:
Also just realized that Fluid Styled Content doesn't handle other things, i.e. different layouts for Uploads (that the first thing I saw, didn't check other CEtypes) so you need to consider yourself if it is OK for your project at the moment. I prefer to stay with old way (no need for Text & Media CE) and disable FSC now (I'm pretty sure, that soon it will be nice alternative for CSC, but not now imho :/) To revert typical state you can use these lines mentioned in the GitHub here within your PageTS.
At the following link there is a cheatsheet for Adobe Experience Manager (AEM formerly CQ).
http://activecq.com/system/assets/46/original/quick-reference.html
There is a section on the page called "Component Organization"
At the bottom of the list are two sections: views and partials.
My first question is, what would the x and y represent and is there some built in mechanism that already exploits this convention?
If a page included content where this component was the resourceType and the appropriate selectors were in play then those x and y JSPs would also be in play. For instance,
/content/mysite/mypage.views.x.html
But that seems strange. A more likely scenario is that the component is targeted through a sling include that adds or replaces selectors.
<sling:include resourceType="/apps/myapp/components/sample"
replaceSelectors="views.x" />
So what is the intended usage of this feature?
I could be wrong, but I believe the partials folder is referring to this: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/10
The idea seems to be to break up the component into inheritable sections for ease of use and development of siblings of the parent.
Starting a new rails project and we have a well-thought-out color palette, and want to capture that in one place. I have usually kept colors in the CSS, but I find I end up with all the same color in lots of different selectors, as it shows up as a background color, color, border color, etc. I also will occassionally need access to colors in the Javascript. It would be great to just define each color ONCE.
So I'd just like to define my color palette in a way that's re-usable in the CSS and Javascript, but I don't want to go all the way to SASS, abandoning CSS syntax completely.
Is there a rails plugin already made that allows this? I could patch together an ERB type solution, but I don't want to do it if someone else has something readily available.
There is a new project out called {less} that sounds like what you are looking for: http://lesscss.org/
LESS seems to have a rails plugin, and a more css like syntax.
There are several server side parsers like LESS and SASS, but if you want to use the palett mentality in straight CSS you have to revers your thinking. Define basic styles like colors, fonts etc. and apply multiple classes at the tag level.
[style]
.color1{color:red}
.color2{color:blue}
.color3{color:green}
.bcolor1{color:red}
.bcolor2{color:blue}
.bcolor3{color:green}
[/style]
[tag class="color1 bcolor2"]
This has worked very well for us.
Another (pure CSS) way may be to define each color once, and have the several selectors associated with that oe color definition, for example:
body,
p,
#foo,
.bar {color: #802369 }