Currently you have to edit CSS (the *css card) and HTML (the *layout rule) to change a site's look. We want it to be super easy to change skins and add new ones. At the same time, we want to retain the possibility of letting power users go down to the lowest level.
Design needs/questions
a. active components for choosing themes (skins) from a list of canned ones wagn sends out - Prototype: Nautical theme - skin: knotty
b. js is the skin, css is the theme - skin.js, theme.css
c. Uglify? hmmm
Anyway.. just trying to find places to jump in. Gerry's pretty much taken me under his wing.
My specialty is style and grace. --cq *Use POE or die*
--cquin.....2013-02-26 06:11:37 +0000
a. in the solution above, the active component is the "*style" rule. You'll edit styles just as you would any other rule (currently through the advanced tab). We could choose to use the word *skin or *theme, but I think *style is the best fit, because we'll often combine multiple stylesheets. Also, to my mind, the "skin" is really the combination of the *layout and the *style setting.
b. javascript is for (in our case) client-side functionality. skins are by definition superficial and should not impact functionality, just appearance. The difference between skins and themes is usually just depth of configurability.
c. "uglify" is a tool for smushing all the css into a single file; it makes page loads faster (and it means fewer web requests)
--Ethan McCutchen.....2013-02-26 16:05:47 +0000
what's POE?
--Ethan McCutchen.....2013-02-26 16:06:57 +0000
http://en.wikipedia.org/wiki/Perl_Object_Environment
--cquin.....2013-03-22 05:04:28 +0000
process:
Thought: assets like these that are sourced in Wagn cards, or in particular the CSS part, we could use something like what is used for File/Image cards where the served file is processed into a real file complete with version identification. then we can do something similar and serve up .../CSS-card-name- .css from the web server cache.
Will we ever want custom javascript on some pages too? Should we add cardtype and settings for that too?
re assets, that's not quite how it works now. we're using standard asset pipeline fingerprinting, which means it's not a web server cache at all, but instead the browser is instructed not to make repeat requests. So, in fact, every time you get a file request to the server, it does go to wagn to process the permissions.
My hope was to follow this pattern for CSS files, though, and have a real file initially (though we could ultimately do it from memory if we prefered).
Javascript is not relevant here, but if you have a use case we could explore it (elsewhere). My general assumption has been that we'd only be compiling one js file, but that it would use standard jquery wagn patterns to assign behaviors to sets of cards as needed. I doubt that it's common to need a lot of different behaviors for different layouts, but if so, even that would be relatively easy to accomplish with a single file.