WebGUI - FilePump core asset dynamic bundle - Content Management System | CMS | Open Source Content Management | Web Application Framework

Username Password

Home Features Download Partners Community Blog

Community Support
WebGUI User Guides
Wiki
Forums
Report A Bug
Request Features
WebGUI 8
WebGUI TV
Add-ons and Plug-ins
Service Providers
webGUI in the news
Karma
API Docs
the people behind wg
webgui worldwide
Mascot
wallpapers
powered by icons
Sightings

View All Tickets

FilePump core asset dynamic bundle (#10971)

Issue

The template working group is planning on using a "wg core" FilePump bundle that will combine all webgui asset css files.

It would be nice if this was a dynamic bundle, that excluded all css files for assets that are not used anywhere on your site (at bundle build time). This would allow the wg core bundle to be as minimal as possible whilst still being cacheable across an entire site.

To achieve this we would need to hook into Asset::new to make sure that the wg core gets automatically rebuilt when a new type of asset is added to a site.

Please assign this RFE to me.

Comments

JT 9/22/2009 11:27 am	I don't understand what this gets us or why we should do it. It's my opinion that nothing from the core (ie /extras folder) should ever go into a file pump bundle. If that stuff goes into file pump, then all the bundles on every site will have to be rebuilt every time an upgrade is done just to be sure that nothing has changed. Now if we want to make some policies for /extras, then I'm ok with that. For example, that there should be a minified version of each file, or that each file should get a version number built into it's filename, etc. If they're planning some sort of a CSS file that doesn't go into /extras and is served up as a snippet, then I'd want a justification for why that's not going into /extras.
patspam 9/23/2009 7:44 pm	Let me back up a bit and try to explain it better. For the sake of maintainability, we want each asset to have a single css file, where by "file" I mean a WebGUI snippet (as many assets already do). e.g. article.css, layout.css, thingy.css, etc.. We then have a wg-core bundle that combines all of these individual css files for optimum browser consumption. That's the first step that we're already working towards on the template working group site. The idea of this RFE is that if the wg-core bundle had some smarts built in, it could figure out that you're not using Thingy anywhere on your site and thus there's not need to bloat wg-core with the thingy.css styles. e.g. it's just an optimisation.
JT 9/23/2009 8:27 pm	I'm still not seeing the advantage here. We don't put the YUI css files into snippets, so why would we put the asset structural css files into snippets? These css files aren't supposed to have anything in them that anyone should ever edit. I sort of see the benefit of the magic of removing things that aren't actually used on the site, and that's really the only plus I see here. However, that plus is so full of problems that I'm having a hard time seeing it as a benefit rather than a detriment. The only way I can see it working is if the "core bundle" was rebuilt every time someone added or deleted an asset from the site, otherwise you'd be missing the structural elements needed to make the asset work. And how do you account for versioning? And you're going to include survey, thingy, map, and 50 other assets even though they are only used in a private section of the site that only 1% of the users use (like the PB intranet vs the public site). I'm still not saying no. I'm just saying that until I can see how these problem's are going to be overcome, I don't see it working.
JT 9/23/2009 8:27 pm	Feedback Requested by JT
patspam 9/23/2009 9:40 pm	Since there are a few interrelated issues here I'll break things down to the level that was discussed at the hackathon by the TWG. By "designers want" or "we want" I just mean that these were the suggestions put forth and agreed to by the TWG. Better suggestions are obviously welcome. 1 - Per-asset css files. * Designers want wg to have a single css file per asset type, consistently named and in an easy to find location. This is firstly for core designers so that they know where to find appropriate css rules, and secondly for end-user designers so that they know where to go to review all of the css rules for an asset (I'm guessing that would be useful when reskinning an asset). To this end Mego has created an inventory of all existing asset css files. I think we're in agreement that this in itself is a Good Thing? * Designers want these css files to be WebGUI snippets so that they are "easier" to access. I agree that designers shouldn't be editing core asset css files (TWG folks currently need to be able to on the TWG site to make their edits, but that's a separate concern). However with FilePump in the mix there is no performance penalty from using Snippets instead of physical files, so why not make them Snippets and give end-users ultimate flexibility? * Whether or not these per-asset css files are physical files or snippets doesn't really make a difference to the topic of this RFE since FilePump can work with either. 2. YUI CSS Perhaps yui css files should be snippets too? Currently we're focused on skinning wg and not on skinning yui. And it would take a lot of effort to add all the yui css files and maintain them through yui upgrades. And designers aren't clamouring for us to do it. All of the above is just the background to the RFE and perhaps should be redirected to the TWG mailing list so that others can participate in the discussion.
JT 9/23/2009 10:23 pm	I agree that having one css file per asset is a good thing, and I understand putting them into snippets while the TWG is working. The part that seems dubious to me is leaving them in snippets. There should be NO reason for an end user to ever edit these things, because they are structural, not stylistic. Plus, they should be able to override or entirely replace them. As far as putting YUI into snippets, the answer is ABSOLUTELY NOT UNDER ANY CIRCUMSTANCE. I'm not willing to even discuss it. It's a terrible idea on every level. 1) No one should ever edit YUI files. 2) For users not using File Pump it slows it down. 3) We change the YUI versions as needed and putting them into the core makes that more difficult and hazardous for us to do. 4) WebGUI 8 is pushing YUI out to CDN anyway, so including them in the asset system and in filepump is just a waste of space for 70% of users. Anyway, not trying to be negative here (except for YUI), just not seeing the benefit.
patspam 9/23/2009 11:05 pm	re: YUI yep I'm not advocating we do it either. Physical per-asset css files rather than snippets are fine by me, I'll leave it to the designers in the TWG to voice any concerns they have with that (if any). The per-asset css files will actually be both structural AND stylistic right? My understanding is they will contain both the css that is required for functionality as well as the css that gives the asset its default "skin".
JT 9/23/2009 11:26 pm	It's not supposed to be that way. It's supposed to be structure only. The "skin" is all supposed to be contained in a site.css file of some sort, so that you can change one css file and the entire site is now new and fresh.
patspam 9/23/2009 11:46 pm	Sorry, I'm not fully getting it. But hopefully one of the TWG folks will pick up this thread and shed some light onto it for me (I've emailed it to the list). Confused thoughts follow. Are you saying each per-asset css file is only supposed to contain css rules that are required for bare-bones functionality (structural not stylistic), and we have another core site.css file that contains the stylistic rules for every asset in wg? If so I'm pretty sure the TWG will want to separate this site.css out into per-asset "stylisitc" css files for maintainability. In which case, what is the point of separating structural/stylistic rules? I feel like the line between the two is going to be pretty blurred anyway. Or do you mean the user creates their own site.css file that overrides styles found elsewhere? In which case, where do the default stylistic (as opposed to structural) rules live? Or are assets supposed to ship with minimal aesthetic styling? Or something else (probably)? Sorry, I don't want to drag you into an unnecessary discussion, I just not grokking it atm and I'm starting to think the TWG might be heading in a different direction to what you want here.
rogier 9/24/2009 5:51 am	First step in doing this RFE is making sure were talking about the same thing. Allow me to summarize... JT is expecting the template group to make: - a single stylesheet - this is in the extras folder - it contains only styles for positioning (structure) - this allows a designer to theme a site by only adding colors, fonts etc. (skin) - so a theme would always be based on the styles in the structure stylesheet, which may be overridden, but never edited (I'm not trying to put words in your mouth JT, if I misunderstood just let me know.) The direction the TWG is moving in is this: - every asset has it's own stylesheet - these stylesheets are snippets - if a designer makes a theme, they have the decision to 1. either add their own stylesheet, which builds upon the structure in the existing stylesheets 2. or add their own stylesheet and edit one or more of the default stylesheets - the stylesheets for the theme are put into a bundle - this bundle contains: --- a custom (skin) stylesheet --- the default stylesheets that have been edited (if any) --- and (probably) the default stylesheets that haven't been edited - so there is still a stylesheet per asset in the bundle, but some may have been edited This is not set in stone yet, by the way; we're still discussing it and there are variations possible. But one thing it requires is that all assets have their own stylesheet and that those are in snippets. The big advantage here is that it allows for both simple skinning and more complex theming. JT, I would like to do the following: the TWG takes a bit more time to work out the process mentioned above. When it's done, we'll discuss it with you and in that context we can re-address this RFE. That doens't mean that I wouldn't like to hear your thoughts on this right now. I just don't have all the answers yet. Everyone, At some point we may perhaps discuss YUI css, but in a different context - so let's leave it out of the discussion for now. Thanks, Rogier
JT 9/24/2009 8:37 am	To Patspam: The structural CSS files per asset should include only basic formatting elements that can be considered site-neutral. And then the user would create a site.css file that would adapt their color scheme to everything in the site. To Rogier: I agree that each structural style sheet for each asset should or at least can be maintained separately as long as there is also another structural style-sheet for "shared" elements like we talked about at the WUC, with things like tab formatting, asset level navigation elements, form formatting, etc. I also agree that those style sheets should be maintained as snippets during the development process. The part I'm debating here is whether or not they should remain snippets after the development process. What I see happening is designers editing the default snippets, and then getting pissed as we overwrite them (during upgrades), when they should never be modifying them at all. They should either not use them at all and create their own, or simply override the properties they wish to change with a new stylesheet. In addition, I think that using filepump for core level stuff is the wrong approach. I think we should be combining and minifying these stylesheets into the /extras folder, because it should be done once per version of WebGUI, not once per version of your site. Sure, go ahead and talk it over with the TWG. Just take back my concerns to them here so you can either move your process inline with what I've said, or so that you can address my concerns and change my mind.
rogier 9/24/2009 10:34 am	"What I see happening is designers editing the default snippets, and then getting pissed as we overwrite them (during upgrades), when they should never be modifying them at all. They should either not use them at all and create their own, or simply override the properties they wish to change with a new stylesheet." Would it be possible to add a warning to these snippets similar to the one you get when editing a default template? I don't think we'll be going in that direction, I'm just asking out of curiosity. "In addition, I think that using filepump for core level stuff is the wrong approach. I think we should be combining and minifying these stylesheets into the /extras folder, because it should be done once per version of WebGUI, not once per version of your site." This is a good argument too. Luckily, using filepump for themes and adding the stylesheets to /extras are not mutually exclusive. I'm sure there is a solution that makes us all happy. I'll make sure to take your concerns into account.
JT 9/24/2009 10:45 am	Anything is possible. =)
rogier 9/24/2009 2:02 pm	...but some things are more probable than others, right?
JT 9/24/2009 2:14 pm	Depends on need vs want. If we decide that these things must be snippets, then we'll figure out how to add that functionality to snippets.
patspam 9/24/2009 7:17 pm	Great stuff. Minifying styles into /extras as a build step sounds like a good option too. There is one nice feature that FilePump would give us over a /extras build step that's worth mentioning - the ability to see the unminified per-asset files when Admin Mode is on. With something like Firebug open you'd be able to inspect an element and see what per-asset css file a given css rule came from, which is rather handy when you're skinning. Anyway, let's hash it out over at the TWG forum and see what we come up with.
dionak 9/24/2009 9:05 pm	I agree, great conversation. I would prefer to see style overrides in a theme rather than complete, but edited, copies of the default css stylesheets. This, imo, is Zen. I agree with JT that default styles need to be structural and not stylistic. E.g. font-color. WebGUI needs to work, out-of-the-box and not over-ride site designs. However, I love the idea of creating themes for assets, which would include stylistic elements, but they need to fit into overall site design. E.g. - creating a vbulletin or phpBB theme for forums, OS themes for blogs, etc. I envision designers being able to download these asset themes from the bazaar. This "asset theme" would maintain the site design, but add elements for appearance for a particular asset (e.g. - vbulletin or phpBB icons or colors for forums - this is lofty but important to reduce customization costs). The designer can then edit the "asset theme" to their liking. The "asset theme" should never override the site design. If a designer were creating a complete theme for a site, they could add the "asset theme" to their package. Thereby adding phpBB (for example) to their "complete site theme". Hence, the thingy.css example. Users could then edit the stylesheet on a per-asset basis but inherit many useful designs by editing an existing "theme asset", therefore reducing customization costs. I think we need to draw the line at "asset themes". Users of a theme could edit asset stylesheets to their liking (replace an icon, change a background-color for forum replies, etc). Making WebGUI attractive upon use will increase adoption. Meaning that good, useful and customizable templates need to be created for new assets. Older templates need to meet this criteria. However, this is where I struggle with WG templates. I'm thinking of the Story Manager here. It works great but is designed aesthetically for a programmer. Colin would like templates I'm sure, as many programmers would likely desire, to increase usage of their work. Anyone using any asset will incur the costs of theming. Reducing this cost, will increase adoption. How do we separate the concern of less work styling (work-out-of-the-box in regards to style) from the desire to override styles? Also, it is critical that designers be able to parse the default stylesheets so there needs to be a way for them to see the un-compressed versions (be they snippets or something else). Perhaps this would make a good topic for a conference call. This is almost too much for digital communications.
patspam 9/24/2009 9:23 pm	I'm totally sold on making the core styles (per-asset css files and webgui.css) as immutable as possible for the sake of upgradeability, theme support, etc.. Diona - perhaps re-post your last message to the TWG forum? This RFE is getting a bit off-topic!
rogier 9/28/2009 5:25 am	OK, discussion not related to this RFE will continue here: http://www.webgui.org/design/template-working-group/style-templates

Details

Ticket Status	Pending
Rating
Submitted By	patspam
Date Submitted	2009-09-11
Assigned To	patspam
Date Assigned	2009-09-11
Assigned By	perlDreamer
What to improve?	WebGUI Beta
URL	rfe/request-for-enhancement/10971

Karma

Difficulty	1
Karma So Far	0
Karma Rank	0.00

Keywords

Ticket History

9/23/2009 9:40 PM	Pending	patspam
9/23/2009 8:27 PM	Feedback Requested	JT
9/23/2009 7:44 PM	Pending	patspam
9/22/2009 11:27 AM	Feedback Requested	JT
9/11/2009 1:46 PM	Assigned to patspam	perlDreamer
9/11/2009 10:30 AM	Ticket created	patspam