Hi all, On 01/07/2011 10:29 AM, Marius Dumitru Florea wrote: > On 01/04/2011 05:44 PM, Sergiu Dumitriu wrote: >> On 12/28/2010 04:13 PM, Anca Luca wrote: >>> Hi guys, >>> >>> Short story: >>> >>> Where to put the css which is needed by java macros (e.g. the columns >>> layouting of the container macro) >>> >>> 1/ in colibri.css >>> 2/ in a .css included on demand by the macro >>> a) from platform resources (using ssfx) >>> b) from the jar (using ssrx) >>> c) from an object in a page with ssx >>> 3/ refactor the skin concept and create a 'platform css' to store all >>> these and not be affected by skin customization. >>> >>> Long story: >>> >>> I can see I've caused the web standards tests to fail for the trunk >>> (http://hudson.xwiki.org/job/xwiki-product-enterprise-tests/org.xwiki.enterprise$xwiki-enterprise-test-webstandards/252/testReport/) >>> because of the inline style attributes used by the columns layout of the >>> container, whijch is now used on the main page. >>> >>> Now, I would like us to agree about where to store the styles needed by >>> the java macros to work right, such as the container macro with columns >>> layout. The options I see are: >>> >>> 1/ as until today (e.g. box macro, warning, error, info, etc), in >>> colibri.css/toucan.css/otherskinwehave.css. I don't like this solution >>> too much because it means that when another skin is used, things won't >>> work anymore unless the person writing the new skin takes care of >>> copying all these "things that must be there". The advantage of this is >>> having a single .css file to load on page load, the disadvantage being >>> that their css is loaded on all pages, regardless of it being used or not. >>> >>> 2/ loading of the styles on demand, each macro loads its style when it >>> needs it >>> a) from a .css file located in the platform resources, which the macro >>> has to include using the ssfx plugin when is executed -- much like a >>> wiki macro would to with a ssx. >>> b) from a .css file located in the macro archive (using ssrx), which the >>> macro includes when executed. >>> c) from a ssx page >>> >>> c) has the advantage of being very very much more easy to change than a) >>> and finally than b) which is the hardest to customize. But on the other >>> side c) means the java macro depends on a page, which is not that good. >>> Note that "cascading" customization is possible for all these choices >>> (adding an extra css with rules to overwrite the rules in the default >>> css for the macro) and that in my view, it's enough, since the idea is >>> that the layout should be preserved no matter what (e.g. a user might >>> want to add a red border to the columns, but not make the columns >>> display as two paragraphs instead of two columns). >>> >>> 3/ refactoring the whole skin thing and creating a "platform" css, which >>> contains things that should work regardless of the skin used. Pros: it's >>> an adaptation of the current approach (1/), that solves the problem. >>> Cons: takes longer, might be very hard to separate what's platform and >>> what's skin. >>> >>> These being said, I think I prefer 2/ if 3/ is not realistic, and for >>> the container macro at least, I would prefer to implement 2b). >> >> Strong +1 for 2b over the other options. colibri.css should not contain >> component style, just general layout. >> >> I don't think that the overriding disadvantage of 2b holds, since users >> are not supposed to _change_ platform styles at all, be they in wiki >> documents as SSX objects or as "hidden" .css files inside jars. Changing >> platform skin that way makes it much harder to upgrade to a newer >> version. CSS overrides in a custom skin or a custom SSX is the proper >> way to do that. >> >> The other disadvantage, about HTTP request proliferation, I've always >> said it and I repeat it once more, this is how XWiki works in >> _development_ mode. For production static website intended for massive >> workload, all the static resources need to be optimized: combine CSS and >> JS in one big file, combine images into sprites, move static resources >> to a CDN... Maybe we should write this down in the administration guide, >> and maybe offer some tools that can help with that (like a tool which >> gathers all skin files from the jars, the skins and the SSX objects, >> concatenates them, feeds sends them through YUI minifier, then outputs a >> zip with the resulting 1 JS and 1 CSS file to put in the CDN). >> > > I agree with Sergiu, I'm +1 for 2b _but_ I don't think it's enough. I > think we also need a mechanism to decouple the client side (precisely > the JavaScript and the CSS) from the server side (i.e. macro component > implementation). Let me give you an example: > > I'm writing an image gallery macro. The macro itself collects images > from some source (e.g. document attachments) and generates: > > (% class="gallery" %) > ((( > image:firstImageReference > > image:secondImageReference > > ... > > image:lastImageReference > ))) > > This needs to be enhanced with JavaScript and CSS. Why should the macro > care what JavaScript code and what CSS style sheets are loaded as long > as they serve their role: the "gallery" role. So IMO the macro should > use a JavaScript/CSS "component manager" to import the resources > required for the "gallery" role. I can bundle a "default implementation" > in the macro jar but it should be possible to overwrite it from within > the wiki. For instance I could add a "SkinExtensionMapping" object to > the page holding a skin extension to map it to the "gallery" role. This > way whenever I use the gallery macro my customized JavaScript/CSS will > be requested on demand.
This comes from the fact that yday with Marius we did an exercise trying to figure out how one would _customize_ their office viewer macro to implement the slideshow feature, for example. Options: 1/ they put their own class to the macro and then provide their own js to implement it. Since this custom js is just an improvement, it uses the existing one. First question, how to include these jss in the pages? 1.1.a/ include always -- performance issue, it makes the customization less efficient that the original, which is not fair 1.1.b/ include on demand, before calling the office viewer. This makes it impossible for normal users to use the office viewer macro (they will need to know they need to include js before calling it, which is completely unrealistic and hardly achievable in wysiwyg) Second issue is that: 1.2/ when this 'customization' is done, all existing calls to the office viewer macro will need to be changed to be passed the new cssClass value. 2/ they overwrite the js and css provided in the jars, in WEB-INF/classes. Besides the fact that this is a little SF for the normal web dev which expects his CSS to not be stored in the binaries folder, iirc and if my little experiment was correct, it requires container restart for any change to be taken into account. Also it requires filesystem access, which if we could avoid it would be great. I understand we want to discourage these modification of default resources because it makes upgrade a pita but, as I saw above, we don't have yet a mechanism to overload / overwrite properly. These are not to say it's impossible, are to say it feels like such a pain and almost anti-intuitive, for the _normal_ webdev. Andreas before has said enough about how easy it should be and, although I don't fully agree with his arguments, I find the options above in the complete opposite direction. > > WDYT? Normally yes, we should have js/css components, it would really be supercool. BUT, since I don't see that happening very soon, I kind of changed my mind about 2b until the js/css components are implemented. Because if we start applying 2b all over, it's gonna take at least 2-3-4 versions of XWiki until we're gonna have a decent way to overwrite those (js components), and in the mean time we'll have at least 3 macros bundled which are not customizable properly (container, dashboard, office viewer). I don't find this ok. If I had to write my macros as an extension of xwiki, not to be bundled in the default build and distributed with the default distribution, i would agree to go for 2b, because then I wouldn't distribute my build (with the macro in it) to other people pretending to distribute an extensible platform. I am preparing XWIKI-5843 with ssfx (that is 2a). Thanks, Anca > > Thanks, > Marius > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
