Hi Anca, thanks again for your informative response. I think again I've learned a lesson. I was not aware of this grouping stuff (((...))) preceeded by a (% ... %) .
You have taken the time to explain things in great detail and I'll do the same to express my thoughts what I'd like to see in XWiki one way or the other. When you want a custom design for a xwiki based site you need to a) hire a designer or b) spend a lot of time to try it yourself Yet I haven't seen any public Xwiki site except XWiki.com that is customized and good looking. The reason why there are so many good looking designed Blogs (and a lot of bad looking as well) is that there are tools that enable non-designers to sort-of-pick from a catalog design templates and arrange them. Some months ago I learned from a posting in the user forum about a design software named "artisteer" (www.artisteer.com). I downloaded the stuff and played with it for a while and I have to say that it's fascinating. Fascination comes from the "suggest a design" button. Any time you click on it it you get a template page created with random background, header picture, menus (with levels), paragraphs and element layout. You can modify any of those elements with the integrated drawing tools. With the $50 base version I've bought you can export the result to Blogger, Wordpress or into a html/css folder. This latter one is interesting as it exports a couple of ccs-files (ie6.css, ie7.css and style.css) and a .html into a folder and a subfolder containing images. Any kid can create some appealing base design by that. I don't believe this is a perfect tool. I don't know about its competition. But what I can say - it is inspiring and fun to use. I think its worth for you - or somebody else in the XWiki team - to spend an hour or so to play with the demo. I'm pretty sure you won't regret that time even if its only for 'looking beyond the fence' in other peoples playgrounds. Of course I'm hoping you might consider a marriage of its output with Xwiki content ;-) Its not realistic to control xwiki content by that in detail. But that shouldn't be the expectation. Headers, menus, paragraphs and element layout should be well enough. I think for someone familiar with XWiki internals this wouldn't even be such a big deal. All the different publishing tools and their capabilities - its a moving target. Sergiu Dimitru said WordPress is **only blogging** well its almost as well a simple CMS platform. Now if you have a publishing project that might be done with XWiki or with Wordpress or with a CMS and it needs to have a smart customized design and you can't spend a lot of money or time on design - which platform would be your reommendation ? regards Andreas Am 04.01.2011 10:28, schrieb Anca Luca: > Hi Andreas, > > Thanks for the feedback, see below my answers. > > On 01/03/2011 11:47 PM, Andreas Hahn wrote: >> Am 28.12.2010 16:13, schrieb Anca Luca: >>> 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). >>> >>> Thanks, >>> Anca >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> Hi devs, >> >> as an Xwiki user for about 2 years I'm not so deeply familiar with all >> the nuances of styling capatibilities - ssx ssfx ssrx and all the like. >> However this is an important topic and I would very much like to see >> that XWiki would move toward a styling architecture comparable to that >> of wordpress and other popular 'social publishing' tools so that it >> becomes easier to customize the look and feel of a site. > I don't know how wordpress is working, I will need to document on that > before I answer this topic. > >> I am aware of the contradiction between either offering components that >> are fully self supported - meaning macros and style bundled somehow >> together - and offering flexible code templates with separate styling (css). >> >> As an example the ColumnMacro and its successor: the Container macro. >> Both are IMHO a misconception leaving out the obvious solution. >> >> The colum macro (java) is limited as it uses hardcoded inline styles. > There's an issue opened about that (XWIKI-5843 iirc), which I am trying > to find the correct solution to with this thread. > >> This makes almost any useful layout modification impossible - ok you >> might rewrite the .jar but that's beyond what most people are capable >> and willing to do. > Now, the container macro and its predecessor, the column macro, are just > "shortcuts", if you want, to make the layouting functions more > accessible to normal people. As a developer, you can _always_ use: > > (%class="mycontainerclass"%)((( > my container wiki syntax content > ))) > > and the HTML result will be a div with a class on it, surrounding the > content. Then you can style that in absolutely any way you want. The > container macro is doing nothing different from that (still using groups > with html attributes), but it's providing it out of the box. The snippet > above is equivalent to: > > {{container cssClass="mycontainerclass"}} > my container wiki syntax content > {{/container}} > > Still, one should never use this second method just to put a div with a > class around the content, the group does that job perfectly without the > overhead of a macro execution. > > The idea of the container macro is that it would allow to add decoration > such as layouting, borders, and others for users which have no clue > about what CSS is or what a HTML class is. Users that is, not devs. > >> Same with the container macro: To modify the Layout you should really >> write an implementation of LayoutManager ? >> Someone must be kidding there - that's total overkill. > No, you shouldn't _really_. That's just a method to allow developers to > provide a layout to users. That is, a dev writes a layout, gives it a > name (say "grid") and then the users can use it with that name. There > are of course, various alternative methods to do that: you can just tell > the users to put a specific value in the cssClass, but as I said above, > the idea of the container macro is to make it feel normal and natural > for simple users. > >> Why not just pass a parameter - say cssClass to such a macro (as it is >> the case with other macros) for example the 'box'-macro. That's useful >> because it can be easily customized and you can provide an own class >> name and associated css. > It has it now on trunk (will be released with 3.0M1), because it's > generally a good idea to allow the container to have a css class (to > make life a little easier for devs) -- and because I needed it for > another macro that extends the container. > >> IMHO it would be much more benefical if there were a style guide for >> writing macros or templates making a small set of parameters mandatory, >> for example the 'cssClass' and maybe an 'id' parameter. > That's not necessarily realistic as cssClass makes sense only if you > have a toplevel element in the macro to put the class on. That's not the > case, and we cannot make it mandatory, there are enough macros which are > not about layout. > >> So if the parameter is not supplied you might go ahead with some >> internal or bundled styling (a default .css file) otherwise it might be >> overridden. >> >> I think there is a general risk thats XWiki is falling behind other >> platforms because of the lack of design standards allowing designers to >> customize solutions in terms of look and feel. >> >> Don't get me wrong - I do like XWiki and its concept much - what worries >> me is that it is simply too much work to customize a site design that >> compares favorable with wordpress sites and others. > I would be very interested in your usecase: what kind of layouting > customization are you approaching and how and where do you feel that > XWiki is "staying in your way"? It would be really great if you could > send us a little story about that. > > Thanks a lot, > Anca > >> regards >> >> Andreas >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
