Eric, Yay! Thanks for completing that work. I agree that it should be merged into master and add the documentation you listed. I can contribute to #1-4. I also agree that it feels like a 4.1 change.
Just so that everyone is aware, SCSS will accept any valid CSS syntax. So if people want to still author in CSS, it can be added to the SCSS files. This is true for both uPortal development as well as institution custom skins. Ideally, people would uptake the benefits of SCSS, but "plain" CSS is still valid within SCSS. -Gary On Apr 30, 2012, at 2:34 PM, Eric Dalquist wrote: > Luckily the resource aggregation plugin required no work and we have the > build time SCSS -> CSS compilation working in the UP-3456 branch. > > I'm thinking we should get this merged into master and then do the following > in the manual: > Document a recommended best practice for custom skin development of copying > one of the provided skin directories and then customizing. Deployers should > be discouraged from modifying any of the provided skins in place. > Suggest (a lighter statement than recommend) that deployers avoid modifying > css/js files in the "common" directory and instead override styles in their > skin specific CSS. > Document how to generate/capture the CSS output from the SCSS template for a > custom skin if the deployer would rather use CSS instead of SCSS > Document how to use the SASS Watch utility to do CSS development for a custom > skin. > I'm thinking that it would be valuable to consider adding the watch > functionality to the sass-maven-plugin since we'll be adding documentation > for that use of the tool. > The last question is where do we do this? Is deleting the shipped CSS files a > big enough change that this should only happen for 4.1? I'm thinking that is > the case since deleting the .css files could be problematic for folks that > have customized one of the provided skins. > -Eric > > On 4/30/12 10:24 AM, Jen Bourey wrote: >> >> My personal thought is that we take option 2 and write clear instructions in >> the manual for disabling the SCSS build. We probably also want to document >> how to disable it on a skin-specific basis - probably the most likely need >> is to know how to let the portal continue using the default behavior for the >> built-in skins, but create university-specific skins that don't use SCSS. >> >> - Jen >> >> >> On Apr 30, 2012, at 6:59 AM, Eric Dalquist wrote: >> >>> I have a snapshot of a sass compiling maven plugin deployed, the source is >>> here: https://github.com/Jasig/sass-maven-plugin >>> >>> I've created a branch of uPortal to figure out how we move forward with >>> this: https://github.com/Jasig/uPortal/tree/UP-3456 >>> >>> Issue 1: >>> When I generated the CSS files from the SASS templates the resulting CSS >>> didn't match what was already in git. You can see the diffs here: >>> https://github.com/Jasig/uPortal/commit/9256edc359e9face91d98f2fa190b3cd9114f3b7 >>> >>> It looks like most of the changes are formatting, I'm wondering if there is >>> something I need to change in the generated ruby script that compiles the >>> templates or the version of SASS being used. The only existing maven >>> artifact for SASS I could find is 3.1.15 though that only appears to be a >>> point release behind the current version. I've pasted the script at the >>> bottom of this email. >>> >>> Issue 2 >>> What is our long term project config goal. Do we want both the SCSS and CSS >>> files in git and we just use the mvn task to re-generate them when needed? >>> Or do we remove the CSS files from git and generate them at build time >>> using the mvn task? >>> >>> For option 1 the advantage is that deployers don't need to learn SCSS/SASS >>> the CSS files are there for them to use and just work. The downside is that >>> we have to remember to only update the SCSS files during uPortal >>> development and to regenerate the CSS files as needed. >>> >>> For option 2 the advantage is we remove what is effectively generate code >>> form the git repo and never have to worry about the CSS being out of date. >>> On the down side if deployers want to use CSS and non SCSS they need to >>> copy the generated files back into the source tree and disable the SCSS >>> plugin. This is doable but we would need to document it VERY WELL. >>> >>> -Eric >>> >>> >>> Ruby script as generated by the plugin: >>> require 'rubygems' >>> require 'sass/plugin' >>> Sass::Plugin.options.merge!( >>> :cache_location => 'uportal-war/target/sass_cache', >>> :cache => true, >>> :unix_newlines => true, >>> :always_update => true >>> ) >>> Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/muniversality/common/scss', >>> 'uportal-war/src/main/webapp/media/skins/muniversality/common') >>> Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/coal/scss', >>> 'uportal-war/src/main/webapp/media/skins/universality/coal') >>> Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/common/scss', >>> 'uportal-war/src/main/webapp/media/skins/universality/common') >>> Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/hc/scss', >>> 'uportal-war/src/main/webapp/media/skins/universality/hc') >>> Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/ivy/scss', >>> 'uportal-war/src/main/webapp/media/skins/universality/ivy') >>> Sass::Plugin.add_template_location('uportal-war/src/main/webapp/media/skins/universality/uportal3/scss', >>> 'uportal-war/src/main/webapp/media/skins/universality/uportal3') >>> Sass::Plugin.update_stylesheets >>> >> >> -- >> >> You are currently subscribed to uportal-dev@lists.ja-sig.org as: >> eric.dalqu...@doit.wisc.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
