[xwiki-devs] [discussion] Where to put java macros CSS?
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.enterpr...) 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
On Tue, Dec 28, 2010 at 16:13, Anca Luca <[email protected]> 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.enterpr...) 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.
We can't really see that as a solution, it kid of work for us because we have access to colibri skin but we have to find a real extendable solution for anyone who write a java macro.
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).
I think the only clean solution from extension architecture POV is b).
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.
For me this is almost as bad as 1/
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).
Side note: be careful with css and macros it's easy to make it unusable for anything except XHTML renderer.
Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Thomas, all On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
On Tue, Dec 28, 2010 at 16:13, Anca Luca<[email protected]> 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.enterpr...) 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.
We can't really see that as a solution, it kid of work for us because we have access to colibri skin but we have to find a real extendable solution for anyone who write a java macro.
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).
I think the only clean solution from extension architecture POV is b).
2b makes it a bit tough to customize, which might be ok for third party macros, but for the platform macros, we might want to leave room for this.
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.
For me this is almost as bad as 1/
For the macros that come with the platform it's not such a bad solution, third party macro authors will still have 2b as a solution. The issue with 2 in general is that the css becomes immensely fragmented: you'd have a separate CSS file fetch for each macro that needs styles, which slows down page loading. I guess this is the very reason why we have everything in colibri.css at the moment. Which is why, for the macros that come with the platform by default, we should have a solution that optimizes this and grabs all the css in one fetch. Of course, we could make it an 'on demand', meaning that this platform.css will be asked for by the macros in the platform that know they need it. Also, we can also improve the skin extension to make it generate a file from multiple ".use" calls that it receives, but it should still be one single file, to allow caching on the client side.
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).
Side note: be careful with css and macros it's easy to make it unusable for anything except XHTML renderer.
well, well... :) I guess when it comes to layout and decoration, it's gonna be necessarily bound to a renderer. e.g. in the columns case, I don't know how to make sure that columns will happen on any renderer. I do have groups around each column allowing a potential other renderer to lay them out the way it needs them, but more than that I don't know how to do. Unless we make these decoration notions (or some of them), part of the abstract syntax tree model (i.e. invent blocks for it, or reserved attributes at XDOM level, etc). It will be hard to cover it all, though. Thanks, Anca
Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Dec 29, 2010 at 11:58, Anca Luca <[email protected]> wrote:
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
On Tue, Dec 28, 2010 at 16:13, Anca Luca<[email protected]> 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.enterpr...) 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.
We can't really see that as a solution, it kid of work for us because we have access to colibri skin but we have to find a real extendable solution for anyone who write a java macro.
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).
I think the only clean solution from extension architecture POV is b).
2b makes it a bit tough to customize, which might be ok for third party macros, but for the platform macros, we might want to leave room for this.
As you said yourself that's not a real issue since you can customize it with some more css.
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.
For me this is almost as bad as 1/
For the macros that come with the platform it's not such a bad solution, third party macro authors will still have 2b as a solution.
My point is that we need a solution for third party anyway. Also for me you are putting way to many thing in what you call "platform". For me most of the macros are extension you have installed or not in your wiki, the fact that a macro is provided by us does not make it a forced macro.
The issue with 2 in general is that the css becomes immensely fragmented: you'd have a separate CSS file fetch for each macro that needs styles, which slows down page loading. I guess this is the very reason why we have everything in colibri.css at the moment. Which is why, for the macros that come with the platform by default, we should have a solution that optimizes this and grabs all the css in one fetch. Of course, we could make it an 'on demand', meaning that this platform.css will be asked for by the macros in the platform that know they need it. Also, we can also improve the skin extension to make it generate a file from multiple ".use" calls that it receives, but it should still be one single file, to allow caching on the client side.
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).
Side note: be careful with css and macros it's easy to make it unusable for anything except XHTML renderer.
well, well... :) I guess when it comes to layout and decoration, it's gonna be necessarily bound to a renderer. e.g. in the columns case, I don't know how to make sure that columns will happen on any renderer. I do have groups around each column allowing a potential other renderer to lay them out the way it needs them, but more than that I don't know how to do.
Unless we make these decoration notions (or some of them), part of the abstract syntax tree model (i.e. invent blocks for it, or reserved attributes at XDOM level, etc). It will be hard to cover it all, though.
Thanks, Anca
Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Thomas, On 12/29/2010 01:31 PM, Thomas Mortagne wrote:
On Wed, Dec 29, 2010 at 11:58, Anca Luca<[email protected]> wrote:
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
On Tue, Dec 28, 2010 at 16:13, Anca Luca<[email protected]> 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.enterpr...) 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.
We can't really see that as a solution, it kid of work for us because we have access to colibri skin but we have to find a real extendable solution for anyone who write a java macro.
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).
I think the only clean solution from extension architecture POV is b).
2b makes it a bit tough to customize, which might be ok for third party macros, but for the platform macros, we might want to leave room for this.
As you said yourself that's not a real issue since you can customize it with some more css.
More or less. Yes we can customize it, but not fully (cascading works only if you can have stronger selectors, etc). Also I'm not sure I want to go for this as the "default" and "recommended" method, since it means packing css and js in "binaries", when CSS is declarative. It doesn't make too much sense as a principle, it would mean that if one wants to read such a css, remove or edit it, he would have to go in the jar, unpack, see what's in there. It's a bit awkward as a paradigm, for me. But then again, ff extensions are packed as jars as well, so I guess it's an ok archiving format.
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.
For me this is almost as bad as 1/
For the macros that come with the platform it's not such a bad solution, third party macro authors will still have 2b as a solution.
My point is that we need a solution for third party anyway. Also for me you are putting way to many thing in what you call "platform".
I agree...
For me most of the macros are extension you have installed or not in your wiki, the fact that a macro is provided by us does not make it a forced macro.
... BUT, I'm just trying to figure out how to create a distributable which is not slow _by default_. It's like you'd download the default Firefox, run it with no modifications, complain it's slow and then be told that "well, it's not firefox which is slow, it's the extensions, you have too many extensions". Either we need to rethink what we distribute, or we need to have a way to make at least the default package(s) as fast as possible. Thanks, Anca
The issue with 2 in general is that the css becomes immensely fragmented: you'd have a separate CSS file fetch for each macro that needs styles, which slows down page loading. I guess this is the very reason why we have everything in colibri.css at the moment. Which is why, for the macros that come with the platform by default, we should have a solution that optimizes this and grabs all the css in one fetch. Of course, we could make it an 'on demand', meaning that this platform.css will be asked for by the macros in the platform that know they need it. Also, we can also improve the skin extension to make it generate a file from multiple ".use" calls that it receives, but it should still be one single file, to allow caching on the client side.
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).
Side note: be careful with css and macros it's easy to make it unusable for anything except XHTML renderer.
well, well... :) I guess when it comes to layout and decoration, it's gonna be necessarily bound to a renderer. e.g. in the columns case, I don't know how to make sure that columns will happen on any renderer. I do have groups around each column allowing a potential other renderer to lay them out the way it needs them, but more than that I don't know how to do.
Unless we make these decoration notions (or some of them), part of the abstract syntax tree model (i.e. invent blocks for it, or reserved attributes at XDOM level, etc). It will be hard to cover it all, though.
Thanks, Anca
Thanks, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Dec 29, 2010 at 14:40, Anca Luca <[email protected]> wrote:
Hi Thomas,
On 12/29/2010 01:31 PM, Thomas Mortagne wrote:
On Wed, Dec 29, 2010 at 11:58, Anca Luca<[email protected]> wrote:
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
On Tue, Dec 28, 2010 at 16:13, Anca Luca<[email protected]> 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.enterpr...) 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.
We can't really see that as a solution, it kid of work for us because we have access to colibri skin but we have to find a real extendable solution for anyone who write a java macro.
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).
I think the only clean solution from extension architecture POV is b).
2b makes it a bit tough to customize, which might be ok for third party macros, but for the platform macros, we might want to leave room for this.
As you said yourself that's not a real issue since you can customize it with some more css.
More or less. Yes we can customize it, but not fully (cascading works only if you can have stronger selectors, etc).
Also I'm not sure I want to go for this as the "default" and "recommended" method, since it means packing css and js in "binaries", when CSS is declarative. It doesn't make too much sense as a principle, it would mean that if one wants to read such a css, remove or edit it, he would have to go in the jar, unpack, see what's in there. It's a bit awkward as a paradigm, for me.
But then again, ff extensions are packed as jars as well, so I guess it's an ok archiving format.
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.
For me this is almost as bad as 1/
For the macros that come with the platform it's not such a bad solution, third party macro authors will still have 2b as a solution.
My point is that we need a solution for third party anyway. Also for me you are putting way to many thing in what you call "platform".
I agree...
For me most of the macros are extension you have installed or not in your wiki, the fact that a macro is provided by us does not make it a forced macro.
... BUT, I'm just trying to figure out how to create a distributable which is not slow _by default_.
It's like you'd download the default Firefox, run it with no modifications, complain it's slow and then be told that "well, it's not firefox which is slow, it's the extensions, you have too many extensions".
Not sure Firefox is a good comparison with XWiki architecture, it's more like Eclipse.
Either we need to rethink what we distribute, or we need to have a way to make at least the default package(s) as fast as possible.
Thanks, Anca
The issue with 2 in general is that the css becomes immensely fragmented: you'd have a separate CSS file fetch for each macro that needs styles, which slows down page loading. I guess this is the very reason why we have everything in colibri.css at the moment. Which is why, for the macros that come with the platform by default, we should have a solution that optimizes this and grabs all the css in one fetch. Of course, we could make it an 'on demand', meaning that this platform.css will be asked for by the macros in the platform that know they need it. Also, we can also improve the skin extension to make it generate a file from multiple ".use" calls that it receives, but it should still be one single file, to allow caching on the client side.
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).
Side note: be careful with css and macros it's easy to make it unusable for anything except XHTML renderer.
well, well... :) I guess when it comes to layout and decoration, it's gonna be necessarily bound to a renderer. e.g. in the columns case, I don't know how to make sure that columns will happen on any renderer. I do have groups around each column allowing a potential other renderer to lay them out the way it needs them, but more than that I don't know how to do.
Unless we make these decoration notions (or some of them), part of the abstract syntax tree model (i.e. invent blocks for it, or reserved attributes at XDOM level, etc). It will be hard to cover it all, though.
Thanks, Anca
Thanks, Anca _______________________________________________ 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
-- Thomas Mortagne
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.enterpr...) 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 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. 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. 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. 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. 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. 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. regards Andreas
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.enterpr...) 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
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.enterpr...) 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
On 01/06/2011 11:31 PM, Andreas Hahn wrote:
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 ?
Depends on the project, depends on the future evolution, depends on the size and collaboration patterns in the team. I'm not an adept of the "one tool for everything" ideology, and I know XWiki is not the right tool for everything. If you need a simple publishing tool, then it's best to pick a tool which does only that, since it's most likely that it will do it way better than more generic tools. But some projects evolve, and then you might end up with a tool that's too limited to allow that evolution, and without knowing it, you'll be limited by the chosen tool. "If all you have is a hammer, everything looks like a nail". -- Sergiu Dumitriu http://purl.org/net/sergiu/
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.enterpr...) 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).
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 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. 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. 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.
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. 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.
As Anca said, you can add classnames to any portion of text with (% class="..." %)((( content here ))), and the macros for which a classname makes sense do usually have such a parameter.
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.
No, that's not true. Let me get this straight: *It is much harder to style WordPress or other "popular" frameworks than XWiki*. And I mean that without any tutorials, samples or tools, styling XWiki is much more flexible, and much easier. The advantage of popular frameworks is that they are more popular, with much more users, much more interest, and an already established market. 1. When you style WordPress, you don't write a CSS file for it. You write the full frontend, from <html> to </html>, and you're forced to respect their requirements: "you must call this PHP function to display the login/logout section, you must call this PHP function to display the panels, ...". In XWiki you write as much code as you need, you can start with just a color theme (for which there's a nice WYSIWYG wizard), or a SSX object, or a Skin document with overridden templates attached to it. Sure, you can go low-level and write a full skin on the filesystem, but that really should be avoided unless you need a major interface overhaul. 2. Installing a theme for all those PHP applications is hard. Sure, they make it sound easy, "download the zip, extract it, put it in this folder on the server, change this configuration file". Installing a proper XWiki theme could be as simple as selecting a xar from the future XWiki app store. We don't have support for .xar extensions in the extension manager yet, but it will be available in 3.0, and during the 3.x cycle we'll build a very user friendly extension manager. And we don't have such easy to install skins yet because nobody provided one yet. The core developers don't have enough time to write extra skins when the users are complaining about core functionality. And the users aren't contributing their skins back in the extensions.xwiki.org repository, although I've seen spectacular skins on top of XWiki out in the wild. 3. XWiki is not a blogging software, it is a *Development Platform*. This means that you can't style XWiki, you can style the generic layout, and then you can style different components. We're adding new macros all the time, and users can develop whatever application they want, so we can't make a style for *everything that ever was and will ever be running in a XWiki instance*. Thus, given the extraordinary flexibility that only XWiki provides, we're doing pretty well when it comes to styling. 4. To help overcome a bit the many degrees of freedom mentioned in 3, we're providing several tools. The most important one is the color theme, which allows to style components in a consistent manner with the global skin. Then there are all the skin extensions plugins that allow to develop standalone components/applications which bring their own style, of course closely integrated in the current theme, since they're using the color theme. Then there are the standards that we've been creating and documenting, like http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms and http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses which should help users (and committers as well) create extensions that fit well inside XWiki. And we're planning more for the future. 5. Let me repeat that: XWiki is not harder to style than other popular frameworks. There are so much more skins to use or buy for them simply because there's a well established market for them. Simple users can't easily write a skin for WP, but they can easily find an existing one to download for free or for money. That's not a merit of the technical aspects of WP, but of the community and market size.
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.
regards
Andreas
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On 01/04/2011 05:28 PM, Sergiu Dumitriu wrote:
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.enterpr...)
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).
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 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. 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. 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.
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. 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.
As Anca said, you can add classnames to any portion of text with (% class="..." %)((( content here ))), and the macros for which a classname makes sense do usually have such a parameter.
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.
No, that's not true. Let me get this straight: *It is much harder to style WordPress or other "popular" frameworks than XWiki*.
And I mean that without any tutorials, samples or tools, styling XWiki is much more flexible, and much easier. The advantage of popular frameworks is that they are more popular, with much more users, much more interest, and an already established market.
1. When you style WordPress, you don't write a CSS file for it. You write the full frontend, from <html> to </html>, and you're forced to respect their requirements: "you must call this PHP function to display the login/logout section, you must call this PHP function to display the panels, ...". In XWiki you write as much code as you need, you can start with just a color theme (for which there's a nice WYSIWYG wizard), or a SSX object, or a Skin document with overridden templates attached to it. Sure, you can go low-level and write a full skin on the filesystem, but that really should be avoided unless you need a major interface overhaul.
2. Installing a theme for all those PHP applications is hard. Sure, they make it sound easy, "download the zip, extract it, put it in this folder on the server, change this configuration file". Installing a proper XWiki theme could be as simple as selecting a xar from the future XWiki app store. We don't have support for .xar extensions in the extension manager yet, but it will be available in 3.0, and during the 3.x cycle we'll build a very user friendly extension manager. And we don't have such easy to install skins yet because nobody provided one yet. The core developers don't have enough time to write extra skins when the users are complaining about core functionality. And the users aren't contributing their skins back in the extensions.xwiki.org repository, although I've seen spectacular skins on top of XWiki out in the wild.
3. XWiki is not a blogging software, it is a *Development Platform*. This means that you can't style XWiki, you can style the generic layout, and then you can style different components. We're adding new macros all the time, and users can develop whatever application they want, so we can't make a style for *everything that ever was and will ever be running in a XWiki instance*. Thus, given the extraordinary flexibility that only XWiki provides, we're doing pretty well when it comes to styling.
4. To help overcome a bit the many degrees of freedom mentioned in 3, we're providing several tools. The most important one is the color theme, which allows to style components in a consistent manner with the global skin. Then there are all the skin extensions plugins that allow to develop standalone components/applications which bring their own style, of course closely integrated in the current theme, since they're using the color theme. Then there are the standards that we've been creating and documenting, like http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms and http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses which should help users (and committers as well) create extensions that fit well inside XWiki. And we're planning more for the future.
5. Let me repeat that: XWiki is not harder to style than other popular frameworks. There are so much more skins to use or buy for them simply because there's a well established market for them. Simple users can't easily write a skin for WP, but they can easily find an existing one to download for free or for money. That's not a merit of the technical aspects of WP, but of the community and market size.
Well, if you have any specific complaints to make, please report them, we'll be happy to improve what we can. I'm not saying that styling XWiki is perfect, just that it's not as hard as some say it is.
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.
regards
Andreas
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Am 04.01.2011 17:28, schrieb Sergiu Dumitriu:
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.enterpr...) 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).
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 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. 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. 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.
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. 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. As Anca said, you can add classnames to any portion of text with (% class="..." %)((( content here ))), and the macros for which a classname makes sense do usually have such a parameter.
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. No, that's not true. Let me get this straight: *It is much harder to style WordPress or other "popular" frameworks than XWiki*.
And I mean that without any tutorials, samples or tools, styling XWiki is much more flexible, and much easier. The advantage of popular frameworks is that they are more popular, with much more users, much more interest, and an already established market.
1. When you style WordPress, you don't write a CSS file for it. You write the full frontend, from<html> to</html>, and you're forced to respect their requirements: "you must call this PHP function to display the login/logout section, you must call this PHP function to display the panels, ...". In XWiki you write as much code as you need, you can start with just a color theme (for which there's a nice WYSIWYG wizard), or a SSX object, or a Skin document with overridden templates attached to it. Sure, you can go low-level and write a full skin on the filesystem, but that really should be avoided unless you need a major interface overhaul.
2. Installing a theme for all those PHP applications is hard. Sure, they make it sound easy, "download the zip, extract it, put it in this folder on the server, change this configuration file". Installing a proper XWiki theme could be as simple as selecting a xar from the future XWiki app store. We don't have support for .xar extensions in the extension manager yet, but it will be available in 3.0, and during the 3.x cycle we'll build a very user friendly extension manager. And we don't have such easy to install skins yet because nobody provided one yet. The core developers don't have enough time to write extra skins when the users are complaining about core functionality. And the users aren't contributing their skins back in the extensions.xwiki.org repository, although I've seen spectacular skins on top of XWiki out in the wild.
3. XWiki is not a blogging software, it is a *Development Platform*. This means that you can't style XWiki, you can style the generic layout, and then you can style different components. We're adding new macros all the time, and users can develop whatever application they want, so we can't make a style for *everything that ever was and will ever be running in a XWiki instance*. Thus, given the extraordinary flexibility that only XWiki provides, we're doing pretty well when it comes to styling.
4. To help overcome a bit the many degrees of freedom mentioned in 3, we're providing several tools. The most important one is the color theme, which allows to style components in a consistent manner with the global skin. Then there are all the skin extensions plugins that allow to develop standalone components/applications which bring their own style, of course closely integrated in the current theme, since they're using the color theme. Then there are the standards that we've been creating and documenting, like http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms and http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses which should help users (and committers as well) create extensions that fit well inside XWiki. And we're planning more for the future.
5. Let me repeat that: XWiki is not harder to style than other popular frameworks. There are so much more skins to use or buy for them simply because there's a well established market for them. Simple users can't easily write a skin for WP, but they can easily find an existing one to download for free or for money. That's not a merit of the technical aspects of WP, but of the community and market size.
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.
regards
Andreas Sergiu, thank you for the time you've taken for your answer. I can hear your haertbeat. You are right to some extent from a technical point of view. I'm operating XWiki for a couple of customers for our other consulting business as a documentation platform. No need for great designs - all are happy - they will go with what we offer.
Now I'm trying to set up another service in an area where we need to catch attention. It should be good looking - it should be distinctive - it's sort of personal dedication: budget is small. I don't agree with your conclusion that with WordPress "*It is much harder to style WordPress or other "popular" frameworks than XWiki*" because for Wordpress you buy a tool like Artisteer for a few bucks to do the job. If you need a more individual solution you call for a tender on a market place like 99designs.com. You say "I've seen spectacular skins on top of XWiki out in the wild." Could you name one or two (other than XWiki.com) that is publicly accessible and compares favorably to one of the many custom WordPress desings ? The XWiki testimonials are not a real help they are either ugly or outdated. I understand what you are saying about a XWiki as a development platform. Question : Have you ever played with a tool like artisteer ? I am sure you haven't. You should download the demo from artisteer.com and look what it does. I want to clarify that I'm not saying that you should make XWiki compatible to some individual tools. But- what Artisteer does is that you can design the layout of a WebPage - no matter if powered by WordPress or Joomla or Drupal by a couple of simple steps Header, Left, Right, Menu ... And I'm really pissed that my 17 year old son produces with a couple of mouseclicks a smarter design than I will ever do in a day or two and it seems such a bareer to join this creative output with an XWiki installation. Ok, I'm sorry so much to say still left but I must come to an end now - notebook battery is going low - and I need some sleep now. If you like we might have a talk on skype - it is not so time consuming as detailed mails. kind regards Andreas
On 01/05/2011 01:21 AM, Andreas Hahn wrote:
Am 04.01.2011 17:28, schrieb Sergiu Dumitriu:
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.enterpr...) 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).
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 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. 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. 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.
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. 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. As Anca said, you can add classnames to any portion of text with (% class="..." %)((( content here ))), and the macros for which a classname makes sense do usually have such a parameter.
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. No, that's not true. Let me get this straight: *It is much harder to style WordPress or other "popular" frameworks than XWiki*.
And I mean that without any tutorials, samples or tools, styling XWiki is much more flexible, and much easier. The advantage of popular frameworks is that they are more popular, with much more users, much more interest, and an already established market.
1. When you style WordPress, you don't write a CSS file for it. You write the full frontend, from<html> to</html>, and you're forced to respect their requirements: "you must call this PHP function to display the login/logout section, you must call this PHP function to display the panels, ...". In XWiki you write as much code as you need, you can start with just a color theme (for which there's a nice WYSIWYG wizard), or a SSX object, or a Skin document with overridden templates attached to it. Sure, you can go low-level and write a full skin on the filesystem, but that really should be avoided unless you need a major interface overhaul.
2. Installing a theme for all those PHP applications is hard. Sure, they make it sound easy, "download the zip, extract it, put it in this folder on the server, change this configuration file". Installing a proper XWiki theme could be as simple as selecting a xar from the future XWiki app store. We don't have support for .xar extensions in the extension manager yet, but it will be available in 3.0, and during the 3.x cycle we'll build a very user friendly extension manager. And we don't have such easy to install skins yet because nobody provided one yet. The core developers don't have enough time to write extra skins when the users are complaining about core functionality. And the users aren't contributing their skins back in the extensions.xwiki.org repository, although I've seen spectacular skins on top of XWiki out in the wild.
3. XWiki is not a blogging software, it is a *Development Platform*. This means that you can't style XWiki, you can style the generic layout, and then you can style different components. We're adding new macros all the time, and users can develop whatever application they want, so we can't make a style for *everything that ever was and will ever be running in a XWiki instance*. Thus, given the extraordinary flexibility that only XWiki provides, we're doing pretty well when it comes to styling.
4. To help overcome a bit the many degrees of freedom mentioned in 3, we're providing several tools. The most important one is the color theme, which allows to style components in a consistent manner with the global skin. Then there are all the skin extensions plugins that allow to develop standalone components/applications which bring their own style, of course closely integrated in the current theme, since they're using the color theme. Then there are the standards that we've been creating and documenting, like http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms and http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses which should help users (and committers as well) create extensions that fit well inside XWiki. And we're planning more for the future.
5. Let me repeat that: XWiki is not harder to style than other popular frameworks. There are so much more skins to use or buy for them simply because there's a well established market for them. Simple users can't easily write a skin for WP, but they can easily find an existing one to download for free or for money. That's not a merit of the technical aspects of WP, but of the community and market size.
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.
regards
Andreas Sergiu, thank you for the time you've taken for your answer. I can hear your haertbeat.
Hm, I might have sounded a bit harsh, but I wasn't, I was simply voicing my opinion. Look, I'm friendly: :)
You are right to some extent from a technical point of view. I'm operating XWiki for a couple of customers for our other consulting business as a documentation platform. No need for great designs - all are happy - they will go with what we offer.
Now I'm trying to set up another service in an area where we need to catch attention. It should be good looking - it should be distinctive - it's sort of personal dedication: budget is small.
I don't agree with your conclusion that with WordPress "*It is much harder to style WordPress or other "popular" frameworks than XWiki*" because for Wordpress you buy a tool like Artisteer for a few bucks to do the job. If you need a more individual solution you call for a tender on a market place like 99designs.com.
Right, you either: - get someone else to do it, which doesn't imply that it's easier to do it for Wordpress, just that there are more people that do skins - use a third party tool to help you with it, but that tool has nothing to do with how hard or easy it is technically to style Joomla or Wordpress, just that somebody took the time to provide a nice UI to hide the messy details. I haven't tried Artisteer yet, but looking at their demo, something similar can be done for XWiki as well, just that nobody did it yet.
You say "I've seen spectacular skins on top of XWiki out in the wild." Could you name one or two (other than XWiki.com) that is publicly accessible and compares favorably to one of the many custom WordPress desings ? The XWiki testimonials are not a real help they are either ugly or outdated.
A quick Google search gave me some results; they aren't necessarily beautiful, but they are very diverse and can show that XWiki can be changed drasticly if you want to: http://www.spagoworld.org/ http://www.alenty.com/ http://www.curriki.org/ http://www.aelia.com/ http://www.espritsdentreprises.fr/ http://www.uaic.ro/ http://www.info.uaic.ro/ http://www.cinquiemesens.com/ http://www.socracy.org/ http://www.easybeans.net/ https://eu.globotraders-tahiti.com/ https://eu.hotelkiaora.com/ http://wiki.jonas.ow2.org/ http://www.antoniogoncalves.org/ http://i2geo.net/ https://wiki.noiv.nl/ https://www.goldenboysbet.com/ http://hub.opensolaris.org/ http://nepomuk.semanticdesktop.org/ http://www.ow2.org/ http://www.caast-net.org/ Plus, working for XWiki SAS I've seen lots of good looking designs implemented as intranets, thus not public.
I understand what you are saying about a XWiki as a development platform. Question : Have you ever played with a tool like artisteer ? I am sure you haven't. You should download the demo from artisteer.com and look what it does.
Yes, but the ease of customization is actually a feature of Artisteer, and that's shows nothing of how easy it is *internally* to create a custom skin for the supported platforms. You don't know how many days or months did the developers of Artisteer spent on making their tool support each framework. Don't blame XWiki for the lack of support in Artisteer, and don't praise WordPress for the existence of Artisteer. I do agree that it would be nice to have such tools on top of XWiki, but the platform developers have little time to work on one, and third party companies didn't get enough requests to see the benefit of writing such a tool. Part of the problem is also the main target of the software. The average WordPress installation has only one user, so there are hundreds of thousands of WordPress instances, thus the request for so many skins. The average WordPress user has NO knowledge of CSS, thus most of those WordPress owners will buy a skin, either already made, or designed in a visual tool. Thus, there's a huge market for WordPress skins. The average XWiki installation has hundreds of users (the name, "XWiki Enterprise", already defines the main target), thus the number of installations is much smaller. Then, XWiki is usually installed by the IT department of a company, or by a contractor, which IT department/contractor knows how to play with CSS, this is their job.
I want to clarify that I'm not saying that you should make XWiki compatible to some individual tools. But- what Artisteer does is that you can design the layout of a WebPage - no matter if powered by WordPress or Joomla or Drupal by a couple of simple steps Header, Left, Right, Menu ...
The same can be done by the Color Theme Wizard introduced in 2.3, did you try it? http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise23#HC... The image selection is not very nice at the moment, it was left as a TODO, but it's already flexible enough. It can be further improved, and any contributions are welcome. Still, this is more than most other tools provide *By Default* in their standalone installation, not as a third party, non-free application.
And I'm really pissed that my 17 year old son produces with a couple of mouseclicks a smarter design than I will ever do in a day or two and it seems such a bareer to join this creative output with an XWiki installation.
Ok, I'm sorry so much to say still left but I must come to an end now - notebook battery is going low - and I need some sleep now. If you like we might have a talk on skype - it is not so time consuming as detailed mails.
kind regards
Andreas
Friendly, -- Sergiu Dumitriu http://purl.org/net/sergiu/
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.enterpr...) 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). -- Sergiu Dumitriu http://purl.org/net/sergiu/
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.enterpr...) 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. WDYT? Thanks, Marius
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.enterpr...) 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
participants (5)
-
Anca Luca -
Andreas Hahn -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne