Re: [xwiki-devs] [Proposal] Retro-compatibility between Color Theme Application ad Flamingo

Hi! The current color theme editor is designed for colibri, and does not look like flamingo does. We have several options here: - create a new color theme editor, especially for Flamingo - modify the current one to detect which skin is currenlty used, and change the preview. The application will be splited in 2 sections: 1/ a live preview where you can set some variables (what we currenlty have) 2/ a free textarea where the user can fill LESS code (for example, some code downloaded on bootswatch). But a lot of applications already use the color theme as it is, via the "colorThemeInit.vm" template. So we need a retro-compatibility: a color theme computed by LESS must be usable with old color themes. Concretly, we will map the old color theme variables to the bootstrap ones, example: $theme.notificationSuccessColor = @brand-success But because of the section 2 (the free textarea), we are not able to know what will be the final value of a bootstrap variables without parsing the content of the textarea! What are the options we have: 1/ Implementing our own LESS parser/compiler in Java 2/ Trying to reuse the official LESS Parser through Rhino in a way that we can get the computed variables 3/ Do not parse the input but the ouput: parse the CSS code to get the final values of the variables I'm for 3. The idea is to create some CSS classes like this: .colortheme-bordercolor{ color: @border-color; } which will be converted by LESS to: .colortheme-bordercolor{ color: #000000; } so we can parse it and know the value of $theme.bordercolor. It is quick, simple, but it pollutes the output CSS a little. WDYT? Thanks, Guillaume