28 Dec
2010
28 Dec
'10
4:13 p.m.
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.enterp…)
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
29 Dec
29 Dec
9:51 a.m.
On Tue, Dec 28, 2010 at 16:13, Anca Luca <lucaa(a)xwiki.com> 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.enterp…)
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
11:58 a.m.
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
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.
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
On Tue, Dec 28, 2010 at 16:13, Anca
Luca<lucaa(a)xwiki.com> wrote:
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.
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.enterp…)
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:31 p.m.
On Wed, Dec 29, 2010 at 11:58, Anca Luca <lucaa(a)xwiki.com> wrote:
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.
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
As you said yourself that's not a real issue since you can customize
it with some more css.
On Tue, Dec 28, 2010 at 16:13, Anca
Luca<lucaa(a)xwiki.com> wrote:
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. 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.enterp…)
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/
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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:40 p.m.
Hi Thomas,
On 12/29/2010 01:31 PM, Thomas Mortagne wrote:
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...
On Wed, Dec 29, 2010 at 11:58, Anca
Luca<lucaa(a)xwiki.com> wrote:
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.
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
As you said yourself that's not a real issue since you can customize
it with some more css. On Tue, Dec 28, 2010 at 16:13, Anca
Luca<lucaa(a)xwiki.com> wrote:
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. 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.enterp…)
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/ 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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:49 p.m.
On Wed, Dec 29, 2010 at 14:40, Anca Luca <lucaa(a)xwiki.com> wrote:
Hi Thomas,
On 12/29/2010 01:31 PM, Thomas Mortagne wrote:
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...
Not sure Firefox is a good comparison with XWiki architecture, it's
more like Eclipse.
On Wed, Dec 29, 2010 at 11:58, Anca
Luca<lucaa(a)xwiki.com> wrote:
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.
Hi Thomas, all
On 12/29/2010 09:51 AM, Thomas Mortagne wrote:
As you said yourself that's not a real issue since you can customize
it with some more css. On Tue, Dec 28, 2010 at 16:13, Anca
Luca<lucaa(a)xwiki.com> 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.enterp…)
> 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. 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3 Jan
3 Jan
11:47 p.m.
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.enterp…)
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
devs(a)xwiki.org
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
4 Jan
4 Jan
10:28 a.m.
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:
I don't know how wordpress is working, I will need to document on that
before I answer this topic.
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.enterp…)
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
devs(a)xwiki.org
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 Jan
6 Jan
11:31 p.m.
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:
I don't know how
wordpress is working, I will need to document on that
before I answer this topic.
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.enterp…)
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
devs(a)xwiki.org
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9 Jan
9 Jan
4:22 a.m.
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/
4 Jan
4 Jan
5:28 p.m.
On 01/03/2011 11:47 PM, Andreas Hahn wrote:
Am 28.12.2010 16:13, schrieb Anca Luca:
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.
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.enterp…)
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. 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/
5:33 p.m.
On 01/04/2011 05:28 PM, Sergiu Dumitriu wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 01/03/2011 11:47 PM, Andreas Hahn wrote:
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.
Am 28.12.2010 16:13, schrieb Anca Luca:
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.
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.enterp…)
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. 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
5 Jan
5 Jan
1:21 a.m.
Am 04.01.2011 17:28, schrieb Sergiu Dumitriu:
On 01/03/2011 11:47 PM, Andreas Hahn wrote:
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
Am 28.12.2010 16:13, schrieb Anca Luca:
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.
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.enterp…)
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. 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
9 Jan
9 Jan
4:12 a.m.
On 01/05/2011 01:21 AM, Andreas Hahn wrote:
Am 04.01.2011 17:28, schrieb Sergiu Dumitriu:
Hm, I might have sounded a bit harsh, but I wasn't, I was simply voicing
my opinion. Look, I'm friendly:
:)
On 01/03/2011 11:47 PM, Andreas Hahn wrote:
Sergiu, thank you for the time you've taken for your answer. I can
hear
your haertbeat. Am 28.12.2010 16:13, schrieb Anca Luca:
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.
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.enterp…)
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. 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 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#H…
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/
4 Jan
4 Jan
4:44 p.m.
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.enterp…)
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/
7 Jan
7 Jan
10:29 a.m.
On 01/04/2011 05:44 PM, Sergiu Dumitriu wrote:
On 12/28/2010 04:13 PM, Anca Luca wrote:
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 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.enterp…)
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).
noon
Hi all,
On 01/07/2011 10:29 AM, Marius Dumitru Florea wrote:
On 01/04/2011 05:44 PM, Sergiu Dumitriu wrote:
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.
On 12/28/2010 04:13 PM, Anca Luca wrote:
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. 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.enterp…)
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).
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5052
days inactive
5064
days old
16 comments
5 participants
participants (5)
-
Anca Luca -
Andreas Hahn -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne