[Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Denis Gervalle-2
Hi Devs,

As you may have noted from a previous mail, I have given a try to skin
XWiki differently, based on Bootstrap. There is certainly many ways to get
it done, but IMO, building over any pre-made css solution requires an
adaptation of the HTML generated.

In the early days of XWiki, the were few places were we have HTML
generated. Most of the html produce came from three major places:
1) .vm templates including macros.vm
2) java generated (#display())
3) XWiki tech document

While 2) and 3) either provide very basic markup or customizable one and
are not so much, and 1) was fully customizable by skins, to work out a new
skin was not too complex.

Today however, the UI of XWiki has considerably increase its complexity,
and the source of HTML has followed, added to the above 3:
 4) XWiki and Java macros
 5) JavaScript (ie: annotation UI, comments preview)

Changing all these places has become really more painful. There is no
central place, and a lot of hidden dependencies between UI components
exists. Worse examples are those written in JS, that hook into the UI.

I should admit that I have not a clear idea of the best way to improve
that, but my feeling is that changing so much places simply to adapt our
wiki skin to the "a la mode" skin solution (something that will happen
again) is not nice.

So this thread is now open for anyone to discuss the situation and for
anyone interested to provide its input to the discussion.

Looking at what I face building the UI with bootstrap, here is what I
noticed:

1) Bootstrap customize standard tags, without any css class associated
2) Bootstrap provide standard css classes to skin a given kind of UI
component
3) Bootstrap use these class and custom attribute to inject JS interactivity

All these are really clean methods and work really well at building very
simple html construct while providing nice looking and easy interface.

Let's take a concrete example, to build a button, you may use either an a
tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
You may complement it with additional 'btn-primary', 'btn-success', ... css
classes, to choose the kind of button you really want.

However, in our XWiki UI, there no single place where we construct buttons,
we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
we also do so in javascript, and finally in some wiki documents, maybe we
also generate some in a java component.
All those buttons are usually built the same, with a very similar HTML, but
there is no central place where the button markup is produced.

And the same is true for most UI component. You may say we don't care, and
CSS could solve them all, making any kind of markup look the way we want.
But, we will loose the benefit of using existing CSS solution. And there
are interesting benefit to that, since those solution gets customized, see
BootsWatch for example.

Therefore, it seems to me that we need something like an UI generator, so
that when you build a application, you would simply says, I want a primary
button here, a secondary button there, and it gets created both the way it
should for your apps to use it, but also for the UI design we want to use.

Defining a list of these UI component is not simple, but we may take
Bootstrap as a starting point. There is in Bootstrap a large number of
control already, that should cover many UI possibilities.

How to provide that UI component to all the places we need it may be less
obvious. For example, we need to create button from .vm, XWiki document,
XWiki and java Macros, and even from javascript. Also defining how you
could expect to interact with each control, from Javascript or from java on
the server needs clarification.

I have not yet googled, but there may be existing experience regarding
these matters on other project. Not reinventing the wheel is always better.
Your ideas are welcome.

IMO, we really need that if we want our Skin 4.x to be really more usable
for customization.

WDYT ?


--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Ecaterina Moraru (Valica)
Hi Denis,

When we discussed the Vertical Forms Standard [1] Thomas mentioned
something about "commons tools to follow that standard (like form related
wiki macros for example)". Some considered that having macros for standard
HTML controls will just duplicate HTML language.

One advantage of having such macros would be that for example (let's say
the macros will be defined in macros.vm) if you want to change the classes
used by the controls (like .buttonwrapper class for example), you are just
changing the macros, not all the places that call them.

This way you could easily change what classes you assign to a button for
example from span.buttonwrapper input.button.secondary to
button.btn.btn-primary (bootstrap way - of course we will also need to
standardize the usage component: input, button, a, etc.)

The example above refers mostly to standard HTML elements. Of course if you
want to use other types of components from different frameworks you will
need to rewrite the templates, and this always calls for a new skin.

I thought about new skins for XWiki and since I joined the project we
mostly deprecated old skins than creating new ones. But one problem I have
is the concept of base skin. For me the base skin should be something very
minimal.
It should contain just the typography, standard controls, the grid, the
reset, anyway elements that are not layout dependent and that will work for
any skin. I'm not sure about templates, because mostly templates refer to
layout and how you arrange things and what functionality you reveal and
where, and this usually change with a new skin. Technical the base skin
should contain the Standard, the base for things that will remain the same
no matter what. Right now Colibri covers much more than that.

And this standard is absolutely necessary also for the way we go with
extensions. We know very well that in an Open Source project, everybody
codes with his own style and having a common ground is essential from a
consistency point of view. All the applications that will be created and
published by the community members should have a common style that could
make them integrate well inside XWiki, no matter of the creator.

So the conclusion is that for this we will need a very well documented
standard and the tools to enforce it. Not sure what this means.

Also other things worth discussing is colorthemes variables and macros
against LESS variables and mixins.
Also the Bootstrap / LESS is also a direction bet, just like Prototype vs.
JQuery, and the solution we pick it would be great if it would be loosely
coupled.

Thanks,
Caty

P.S. Another discussion somehow related to extensibility is [Discussion]
Problematic ColorTheme extensibility
http://markmail.org/thread/ex6fgou6fl6vjwfr

[1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms


On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]> wrote:

> Hi Devs,
>
> As you may have noted from a previous mail, I have given a try to skin
> XWiki differently, based on Bootstrap. There is certainly many ways to get
> it done, but IMO, building over any pre-made css solution requires an
> adaptation of the HTML generated.
>
> In the early days of XWiki, the were few places were we have HTML
> generated. Most of the html produce came from three major places:
> 1) .vm templates including macros.vm
> 2) java generated (#display())
> 3) XWiki tech document
>
> While 2) and 3) either provide very basic markup or customizable one and
> are not so much, and 1) was fully customizable by skins, to work out a new
> skin was not too complex.
>
> Today however, the UI of XWiki has considerably increase its complexity,
> and the source of HTML has followed, added to the above 3:
>  4) XWiki and Java macros
>  5) JavaScript (ie: annotation UI, comments preview)
>
> Changing all these places has become really more painful. There is no
> central place, and a lot of hidden dependencies between UI components
> exists. Worse examples are those written in JS, that hook into the UI.
>
> I should admit that I have not a clear idea of the best way to improve
> that, but my feeling is that changing so much places simply to adapt our
> wiki skin to the "a la mode" skin solution (something that will happen
> again) is not nice.
>
> So this thread is now open for anyone to discuss the situation and for
> anyone interested to provide its input to the discussion.
>
> Looking at what I face building the UI with bootstrap, here is what I
> noticed:
>
> 1) Bootstrap customize standard tags, without any css class associated
> 2) Bootstrap provide standard css classes to skin a given kind of UI
> component
> 3) Bootstrap use these class and custom attribute to inject JS
> interactivity
>
> All these are really clean methods and work really well at building very
> simple html construct while providing nice looking and easy interface.
>
> Let's take a concrete example, to build a button, you may use either an a
> tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
> You may complement it with additional 'btn-primary', 'btn-success', ... css
> classes, to choose the kind of button you really want.
>
> However, in our XWiki UI, there no single place where we construct buttons,
> we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
> we also do so in javascript, and finally in some wiki documents, maybe we
> also generate some in a java component.
> All those buttons are usually built the same, with a very similar HTML, but
> there is no central place where the button markup is produced.
>
> And the same is true for most UI component. You may say we don't care, and
> CSS could solve them all, making any kind of markup look the way we want.
> But, we will loose the benefit of using existing CSS solution. And there
> are interesting benefit to that, since those solution gets customized, see
> BootsWatch for example.
>
> Therefore, it seems to me that we need something like an UI generator, so
> that when you build a application, you would simply says, I want a primary
> button here, a secondary button there, and it gets created both the way it
> should for your apps to use it, but also for the UI design we want to use.
>
> Defining a list of these UI component is not simple, but we may take
> Bootstrap as a starting point. There is in Bootstrap a large number of
> control already, that should cover many UI possibilities.
>
> How to provide that UI component to all the places we need it may be less
> obvious. For example, we need to create button from .vm, XWiki document,
> XWiki and java Macros, and even from javascript. Also defining how you
> could expect to interact with each control, from Javascript or from java on
> the server needs clarification.
>
> I have not yet googled, but there may be existing experience regarding
> these matters on other project. Not reinventing the wheel is always better.
> Your ideas are welcome.
>
> IMO, we really need that if we want our Skin 4.x to be really more usable
> for customization.
>
> WDYT ?
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Paul Libbrecht-2

Breaking the very broad toolset and knowledge of developers in HTML to create XWiki content and applications is, to me, suicidal.
Who would be ready to replace most of its html by macros?

Paul


On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote:

> Hi Denis,
>
> When we discussed the Vertical Forms Standard [1] Thomas mentioned
> something about "commons tools to follow that standard (like form related
> wiki macros for example)". Some considered that having macros for standard
> HTML controls will just duplicate HTML language.
>
> One advantage of having such macros would be that for example (let's say
> the macros will be defined in macros.vm) if you want to change the classes
> used by the controls (like .buttonwrapper class for example), you are just
> changing the macros, not all the places that call them.
>
> This way you could easily change what classes you assign to a button for
> example from span.buttonwrapper input.button.secondary to
> button.btn.btn-primary (bootstrap way - of course we will also need to
> standardize the usage component: input, button, a, etc.)
>
> The example above refers mostly to standard HTML elements. Of course if you
> want to use other types of components from different frameworks you will
> need to rewrite the templates, and this always calls for a new skin.
>
> I thought about new skins for XWiki and since I joined the project we
> mostly deprecated old skins than creating new ones. But one problem I have
> is the concept of base skin. For me the base skin should be something very
> minimal.
> It should contain just the typography, standard controls, the grid, the
> reset, anyway elements that are not layout dependent and that will work for
> any skin. I'm not sure about templates, because mostly templates refer to
> layout and how you arrange things and what functionality you reveal and
> where, and this usually change with a new skin. Technical the base skin
> should contain the Standard, the base for things that will remain the same
> no matter what. Right now Colibri covers much more than that.
>
> And this standard is absolutely necessary also for the way we go with
> extensions. We know very well that in an Open Source project, everybody
> codes with his own style and having a common ground is essential from a
> consistency point of view. All the applications that will be created and
> published by the community members should have a common style that could
> make them integrate well inside XWiki, no matter of the creator.
>
> So the conclusion is that for this we will need a very well documented
> standard and the tools to enforce it. Not sure what this means.
>
> Also other things worth discussing is colorthemes variables and macros
> against LESS variables and mixins.
> Also the Bootstrap / LESS is also a direction bet, just like Prototype vs.
> JQuery, and the solution we pick it would be great if it would be loosely
> coupled.
>
> Thanks,
> Caty
>
> P.S. Another discussion somehow related to extensibility is [Discussion]
> Problematic ColorTheme extensibility
> http://markmail.org/thread/ex6fgou6fl6vjwfr
>
> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms
>
>
> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]> wrote:
>
>> Hi Devs,
>>
>> As you may have noted from a previous mail, I have given a try to skin
>> XWiki differently, based on Bootstrap. There is certainly many ways to get
>> it done, but IMO, building over any pre-made css solution requires an
>> adaptation of the HTML generated.
>>
>> In the early days of XWiki, the were few places were we have HTML
>> generated. Most of the html produce came from three major places:
>> 1) .vm templates including macros.vm
>> 2) java generated (#display())
>> 3) XWiki tech document
>>
>> While 2) and 3) either provide very basic markup or customizable one and
>> are not so much, and 1) was fully customizable by skins, to work out a new
>> skin was not too complex.
>>
>> Today however, the UI of XWiki has considerably increase its complexity,
>> and the source of HTML has followed, added to the above 3:
>> 4) XWiki and Java macros
>> 5) JavaScript (ie: annotation UI, comments preview)
>>
>> Changing all these places has become really more painful. There is no
>> central place, and a lot of hidden dependencies between UI components
>> exists. Worse examples are those written in JS, that hook into the UI.
>>
>> I should admit that I have not a clear idea of the best way to improve
>> that, but my feeling is that changing so much places simply to adapt our
>> wiki skin to the "a la mode" skin solution (something that will happen
>> again) is not nice.
>>
>> So this thread is now open for anyone to discuss the situation and for
>> anyone interested to provide its input to the discussion.
>>
>> Looking at what I face building the UI with bootstrap, here is what I
>> noticed:
>>
>> 1) Bootstrap customize standard tags, without any css class associated
>> 2) Bootstrap provide standard css classes to skin a given kind of UI
>> component
>> 3) Bootstrap use these class and custom attribute to inject JS
>> interactivity
>>
>> All these are really clean methods and work really well at building very
>> simple html construct while providing nice looking and easy interface.
>>
>> Let's take a concrete example, to build a button, you may use either an a
>> tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
>> You may complement it with additional 'btn-primary', 'btn-success', ... css
>> classes, to choose the kind of button you really want.
>>
>> However, in our XWiki UI, there no single place where we construct buttons,
>> we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
>> we also do so in javascript, and finally in some wiki documents, maybe we
>> also generate some in a java component.
>> All those buttons are usually built the same, with a very similar HTML, but
>> there is no central place where the button markup is produced.
>>
>> And the same is true for most UI component. You may say we don't care, and
>> CSS could solve them all, making any kind of markup look the way we want.
>> But, we will loose the benefit of using existing CSS solution. And there
>> are interesting benefit to that, since those solution gets customized, see
>> BootsWatch for example.
>>
>> Therefore, it seems to me that we need something like an UI generator, so
>> that when you build a application, you would simply says, I want a primary
>> button here, a secondary button there, and it gets created both the way it
>> should for your apps to use it, but also for the UI design we want to use.
>>
>> Defining a list of these UI component is not simple, but we may take
>> Bootstrap as a starting point. There is in Bootstrap a large number of
>> control already, that should cover many UI possibilities.
>>
>> How to provide that UI component to all the places we need it may be less
>> obvious. For example, we need to create button from .vm, XWiki document,
>> XWiki and java Macros, and even from javascript. Also defining how you
>> could expect to interact with each control, from Javascript or from java on
>> the server needs clarification.
>>
>> I have not yet googled, but there may be existing experience regarding
>> these matters on other project. Not reinventing the wheel is always better.
>> Your ideas are welcome.
>>
>> IMO, we really need that if we want our Skin 4.x to be really more usable
>> for customization.
>>
>> WDYT ?
>>
>>
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> eGuilde sarl - CTO
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Jean-Vincent Drean
AFAIU the thread is not about breaking things, it's about using xwiki
syntax and macros (mostly for forms since the 2.0 syntax covers a lot
of the html markup) to benefit from a standardized styling. Existing
HTML would still be working, and it would be possible to write apps
with HTML, but you'd have to handle styling on your own.

On Thu, Jan 31, 2013 at 10:20 PM, Paul Libbrecht <[hidden email]> wrote:

>
> Breaking the very broad toolset and knowledge of developers in HTML to create XWiki content and applications is, to me, suicidal.
> Who would be ready to replace most of its html by macros?
>
> Paul
>
>
> On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote:
>
>> Hi Denis,
>>
>> When we discussed the Vertical Forms Standard [1] Thomas mentioned
>> something about "commons tools to follow that standard (like form related
>> wiki macros for example)". Some considered that having macros for standard
>> HTML controls will just duplicate HTML language.
>>
>> One advantage of having such macros would be that for example (let's say
>> the macros will be defined in macros.vm) if you want to change the classes
>> used by the controls (like .buttonwrapper class for example), you are just
>> changing the macros, not all the places that call them.
>>
>> This way you could easily change what classes you assign to a button for
>> example from span.buttonwrapper input.button.secondary to
>> button.btn.btn-primary (bootstrap way - of course we will also need to
>> standardize the usage component: input, button, a, etc.)
>>
>> The example above refers mostly to standard HTML elements. Of course if you
>> want to use other types of components from different frameworks you will
>> need to rewrite the templates, and this always calls for a new skin.
>>
>> I thought about new skins for XWiki and since I joined the project we
>> mostly deprecated old skins than creating new ones. But one problem I have
>> is the concept of base skin. For me the base skin should be something very
>> minimal.
>> It should contain just the typography, standard controls, the grid, the
>> reset, anyway elements that are not layout dependent and that will work for
>> any skin. I'm not sure about templates, because mostly templates refer to
>> layout and how you arrange things and what functionality you reveal and
>> where, and this usually change with a new skin. Technical the base skin
>> should contain the Standard, the base for things that will remain the same
>> no matter what. Right now Colibri covers much more than that.
>>
>> And this standard is absolutely necessary also for the way we go with
>> extensions. We know very well that in an Open Source project, everybody
>> codes with his own style and having a common ground is essential from a
>> consistency point of view. All the applications that will be created and
>> published by the community members should have a common style that could
>> make them integrate well inside XWiki, no matter of the creator.
>>
>> So the conclusion is that for this we will need a very well documented
>> standard and the tools to enforce it. Not sure what this means.
>>
>> Also other things worth discussing is colorthemes variables and macros
>> against LESS variables and mixins.
>> Also the Bootstrap / LESS is also a direction bet, just like Prototype vs.
>> JQuery, and the solution we pick it would be great if it would be loosely
>> coupled.
>>
>> Thanks,
>> Caty
>>
>> P.S. Another discussion somehow related to extensibility is [Discussion]
>> Problematic ColorTheme extensibility
>> http://markmail.org/thread/ex6fgou6fl6vjwfr
>>
>> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms
>>
>>
>> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]> wrote:
>>
>>> Hi Devs,
>>>
>>> As you may have noted from a previous mail, I have given a try to skin
>>> XWiki differently, based on Bootstrap. There is certainly many ways to get
>>> it done, but IMO, building over any pre-made css solution requires an
>>> adaptation of the HTML generated.
>>>
>>> In the early days of XWiki, the were few places were we have HTML
>>> generated. Most of the html produce came from three major places:
>>> 1) .vm templates including macros.vm
>>> 2) java generated (#display())
>>> 3) XWiki tech document
>>>
>>> While 2) and 3) either provide very basic markup or customizable one and
>>> are not so much, and 1) was fully customizable by skins, to work out a new
>>> skin was not too complex.
>>>
>>> Today however, the UI of XWiki has considerably increase its complexity,
>>> and the source of HTML has followed, added to the above 3:
>>> 4) XWiki and Java macros
>>> 5) JavaScript (ie: annotation UI, comments preview)
>>>
>>> Changing all these places has become really more painful. There is no
>>> central place, and a lot of hidden dependencies between UI components
>>> exists. Worse examples are those written in JS, that hook into the UI.
>>>
>>> I should admit that I have not a clear idea of the best way to improve
>>> that, but my feeling is that changing so much places simply to adapt our
>>> wiki skin to the "a la mode" skin solution (something that will happen
>>> again) is not nice.
>>>
>>> So this thread is now open for anyone to discuss the situation and for
>>> anyone interested to provide its input to the discussion.
>>>
>>> Looking at what I face building the UI with bootstrap, here is what I
>>> noticed:
>>>
>>> 1) Bootstrap customize standard tags, without any css class associated
>>> 2) Bootstrap provide standard css classes to skin a given kind of UI
>>> component
>>> 3) Bootstrap use these class and custom attribute to inject JS
>>> interactivity
>>>
>>> All these are really clean methods and work really well at building very
>>> simple html construct while providing nice looking and easy interface.
>>>
>>> Let's take a concrete example, to build a button, you may use either an a
>>> tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
>>> You may complement it with additional 'btn-primary', 'btn-success', ... css
>>> classes, to choose the kind of button you really want.
>>>
>>> However, in our XWiki UI, there no single place where we construct buttons,
>>> we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
>>> we also do so in javascript, and finally in some wiki documents, maybe we
>>> also generate some in a java component.
>>> All those buttons are usually built the same, with a very similar HTML, but
>>> there is no central place where the button markup is produced.
>>>
>>> And the same is true for most UI component. You may say we don't care, and
>>> CSS could solve them all, making any kind of markup look the way we want.
>>> But, we will loose the benefit of using existing CSS solution. And there
>>> are interesting benefit to that, since those solution gets customized, see
>>> BootsWatch for example.
>>>
>>> Therefore, it seems to me that we need something like an UI generator, so
>>> that when you build a application, you would simply says, I want a primary
>>> button here, a secondary button there, and it gets created both the way it
>>> should for your apps to use it, but also for the UI design we want to use.
>>>
>>> Defining a list of these UI component is not simple, but we may take
>>> Bootstrap as a starting point. There is in Bootstrap a large number of
>>> control already, that should cover many UI possibilities.
>>>
>>> How to provide that UI component to all the places we need it may be less
>>> obvious. For example, we need to create button from .vm, XWiki document,
>>> XWiki and java Macros, and even from javascript. Also defining how you
>>> could expect to interact with each control, from Javascript or from java on
>>> the server needs clarification.
>>>
>>> I have not yet googled, but there may be existing experience regarding
>>> these matters on other project. Not reinventing the wheel is always better.
>>> Your ideas are welcome.
>>>
>>> IMO, we really need that if we want our Skin 4.x to be really more usable
>>> for customization.
>>>
>>> WDYT ?
>>>
>>>
>>> --
>>> Denis Gervalle
>>> SOFTEC sa - CEO
>>> eGuilde sarl - CTO
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jean-Vincent Drean,
XWiki.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Paul Libbrecht-2
Correct Jean-Vincent, and I was probably too harsh describing it,

but I understood Ecaterina's point to be a strive for a radical request to move away from html.
Maybe this can be described in several stages?

paul


On 1 févr. 2013, at 11:09, Jean-Vincent Drean wrote:

> AFAIU the thread is not about breaking things, it's about using xwiki
> syntax and macros (mostly for forms since the 2.0 syntax covers a lot
> of the html markup) to benefit from a standardized styling. Existing
> HTML would still be working, and it would be possible to write apps
> with HTML, but you'd have to handle styling on your own.
>
> On Thu, Jan 31, 2013 at 10:20 PM, Paul Libbrecht <[hidden email]> wrote:
>>
>> Breaking the very broad toolset and knowledge of developers in HTML to create XWiki content and applications is, to me, suicidal.
>> Who would be ready to replace most of its html by macros?
>>
>> Paul
>>
>>
>> On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote:
>>
>>> Hi Denis,
>>>
>>> When we discussed the Vertical Forms Standard [1] Thomas mentioned
>>> something about "commons tools to follow that standard (like form related
>>> wiki macros for example)". Some considered that having macros for standard
>>> HTML controls will just duplicate HTML language.
>>>
>>> One advantage of having such macros would be that for example (let's say
>>> the macros will be defined in macros.vm) if you want to change the classes
>>> used by the controls (like .buttonwrapper class for example), you are just
>>> changing the macros, not all the places that call them.
>>>
>>> This way you could easily change what classes you assign to a button for
>>> example from span.buttonwrapper input.button.secondary to
>>> button.btn.btn-primary (bootstrap way - of course we will also need to
>>> standardize the usage component: input, button, a, etc.)
>>>
>>> The example above refers mostly to standard HTML elements. Of course if you
>>> want to use other types of components from different frameworks you will
>>> need to rewrite the templates, and this always calls for a new skin.
>>>
>>> I thought about new skins for XWiki and since I joined the project we
>>> mostly deprecated old skins than creating new ones. But one problem I have
>>> is the concept of base skin. For me the base skin should be something very
>>> minimal.
>>> It should contain just the typography, standard controls, the grid, the
>>> reset, anyway elements that are not layout dependent and that will work for
>>> any skin. I'm not sure about templates, because mostly templates refer to
>>> layout and how you arrange things and what functionality you reveal and
>>> where, and this usually change with a new skin. Technical the base skin
>>> should contain the Standard, the base for things that will remain the same
>>> no matter what. Right now Colibri covers much more than that.
>>>
>>> And this standard is absolutely necessary also for the way we go with
>>> extensions. We know very well that in an Open Source project, everybody
>>> codes with his own style and having a common ground is essential from a
>>> consistency point of view. All the applications that will be created and
>>> published by the community members should have a common style that could
>>> make them integrate well inside XWiki, no matter of the creator.
>>>
>>> So the conclusion is that for this we will need a very well documented
>>> standard and the tools to enforce it. Not sure what this means.
>>>
>>> Also other things worth discussing is colorthemes variables and macros
>>> against LESS variables and mixins.
>>> Also the Bootstrap / LESS is also a direction bet, just like Prototype vs.
>>> JQuery, and the solution we pick it would be great if it would be loosely
>>> coupled.
>>>
>>> Thanks,
>>> Caty
>>>
>>> P.S. Another discussion somehow related to extensibility is [Discussion]
>>> Problematic ColorTheme extensibility
>>> http://markmail.org/thread/ex6fgou6fl6vjwfr
>>>
>>> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms
>>>
>>>
>>> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> As you may have noted from a previous mail, I have given a try to skin
>>>> XWiki differently, based on Bootstrap. There is certainly many ways to get
>>>> it done, but IMO, building over any pre-made css solution requires an
>>>> adaptation of the HTML generated.
>>>>
>>>> In the early days of XWiki, the were few places were we have HTML
>>>> generated. Most of the html produce came from three major places:
>>>> 1) .vm templates including macros.vm
>>>> 2) java generated (#display())
>>>> 3) XWiki tech document
>>>>
>>>> While 2) and 3) either provide very basic markup or customizable one and
>>>> are not so much, and 1) was fully customizable by skins, to work out a new
>>>> skin was not too complex.
>>>>
>>>> Today however, the UI of XWiki has considerably increase its complexity,
>>>> and the source of HTML has followed, added to the above 3:
>>>> 4) XWiki and Java macros
>>>> 5) JavaScript (ie: annotation UI, comments preview)
>>>>
>>>> Changing all these places has become really more painful. There is no
>>>> central place, and a lot of hidden dependencies between UI components
>>>> exists. Worse examples are those written in JS, that hook into the UI.
>>>>
>>>> I should admit that I have not a clear idea of the best way to improve
>>>> that, but my feeling is that changing so much places simply to adapt our
>>>> wiki skin to the "a la mode" skin solution (something that will happen
>>>> again) is not nice.
>>>>
>>>> So this thread is now open for anyone to discuss the situation and for
>>>> anyone interested to provide its input to the discussion.
>>>>
>>>> Looking at what I face building the UI with bootstrap, here is what I
>>>> noticed:
>>>>
>>>> 1) Bootstrap customize standard tags, without any css class associated
>>>> 2) Bootstrap provide standard css classes to skin a given kind of UI
>>>> component
>>>> 3) Bootstrap use these class and custom attribute to inject JS
>>>> interactivity
>>>>
>>>> All these are really clean methods and work really well at building very
>>>> simple html construct while providing nice looking and easy interface.
>>>>
>>>> Let's take a concrete example, to build a button, you may use either an a
>>>> tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
>>>> You may complement it with additional 'btn-primary', 'btn-success', ... css
>>>> classes, to choose the kind of button you really want.
>>>>
>>>> However, in our XWiki UI, there no single place where we construct buttons,
>>>> we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
>>>> we also do so in javascript, and finally in some wiki documents, maybe we
>>>> also generate some in a java component.
>>>> All those buttons are usually built the same, with a very similar HTML, but
>>>> there is no central place where the button markup is produced.
>>>>
>>>> And the same is true for most UI component. You may say we don't care, and
>>>> CSS could solve them all, making any kind of markup look the way we want.
>>>> But, we will loose the benefit of using existing CSS solution. And there
>>>> are interesting benefit to that, since those solution gets customized, see
>>>> BootsWatch for example.
>>>>
>>>> Therefore, it seems to me that we need something like an UI generator, so
>>>> that when you build a application, you would simply says, I want a primary
>>>> button here, a secondary button there, and it gets created both the way it
>>>> should for your apps to use it, but also for the UI design we want to use.
>>>>
>>>> Defining a list of these UI component is not simple, but we may take
>>>> Bootstrap as a starting point. There is in Bootstrap a large number of
>>>> control already, that should cover many UI possibilities.
>>>>
>>>> How to provide that UI component to all the places we need it may be less
>>>> obvious. For example, we need to create button from .vm, XWiki document,
>>>> XWiki and java Macros, and even from javascript. Also defining how you
>>>> could expect to interact with each control, from Javascript or from java on
>>>> the server needs clarification.
>>>>
>>>> I have not yet googled, but there may be existing experience regarding
>>>> these matters on other project. Not reinventing the wheel is always better.
>>>> Your ideas are welcome.
>>>>
>>>> IMO, we really need that if we want our Skin 4.x to be really more usable
>>>> for customization.
>>>>
>>>> WDYT ?
>>>>
>>>>
>>>> --
>>>> Denis Gervalle
>>>> SOFTEC sa - CEO
>>>> eGuilde sarl - CTO
>>>> _______________________________________________
>>>> devs mailing list
>>>> [hidden email]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Jean-Vincent Drean,
> XWiki.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Denis Gervalle-2
On Fri, Feb 1, 2013 at 11:52 AM, Paul Libbrecht <[hidden email]> wrote:

> Correct Jean-Vincent, and I was probably too harsh describing it,
>
> but I understood Ecaterina's point to be a strive for a radical request to
> move away from html.
> Maybe this can be described in several stages?
>

What we are discussing is mainly to get away from producing the same html
in several places of our standard UI, so we can change it easily for
creating different kind of skins. Currently, to produce a button in the
XWiki UI, we always use the same html, but we produce that same HTML from
different places in the source code, and it is therefore not easy to change
the way button are rendered (to conform with markup require by bootstrap
for example).

Usually, you do not really care about the HTML since you can use a custom
CSS to change its appearance. But here, we definitely want to the opposite,
adapting our HTML to support existing CSS like bootstrap, and benefit of
all the derived CSS based on it very easily.

In no way, this will change your ability to use HTML in XWiki, we will
propose additional way to produce UI elements that will
integrate seamlessly with the XWiki UI. For exampke, when you write an
extension, you may want your extension to look like the rest of the UI, and
not reinvent the button.


>
> paul
>
>
> On 1 févr. 2013, at 11:09, Jean-Vincent Drean wrote:
>
> > AFAIU the thread is not about breaking things, it's about using xwiki
> > syntax and macros (mostly for forms since the 2.0 syntax covers a lot
> > of the html markup) to benefit from a standardized styling. Existing
> > HTML would still be working, and it would be possible to write apps
> > with HTML, but you'd have to handle styling on your own.
> >
> > On Thu, Jan 31, 2013 at 10:20 PM, Paul Libbrecht <[hidden email]>
> wrote:
> >>
> >> Breaking the very broad toolset and knowledge of developers in HTML to
> create XWiki content and applications is, to me, suicidal.
> >> Who would be ready to replace most of its html by macros?
> >>
> >> Paul
> >>
> >>
> >> On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote:
> >>
> >>> Hi Denis,
> >>>
> >>> When we discussed the Vertical Forms Standard [1] Thomas mentioned
> >>> something about "commons tools to follow that standard (like form
> related
> >>> wiki macros for example)". Some considered that having macros for
> standard
> >>> HTML controls will just duplicate HTML language.
> >>>
> >>> One advantage of having such macros would be that for example (let's
> say
> >>> the macros will be defined in macros.vm) if you want to change the
> classes
> >>> used by the controls (like .buttonwrapper class for example), you are
> just
> >>> changing the macros, not all the places that call them.
> >>>
> >>> This way you could easily change what classes you assign to a button
> for
> >>> example from span.buttonwrapper input.button.secondary to
> >>> button.btn.btn-primary (bootstrap way - of course we will also need to
> >>> standardize the usage component: input, button, a, etc.)
> >>>
> >>> The example above refers mostly to standard HTML elements. Of course
> if you
> >>> want to use other types of components from different frameworks you
> will
> >>> need to rewrite the templates, and this always calls for a new skin.
> >>>
> >>> I thought about new skins for XWiki and since I joined the project we
> >>> mostly deprecated old skins than creating new ones. But one problem I
> have
> >>> is the concept of base skin. For me the base skin should be something
> very
> >>> minimal.
> >>> It should contain just the typography, standard controls, the grid, the
> >>> reset, anyway elements that are not layout dependent and that will
> work for
> >>> any skin. I'm not sure about templates, because mostly templates refer
> to
> >>> layout and how you arrange things and what functionality you reveal and
> >>> where, and this usually change with a new skin. Technical the base skin
> >>> should contain the Standard, the base for things that will remain the
> same
> >>> no matter what. Right now Colibri covers much more than that.
> >>>
> >>> And this standard is absolutely necessary also for the way we go with
> >>> extensions. We know very well that in an Open Source project, everybody
> >>> codes with his own style and having a common ground is essential from a
> >>> consistency point of view. All the applications that will be created
> and
> >>> published by the community members should have a common style that
> could
> >>> make them integrate well inside XWiki, no matter of the creator.
> >>>
> >>> So the conclusion is that for this we will need a very well documented
> >>> standard and the tools to enforce it. Not sure what this means.
> >>>
> >>> Also other things worth discussing is colorthemes variables and macros
> >>> against LESS variables and mixins.
> >>> Also the Bootstrap / LESS is also a direction bet, just like Prototype
> vs.
> >>> JQuery, and the solution we pick it would be great if it would be
> loosely
> >>> coupled.
> >>>
> >>> Thanks,
> >>> Caty
> >>>
> >>> P.S. Another discussion somehow related to extensibility is
> [Discussion]
> >>> Problematic ColorTheme extensibility
> >>> http://markmail.org/thread/ex6fgou6fl6vjwfr
> >>>
> >>> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms
> >>>
> >>>
> >>> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]> wrote:
> >>>
> >>>> Hi Devs,
> >>>>
> >>>> As you may have noted from a previous mail, I have given a try to skin
> >>>> XWiki differently, based on Bootstrap. There is certainly many ways
> to get
> >>>> it done, but IMO, building over any pre-made css solution requires an
> >>>> adaptation of the HTML generated.
> >>>>
> >>>> In the early days of XWiki, the were few places were we have HTML
> >>>> generated. Most of the html produce came from three major places:
> >>>> 1) .vm templates including macros.vm
> >>>> 2) java generated (#display())
> >>>> 3) XWiki tech document
> >>>>
> >>>> While 2) and 3) either provide very basic markup or customizable one
> and
> >>>> are not so much, and 1) was fully customizable by skins, to work out
> a new
> >>>> skin was not too complex.
> >>>>
> >>>> Today however, the UI of XWiki has considerably increase its
> complexity,
> >>>> and the source of HTML has followed, added to the above 3:
> >>>> 4) XWiki and Java macros
> >>>> 5) JavaScript (ie: annotation UI, comments preview)
> >>>>
> >>>> Changing all these places has become really more painful. There is no
> >>>> central place, and a lot of hidden dependencies between UI components
> >>>> exists. Worse examples are those written in JS, that hook into the UI.
> >>>>
> >>>> I should admit that I have not a clear idea of the best way to improve
> >>>> that, but my feeling is that changing so much places simply to adapt
> our
> >>>> wiki skin to the "a la mode" skin solution (something that will happen
> >>>> again) is not nice.
> >>>>
> >>>> So this thread is now open for anyone to discuss the situation and for
> >>>> anyone interested to provide its input to the discussion.
> >>>>
> >>>> Looking at what I face building the UI with bootstrap, here is what I
> >>>> noticed:
> >>>>
> >>>> 1) Bootstrap customize standard tags, without any css class associated
> >>>> 2) Bootstrap provide standard css classes to skin a given kind of UI
> >>>> component
> >>>> 3) Bootstrap use these class and custom attribute to inject JS
> >>>> interactivity
> >>>>
> >>>> All these are really clean methods and work really well at building
> very
> >>>> simple html construct while providing nice looking and easy interface.
> >>>>
> >>>> Let's take a concrete example, to build a button, you may use either
> an a
> >>>> tag, an input tag, a button tag or whatever, and set it a 'btn' css
> class.
> >>>> You may complement it with additional 'btn-primary', 'btn-success',
> ... css
> >>>> classes, to choose the kind of button you really want.
> >>>>
> >>>> However, in our XWiki UI, there no single place where we construct
> buttons,
> >>>> we do so in some velocity macros of macros.vm, we do so in .vm of the
> UI,
> >>>> we also do so in javascript, and finally in some wiki documents,
> maybe we
> >>>> also generate some in a java component.
> >>>> All those buttons are usually built the same, with a very similar
> HTML, but
> >>>> there is no central place where the button markup is produced.
> >>>>
> >>>> And the same is true for most UI component. You may say we don't
> care, and
> >>>> CSS could solve them all, making any kind of markup look the way we
> want.
> >>>> But, we will loose the benefit of using existing CSS solution. And
> there
> >>>> are interesting benefit to that, since those solution gets
> customized, see
> >>>> BootsWatch for example.
> >>>>
> >>>> Therefore, it seems to me that we need something like an UI
> generator, so
> >>>> that when you build a application, you would simply says, I want a
> primary
> >>>> button here, a secondary button there, and it gets created both the
> way it
> >>>> should for your apps to use it, but also for the UI design we want to
> use.
> >>>>
> >>>> Defining a list of these UI component is not simple, but we may take
> >>>> Bootstrap as a starting point. There is in Bootstrap a large number of
> >>>> control already, that should cover many UI possibilities.
> >>>>
> >>>> How to provide that UI component to all the places we need it may be
> less
> >>>> obvious. For example, we need to create button from .vm, XWiki
> document,
> >>>> XWiki and java Macros, and even from javascript. Also defining how you
> >>>> could expect to interact with each control, from Javascript or from
> java on
> >>>> the server needs clarification.
> >>>>
> >>>> I have not yet googled, but there may be existing experience regarding
> >>>> these matters on other project. Not reinventing the wheel is always
> better.
> >>>> Your ideas are welcome.
> >>>>
> >>>> IMO, we really need that if we want our Skin 4.x to be really more
> usable
> >>>> for customization.
> >>>>
> >>>> WDYT ?
> >>>>
> >>>>
> >>>> --
> >>>> Denis Gervalle
> >>>> SOFTEC sa - CEO
> >>>> eGuilde sarl - CTO
> >>>> _______________________________________________
> >>>> devs mailing list
> >>>> [hidden email]
> >>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>
> >>> _______________________________________________
> >>> devs mailing list
> >>> [hidden email]
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Jean-Vincent Drean,
> > XWiki.
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Denis Gervalle-2
Hi Devs,

I have setup a public demonstration of my Bluebird Experimental Skin in the
incubator:

http://incubator.myxwiki.org/xwiki/bin/view/BluebirdSkin/WebHome

This demo is aimed to support the purpose of this brainstorming. I hope it
will inspire you to comment further on this thread.

For those who will undoubtedly ask, no this skin is not yet published. I
doubt I will publish it since it is unfinished with some rough edges and
missing features, but you may try to convince me of the opposite ;)


On Fri, Feb 1, 2013 at 12:43 PM, Denis Gervalle <[hidden email]> wrote:

>
>
>
> On Fri, Feb 1, 2013 at 11:52 AM, Paul Libbrecht <[hidden email]> wrote:
>
>> Correct Jean-Vincent, and I was probably too harsh describing it,
>>
>> but I understood Ecaterina's point to be a strive for a radical request
>> to move away from html.
>> Maybe this can be described in several stages?
>>
>
> What we are discussing is mainly to get away from producing the same html
> in several places of our standard UI, so we can change it easily for
> creating different kind of skins. Currently, to produce a button in the
> XWiki UI, we always use the same html, but we produce that same HTML from
> different places in the source code, and it is therefore not easy to change
> the way button are rendered (to conform with markup require by bootstrap
> for example).
>
> Usually, you do not really care about the HTML since you can use a custom
> CSS to change its appearance. But here, we definitely want to the opposite,
> adapting our HTML to support existing CSS like bootstrap, and benefit of
> all the derived CSS based on it very easily.
>
> In no way, this will change your ability to use HTML in XWiki, we will
> propose additional way to produce UI elements that will
> integrate seamlessly with the XWiki UI. For exampke, when you write an
> extension, you may want your extension to look like the rest of the UI, and
> not reinvent the button.
>
>
>>
>> paul
>>
>>
>> On 1 févr. 2013, at 11:09, Jean-Vincent Drean wrote:
>>
>> > AFAIU the thread is not about breaking things, it's about using xwiki
>> > syntax and macros (mostly for forms since the 2.0 syntax covers a lot
>> > of the html markup) to benefit from a standardized styling. Existing
>> > HTML would still be working, and it would be possible to write apps
>> > with HTML, but you'd have to handle styling on your own.
>> >
>> > On Thu, Jan 31, 2013 at 10:20 PM, Paul Libbrecht <[hidden email]>
>> wrote:
>> >>
>> >> Breaking the very broad toolset and knowledge of developers in HTML to
>> create XWiki content and applications is, to me, suicidal.
>> >> Who would be ready to replace most of its html by macros?
>> >>
>> >> Paul
>> >>
>> >>
>> >> On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote:
>> >>
>> >>> Hi Denis,
>> >>>
>> >>> When we discussed the Vertical Forms Standard [1] Thomas mentioned
>> >>> something about "commons tools to follow that standard (like form
>> related
>> >>> wiki macros for example)". Some considered that having macros for
>> standard
>> >>> HTML controls will just duplicate HTML language.
>> >>>
>> >>> One advantage of having such macros would be that for example (let's
>> say
>> >>> the macros will be defined in macros.vm) if you want to change the
>> classes
>> >>> used by the controls (like .buttonwrapper class for example), you are
>> just
>> >>> changing the macros, not all the places that call them.
>> >>>
>> >>> This way you could easily change what classes you assign to a button
>> for
>> >>> example from span.buttonwrapper input.button.secondary to
>> >>> button.btn.btn-primary (bootstrap way - of course we will also need to
>> >>> standardize the usage component: input, button, a, etc.)
>> >>>
>> >>> The example above refers mostly to standard HTML elements. Of course
>> if you
>> >>> want to use other types of components from different frameworks you
>> will
>> >>> need to rewrite the templates, and this always calls for a new skin.
>> >>>
>> >>> I thought about new skins for XWiki and since I joined the project we
>> >>> mostly deprecated old skins than creating new ones. But one problem I
>> have
>> >>> is the concept of base skin. For me the base skin should be something
>> very
>> >>> minimal.
>> >>> It should contain just the typography, standard controls, the grid,
>> the
>> >>> reset, anyway elements that are not layout dependent and that will
>> work for
>> >>> any skin. I'm not sure about templates, because mostly templates
>> refer to
>> >>> layout and how you arrange things and what functionality you reveal
>> and
>> >>> where, and this usually change with a new skin. Technical the base
>> skin
>> >>> should contain the Standard, the base for things that will remain the
>> same
>> >>> no matter what. Right now Colibri covers much more than that.
>> >>>
>> >>> And this standard is absolutely necessary also for the way we go with
>> >>> extensions. We know very well that in an Open Source project,
>> everybody
>> >>> codes with his own style and having a common ground is essential from
>> a
>> >>> consistency point of view. All the applications that will be created
>> and
>> >>> published by the community members should have a common style that
>> could
>> >>> make them integrate well inside XWiki, no matter of the creator.
>> >>>
>> >>> So the conclusion is that for this we will need a very well documented
>> >>> standard and the tools to enforce it. Not sure what this means.
>> >>>
>> >>> Also other things worth discussing is colorthemes variables and macros
>> >>> against LESS variables and mixins.
>> >>> Also the Bootstrap / LESS is also a direction bet, just like
>> Prototype vs.
>> >>> JQuery, and the solution we pick it would be great if it would be
>> loosely
>> >>> coupled.
>> >>>
>> >>> Thanks,
>> >>> Caty
>> >>>
>> >>> P.S. Another discussion somehow related to extensibility is
>> [Discussion]
>> >>> Problematic ColorTheme extensibility
>> >>> http://markmail.org/thread/ex6fgou6fl6vjwfr
>> >>>
>> >>> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms
>> >>>
>> >>>
>> >>> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]>
>> wrote:
>> >>>
>> >>>> Hi Devs,
>> >>>>
>> >>>> As you may have noted from a previous mail, I have given a try to
>> skin
>> >>>> XWiki differently, based on Bootstrap. There is certainly many ways
>> to get
>> >>>> it done, but IMO, building over any pre-made css solution requires an
>> >>>> adaptation of the HTML generated.
>> >>>>
>> >>>> In the early days of XWiki, the were few places were we have HTML
>> >>>> generated. Most of the html produce came from three major places:
>> >>>> 1) .vm templates including macros.vm
>> >>>> 2) java generated (#display())
>> >>>> 3) XWiki tech document
>> >>>>
>> >>>> While 2) and 3) either provide very basic markup or customizable one
>> and
>> >>>> are not so much, and 1) was fully customizable by skins, to work out
>> a new
>> >>>> skin was not too complex.
>> >>>>
>> >>>> Today however, the UI of XWiki has considerably increase its
>> complexity,
>> >>>> and the source of HTML has followed, added to the above 3:
>> >>>> 4) XWiki and Java macros
>> >>>> 5) JavaScript (ie: annotation UI, comments preview)
>> >>>>
>> >>>> Changing all these places has become really more painful. There is no
>> >>>> central place, and a lot of hidden dependencies between UI components
>> >>>> exists. Worse examples are those written in JS, that hook into the
>> UI.
>> >>>>
>> >>>> I should admit that I have not a clear idea of the best way to
>> improve
>> >>>> that, but my feeling is that changing so much places simply to adapt
>> our
>> >>>> wiki skin to the "a la mode" skin solution (something that will
>> happen
>> >>>> again) is not nice.
>> >>>>
>> >>>> So this thread is now open for anyone to discuss the situation and
>> for
>> >>>> anyone interested to provide its input to the discussion.
>> >>>>
>> >>>> Looking at what I face building the UI with bootstrap, here is what I
>> >>>> noticed:
>> >>>>
>> >>>> 1) Bootstrap customize standard tags, without any css class
>> associated
>> >>>> 2) Bootstrap provide standard css classes to skin a given kind of UI
>> >>>> component
>> >>>> 3) Bootstrap use these class and custom attribute to inject JS
>> >>>> interactivity
>> >>>>
>> >>>> All these are really clean methods and work really well at building
>> very
>> >>>> simple html construct while providing nice looking and easy
>> interface.
>> >>>>
>> >>>> Let's take a concrete example, to build a button, you may use either
>> an a
>> >>>> tag, an input tag, a button tag or whatever, and set it a 'btn' css
>> class.
>> >>>> You may complement it with additional 'btn-primary', 'btn-success',
>> ... css
>> >>>> classes, to choose the kind of button you really want.
>> >>>>
>> >>>> However, in our XWiki UI, there no single place where we construct
>> buttons,
>> >>>> we do so in some velocity macros of macros.vm, we do so in .vm of
>> the UI,
>> >>>> we also do so in javascript, and finally in some wiki documents,
>> maybe we
>> >>>> also generate some in a java component.
>> >>>> All those buttons are usually built the same, with a very similar
>> HTML, but
>> >>>> there is no central place where the button markup is produced.
>> >>>>
>> >>>> And the same is true for most UI component. You may say we don't
>> care, and
>> >>>> CSS could solve them all, making any kind of markup look the way we
>> want.
>> >>>> But, we will loose the benefit of using existing CSS solution. And
>> there
>> >>>> are interesting benefit to that, since those solution gets
>> customized, see
>> >>>> BootsWatch for example.
>> >>>>
>> >>>> Therefore, it seems to me that we need something like an UI
>> generator, so
>> >>>> that when you build a application, you would simply says, I want a
>> primary
>> >>>> button here, a secondary button there, and it gets created both the
>> way it
>> >>>> should for your apps to use it, but also for the UI design we want
>> to use.
>> >>>>
>> >>>> Defining a list of these UI component is not simple, but we may take
>> >>>> Bootstrap as a starting point. There is in Bootstrap a large number
>> of
>> >>>> control already, that should cover many UI possibilities.
>> >>>>
>> >>>> How to provide that UI component to all the places we need it may be
>> less
>> >>>> obvious. For example, we need to create button from .vm, XWiki
>> document,
>> >>>> XWiki and java Macros, and even from javascript. Also defining how
>> you
>> >>>> could expect to interact with each control, from Javascript or from
>> java on
>> >>>> the server needs clarification.
>> >>>>
>> >>>> I have not yet googled, but there may be existing experience
>> regarding
>> >>>> these matters on other project. Not reinventing the wheel is always
>> better.
>> >>>> Your ideas are welcome.
>> >>>>
>> >>>> IMO, we really need that if we want our Skin 4.x to be really more
>> usable
>> >>>> for customization.
>> >>>>
>> >>>> WDYT ?
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Denis Gervalle
>> >>>> SOFTEC sa - CEO
>> >>>> eGuilde sarl - CTO
>> >>>> _______________________________________________
>> >>>> devs mailing list
>> >>>> [hidden email]
>> >>>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>> _______________________________________________
>> >>> devs mailing list
>> >>> [hidden email]
>> >>> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> >> _______________________________________________
>> >> devs mailing list
>> >> [hidden email]
>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> >
>> >
>> > --
>> > Jean-Vincent Drean,
>> > XWiki.
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

vmassol
Administrator
Hi Denis,

On Feb 6, 2013, at 9:11 PM, Denis Gervalle <[hidden email]> wrote:

> Hi Devs,
>
> I have setup a public demonstration of my Bluebird Experimental Skin in the
> incubator:
>
> http://incubator.myxwiki.org/xwiki/bin/view/BluebirdSkin/WebHome
>
> This demo is aimed to support the purpose of this brainstorming. I hope it
> will inspire you to comment further on this thread.
>
> For those who will undoubtedly ask, no this skin is not yet published. I
> doubt I will publish it since it is unfinished with some rough edges and
> missing features, but you may try to convince me of the opposite ;)

It's really very nice! I like it a lot: simple and nice.

The various themes are very cool too.

It would really be a pity not to publish what you have so far, it doesn't have to be finished, you can publish the best you've done and others can continue it.

You could start by putting what you have in xwiki-contrib, wdyt?

Thanks
-Vincent

> On Fri, Feb 1, 2013 at 12:43 PM, Denis Gervalle <[hidden email]> wrote:
>
>>
>>
>>
>> On Fri, Feb 1, 2013 at 11:52 AM, Paul Libbrecht <[hidden email]> wrote:
>>
>>> Correct Jean-Vincent, and I was probably too harsh describing it,
>>>
>>> but I understood Ecaterina's point to be a strive for a radical request
>>> to move away from html.
>>> Maybe this can be described in several stages?
>>>
>>
>> What we are discussing is mainly to get away from producing the same html
>> in several places of our standard UI, so we can change it easily for
>> creating different kind of skins. Currently, to produce a button in the
>> XWiki UI, we always use the same html, but we produce that same HTML from
>> different places in the source code, and it is therefore not easy to change
>> the way button are rendered (to conform with markup require by bootstrap
>> for example).
>>
>> Usually, you do not really care about the HTML since you can use a custom
>> CSS to change its appearance. But here, we definitely want to the opposite,
>> adapting our HTML to support existing CSS like bootstrap, and benefit of
>> all the derived CSS based on it very easily.
>>
>> In no way, this will change your ability to use HTML in XWiki, we will
>> propose additional way to produce UI elements that will
>> integrate seamlessly with the XWiki UI. For exampke, when you write an
>> extension, you may want your extension to look like the rest of the UI, and
>> not reinvent the button.
>>
>>
>>>
>>> paul
>>>
>>>
>>> On 1 févr. 2013, at 11:09, Jean-Vincent Drean wrote:
>>>
>>>> AFAIU the thread is not about breaking things, it's about using xwiki
>>>> syntax and macros (mostly for forms since the 2.0 syntax covers a lot
>>>> of the html markup) to benefit from a standardized styling. Existing
>>>> HTML would still be working, and it would be possible to write apps
>>>> with HTML, but you'd have to handle styling on your own.
>>>>
>>>> On Thu, Jan 31, 2013 at 10:20 PM, Paul Libbrecht <[hidden email]>
>>> wrote:
>>>>>
>>>>> Breaking the very broad toolset and knowledge of developers in HTML to
>>> create XWiki content and applications is, to me, suicidal.
>>>>> Who would be ready to replace most of its html by macros?
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>> On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote:
>>>>>
>>>>>> Hi Denis,
>>>>>>
>>>>>> When we discussed the Vertical Forms Standard [1] Thomas mentioned
>>>>>> something about "commons tools to follow that standard (like form
>>> related
>>>>>> wiki macros for example)". Some considered that having macros for
>>> standard
>>>>>> HTML controls will just duplicate HTML language.
>>>>>>
>>>>>> One advantage of having such macros would be that for example (let's
>>> say
>>>>>> the macros will be defined in macros.vm) if you want to change the
>>> classes
>>>>>> used by the controls (like .buttonwrapper class for example), you are
>>> just
>>>>>> changing the macros, not all the places that call them.
>>>>>>
>>>>>> This way you could easily change what classes you assign to a button
>>> for
>>>>>> example from span.buttonwrapper input.button.secondary to
>>>>>> button.btn.btn-primary (bootstrap way - of course we will also need to
>>>>>> standardize the usage component: input, button, a, etc.)
>>>>>>
>>>>>> The example above refers mostly to standard HTML elements. Of course
>>> if you
>>>>>> want to use other types of components from different frameworks you
>>> will
>>>>>> need to rewrite the templates, and this always calls for a new skin.
>>>>>>
>>>>>> I thought about new skins for XWiki and since I joined the project we
>>>>>> mostly deprecated old skins than creating new ones. But one problem I
>>> have
>>>>>> is the concept of base skin. For me the base skin should be something
>>> very
>>>>>> minimal.
>>>>>> It should contain just the typography, standard controls, the grid,
>>> the
>>>>>> reset, anyway elements that are not layout dependent and that will
>>> work for
>>>>>> any skin. I'm not sure about templates, because mostly templates
>>> refer to
>>>>>> layout and how you arrange things and what functionality you reveal
>>> and
>>>>>> where, and this usually change with a new skin. Technical the base
>>> skin
>>>>>> should contain the Standard, the base for things that will remain the
>>> same
>>>>>> no matter what. Right now Colibri covers much more than that.
>>>>>>
>>>>>> And this standard is absolutely necessary also for the way we go with
>>>>>> extensions. We know very well that in an Open Source project,
>>> everybody
>>>>>> codes with his own style and having a common ground is essential from
>>> a
>>>>>> consistency point of view. All the applications that will be created
>>> and
>>>>>> published by the community members should have a common style that
>>> could
>>>>>> make them integrate well inside XWiki, no matter of the creator.
>>>>>>
>>>>>> So the conclusion is that for this we will need a very well documented
>>>>>> standard and the tools to enforce it. Not sure what this means.
>>>>>>
>>>>>> Also other things worth discussing is colorthemes variables and macros
>>>>>> against LESS variables and mixins.
>>>>>> Also the Bootstrap / LESS is also a direction bet, just like
>>> Prototype vs.
>>>>>> JQuery, and the solution we pick it would be great if it would be
>>> loosely
>>>>>> coupled.
>>>>>>
>>>>>> Thanks,
>>>>>> Caty
>>>>>>
>>>>>> P.S. Another discussion somehow related to extensibility is
>>> [Discussion]
>>>>>> Problematic ColorTheme extensibility
>>>>>> http://markmail.org/thread/ex6fgou6fl6vjwfr
>>>>>>
>>>>>> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]>
>>> wrote:
>>>>>>
>>>>>>> Hi Devs,
>>>>>>>
>>>>>>> As you may have noted from a previous mail, I have given a try to
>>> skin
>>>>>>> XWiki differently, based on Bootstrap. There is certainly many ways
>>> to get
>>>>>>> it done, but IMO, building over any pre-made css solution requires an
>>>>>>> adaptation of the HTML generated.
>>>>>>>
>>>>>>> In the early days of XWiki, the were few places were we have HTML
>>>>>>> generated. Most of the html produce came from three major places:
>>>>>>> 1) .vm templates including macros.vm
>>>>>>> 2) java generated (#display())
>>>>>>> 3) XWiki tech document
>>>>>>>
>>>>>>> While 2) and 3) either provide very basic markup or customizable one
>>> and
>>>>>>> are not so much, and 1) was fully customizable by skins, to work out
>>> a new
>>>>>>> skin was not too complex.
>>>>>>>
>>>>>>> Today however, the UI of XWiki has considerably increase its
>>> complexity,
>>>>>>> and the source of HTML has followed, added to the above 3:
>>>>>>> 4) XWiki and Java macros
>>>>>>> 5) JavaScript (ie: annotation UI, comments preview)
>>>>>>>
>>>>>>> Changing all these places has become really more painful. There is no
>>>>>>> central place, and a lot of hidden dependencies between UI components
>>>>>>> exists. Worse examples are those written in JS, that hook into the
>>> UI.
>>>>>>>
>>>>>>> I should admit that I have not a clear idea of the best way to
>>> improve
>>>>>>> that, but my feeling is that changing so much places simply to adapt
>>> our
>>>>>>> wiki skin to the "a la mode" skin solution (something that will
>>> happen
>>>>>>> again) is not nice.
>>>>>>>
>>>>>>> So this thread is now open for anyone to discuss the situation and
>>> for
>>>>>>> anyone interested to provide its input to the discussion.
>>>>>>>
>>>>>>> Looking at what I face building the UI with bootstrap, here is what I
>>>>>>> noticed:
>>>>>>>
>>>>>>> 1) Bootstrap customize standard tags, without any css class
>>> associated
>>>>>>> 2) Bootstrap provide standard css classes to skin a given kind of UI
>>>>>>> component
>>>>>>> 3) Bootstrap use these class and custom attribute to inject JS
>>>>>>> interactivity
>>>>>>>
>>>>>>> All these are really clean methods and work really well at building
>>> very
>>>>>>> simple html construct while providing nice looking and easy
>>> interface.
>>>>>>>
>>>>>>> Let's take a concrete example, to build a button, you may use either
>>> an a
>>>>>>> tag, an input tag, a button tag or whatever, and set it a 'btn' css
>>> class.
>>>>>>> You may complement it with additional 'btn-primary', 'btn-success',
>>> ... css
>>>>>>> classes, to choose the kind of button you really want.
>>>>>>>
>>>>>>> However, in our XWiki UI, there no single place where we construct
>>> buttons,
>>>>>>> we do so in some velocity macros of macros.vm, we do so in .vm of
>>> the UI,
>>>>>>> we also do so in javascript, and finally in some wiki documents,
>>> maybe we
>>>>>>> also generate some in a java component.
>>>>>>> All those buttons are usually built the same, with a very similar
>>> HTML, but
>>>>>>> there is no central place where the button markup is produced.
>>>>>>>
>>>>>>> And the same is true for most UI component. You may say we don't
>>> care, and
>>>>>>> CSS could solve them all, making any kind of markup look the way we
>>> want.
>>>>>>> But, we will loose the benefit of using existing CSS solution. And
>>> there
>>>>>>> are interesting benefit to that, since those solution gets
>>> customized, see
>>>>>>> BootsWatch for example.
>>>>>>>
>>>>>>> Therefore, it seems to me that we need something like an UI
>>> generator, so
>>>>>>> that when you build a application, you would simply says, I want a
>>> primary
>>>>>>> button here, a secondary button there, and it gets created both the
>>> way it
>>>>>>> should for your apps to use it, but also for the UI design we want
>>> to use.
>>>>>>>
>>>>>>> Defining a list of these UI component is not simple, but we may take
>>>>>>> Bootstrap as a starting point. There is in Bootstrap a large number
>>> of
>>>>>>> control already, that should cover many UI possibilities.
>>>>>>>
>>>>>>> How to provide that UI component to all the places we need it may be
>>> less
>>>>>>> obvious. For example, we need to create button from .vm, XWiki
>>> document,
>>>>>>> XWiki and java Macros, and even from javascript. Also defining how
>>> you
>>>>>>> could expect to interact with each control, from Javascript or from
>>> java on
>>>>>>> the server needs clarification.
>>>>>>>
>>>>>>> I have not yet googled, but there may be existing experience
>>> regarding
>>>>>>> these matters on other project. Not reinventing the wheel is always
>>> better.
>>>>>>> Your ideas are welcome.
>>>>>>>
>>>>>>> IMO, we really need that if we want our Skin 4.x to be really more
>>> usable
>>>>>>> for customization.
>>>>>>>
>>>>>>> WDYT ?
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

Jérôme Velociter
In reply to this post by Denis Gervalle-2
Hi,

I acknowledge the need for adapting HTML output to different needs. One
other thing it could be particularly useful for is for having alternate
HTML for touch devices.

The only problem I see with this approach is that by creating a DSL for
the UI we are moving the HTML farther from the user (developer), thus
cutting us away from users that don't have a strong technical background
but can work with HTML. This is Paul's concern as well if I understand
correctly.

Regarding implementation will we need to figure out a way that makes the
"components" easy to use on the front-end and from the back-end
altogether. We've mentionned the possibility of using rhino for that in
a conversation with Denis offline.

Jerome

Le 29/01/13 19:10, Denis Gervalle a écrit :

> Hi Devs,
>
> As you may have noted from a previous mail, I have given a try to skin
> XWiki differently, based on Bootstrap. There is certainly many ways to get
> it done, but IMO, building over any pre-made css solution requires an
> adaptation of the HTML generated.
>
> In the early days of XWiki, the were few places were we have HTML
> generated. Most of the html produce came from three major places:
> 1) .vm templates including macros.vm
> 2) java generated (#display())
> 3) XWiki tech document
>
> While 2) and 3) either provide very basic markup or customizable one and
> are not so much, and 1) was fully customizable by skins, to work out a new
> skin was not too complex.
>
> Today however, the UI of XWiki has considerably increase its complexity,
> and the source of HTML has followed, added to the above 3:
>   4) XWiki and Java macros
>   5) JavaScript (ie: annotation UI, comments preview)
>
> Changing all these places has become really more painful. There is no
> central place, and a lot of hidden dependencies between UI components
> exists. Worse examples are those written in JS, that hook into the UI.
>
> I should admit that I have not a clear idea of the best way to improve
> that, but my feeling is that changing so much places simply to adapt our
> wiki skin to the "a la mode" skin solution (something that will happen
> again) is not nice.
>
> So this thread is now open for anyone to discuss the situation and for
> anyone interested to provide its input to the discussion.
>
> Looking at what I face building the UI with bootstrap, here is what I
> noticed:
>
> 1) Bootstrap customize standard tags, without any css class associated
> 2) Bootstrap provide standard css classes to skin a given kind of UI
> component
> 3) Bootstrap use these class and custom attribute to inject JS interactivity
>
> All these are really clean methods and work really well at building very
> simple html construct while providing nice looking and easy interface.
>
> Let's take a concrete example, to build a button, you may use either an a
> tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
> You may complement it with additional 'btn-primary', 'btn-success', ... css
> classes, to choose the kind of button you really want.
>
> However, in our XWiki UI, there no single place where we construct buttons,
> we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
> we also do so in javascript, and finally in some wiki documents, maybe we
> also generate some in a java component.
> All those buttons are usually built the same, with a very similar HTML, but
> there is no central place where the button markup is produced.
>
> And the same is true for most UI component. You may say we don't care, and
> CSS could solve them all, making any kind of markup look the way we want.
> But, we will loose the benefit of using existing CSS solution. And there
> are interesting benefit to that, since those solution gets customized, see
> BootsWatch for example.
>
> Therefore, it seems to me that we need something like an UI generator, so
> that when you build a application, you would simply says, I want a primary
> button here, a secondary button there, and it gets created both the way it
> should for your apps to use it, but also for the UI design we want to use.
>
> Defining a list of these UI component is not simple, but we may take
> Bootstrap as a starting point. There is in Bootstrap a large number of
> control already, that should cover many UI possibilities.
>
> How to provide that UI component to all the places we need it may be less
> obvious. For example, we need to create button from .vm, XWiki document,
> XWiki and java Macros, and even from javascript. Also defining how you
> could expect to interact with each control, from Javascript or from java on
> the server needs clarification.
>
> I have not yet googled, but there may be existing experience regarding
> these matters on other project. Not reinventing the wheel is always better.
> Your ideas are welcome.
>
> IMO, we really need that if we want our Skin 4.x to be really more usable
> for customization.
>
> WDYT ?
>
>

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

vmassol
Administrator
In reply to this post by Denis Gervalle-2
Hi Denis,

On Jan 29, 2013, at 7:10 PM, Denis Gervalle <[hidden email]> wrote:

> Hi Devs,
>
> As you may have noted from a previous mail, I have given a try to skin
> XWiki differently, based on Bootstrap. There is certainly many ways to get
> it done, but IMO, building over any pre-made css solution requires an
> adaptation of the HTML generated.
>
> In the early days of XWiki, the were few places were we have HTML
> generated. Most of the html produce came from three major places:
> 1) .vm templates including macros.vm
> 2) java generated (#display())
> 3) XWiki tech document
>
> While 2) and 3) either provide very basic markup or customizable one and
> are not so much, and 1) was fully customizable by skins, to work out a new
> skin was not too complex.
>
> Today however, the UI of XWiki has considerably increase its complexity,
> and the source of HTML has followed, added to the above 3:
> 4) XWiki and Java macros
> 5) JavaScript (ie: annotation UI, comments preview)
>
> Changing all these places has become really more painful. There is no
> central place, and a lot of hidden dependencies between UI components
> exists. Worse examples are those written in JS, that hook into the UI.
>
> I should admit that I have not a clear idea of the best way to improve
> that, but my feeling is that changing so much places simply to adapt our
> wiki skin to the "a la mode" skin solution (something that will happen
> again) is not nice.
>
> So this thread is now open for anyone to discuss the situation and for
> anyone interested to provide its input to the discussion.
>
> Looking at what I face building the UI with bootstrap, here is what I
> noticed:
>
> 1) Bootstrap customize standard tags, without any css class associated
> 2) Bootstrap provide standard css classes to skin a given kind of UI
> component
> 3) Bootstrap use these class and custom attribute to inject JS interactivity
>
> All these are really clean methods and work really well at building very
> simple html construct while providing nice looking and easy interface.
>
> Let's take a concrete example, to build a button, you may use either an a
> tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
> You may complement it with additional 'btn-primary', 'btn-success', ... css
> classes, to choose the kind of button you really want.
>
> However, in our XWiki UI, there no single place where we construct buttons,
> we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
> we also do so in javascript, and finally in some wiki documents, maybe we
> also generate some in a java component.
> All those buttons are usually built the same, with a very similar HTML, but
> there is no central place where the button markup is produced.
>
> And the same is true for most UI component. You may say we don't care, and
> CSS could solve them all, making any kind of markup look the way we want.
> But, we will loose the benefit of using existing CSS solution. And there
> are interesting benefit to that, since those solution gets customized, see
> BootsWatch for example.
>
> Therefore, it seems to me that we need something like an UI generator, so
> that when you build a application, you would simply says, I want a primary
> button here, a secondary button there, and it gets created both the way it
> should for your apps to use it, but also for the UI design we want to use.
>
> Defining a list of these UI component is not simple, but we may take
> Bootstrap as a starting point. There is in Bootstrap a large number of
> control already, that should cover many UI possibilities.
>
> How to provide that UI component to all the places we need it may be less
> obvious. For example, we need to create button from .vm, XWiki document,
> XWiki and java Macros, and even from javascript. Also defining how you
> could expect to interact with each control, from Javascript or from java on
> the server needs clarification.
>
> I have not yet googled, but there may be existing experience regarding
> these matters on other project. Not reinventing the wheel is always better.
> Your ideas are welcome.
>
> IMO, we really need that if we want our Skin 4.x to be really more usable
> for customization.
>
> WDYT ?

I agree with the need but I don't agree that we need a UI Generator. IMO we should use HTML as our primary language for expressing the UI and standardize on some CSS classes (we could use the bootstrap ones).

So from wherever we generate HTML the generated HTML must only use the standardized CSS classes. We can document that and we can document what HTML should be used to create a button, etc.

It's IMO not possible to have a UI Generator that will work for all technologies: vm, java, javascript, etc. Using standardized HTML seems much simpler and more versatile to me.

So big +1 to better standardize our HTML and the CSS classes we're allowed to use.

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

vmassol
Administrator
In reply to this post by Ecaterina Moraru (Valica)
IMO it's ok to have some "common reusable front end components" but they should just be helpers and the standard should be HTML and the agreed CSS classes we wish to use.

One reason is that we won't have those components for all technologies.

Thanks
-Vincent

On Jan 31, 2013, at 3:26 PM, Ecaterina Moraru (Valica) <[hidden email]> wrote:

> Hi Denis,
>
> When we discussed the Vertical Forms Standard [1] Thomas mentioned
> something about "commons tools to follow that standard (like form related
> wiki macros for example)". Some considered that having macros for standard
> HTML controls will just duplicate HTML language.
>
> One advantage of having such macros would be that for example (let's say
> the macros will be defined in macros.vm) if you want to change the classes
> used by the controls (like .buttonwrapper class for example), you are just
> changing the macros, not all the places that call them.
>
> This way you could easily change what classes you assign to a button for
> example from span.buttonwrapper input.button.secondary to
> button.btn.btn-primary (bootstrap way - of course we will also need to
> standardize the usage component: input, button, a, etc.)
>
> The example above refers mostly to standard HTML elements. Of course if you
> want to use other types of components from different frameworks you will
> need to rewrite the templates, and this always calls for a new skin.
>
> I thought about new skins for XWiki and since I joined the project we
> mostly deprecated old skins than creating new ones. But one problem I have
> is the concept of base skin. For me the base skin should be something very
> minimal.
> It should contain just the typography, standard controls, the grid, the
> reset, anyway elements that are not layout dependent and that will work for
> any skin. I'm not sure about templates, because mostly templates refer to
> layout and how you arrange things and what functionality you reveal and
> where, and this usually change with a new skin. Technical the base skin
> should contain the Standard, the base for things that will remain the same
> no matter what. Right now Colibri covers much more than that.
>
> And this standard is absolutely necessary also for the way we go with
> extensions. We know very well that in an Open Source project, everybody
> codes with his own style and having a common ground is essential from a
> consistency point of view. All the applications that will be created and
> published by the community members should have a common style that could
> make them integrate well inside XWiki, no matter of the creator.
>
> So the conclusion is that for this we will need a very well documented
> standard and the tools to enforce it. Not sure what this means.
>
> Also other things worth discussing is colorthemes variables and macros
> against LESS variables and mixins.
> Also the Bootstrap / LESS is also a direction bet, just like Prototype vs.
> JQuery, and the solution we pick it would be great if it would be loosely
> coupled.
>
> Thanks,
> Caty
>
> P.S. Another discussion somehow related to extensibility is [Discussion]
> Problematic ColorTheme extensibility
> http://markmail.org/thread/ex6fgou6fl6vjwfr
>
> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms
>
>
> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[hidden email]> wrote:
>
>> Hi Devs,
>>
>> As you may have noted from a previous mail, I have given a try to skin
>> XWiki differently, based on Bootstrap. There is certainly many ways to get
>> it done, but IMO, building over any pre-made css solution requires an
>> adaptation of the HTML generated.
>>
>> In the early days of XWiki, the were few places were we have HTML
>> generated. Most of the html produce came from three major places:
>> 1) .vm templates including macros.vm
>> 2) java generated (#display())
>> 3) XWiki tech document
>>
>> While 2) and 3) either provide very basic markup or customizable one and
>> are not so much, and 1) was fully customizable by skins, to work out a new
>> skin was not too complex.
>>
>> Today however, the UI of XWiki has considerably increase its complexity,
>> and the source of HTML has followed, added to the above 3:
>> 4) XWiki and Java macros
>> 5) JavaScript (ie: annotation UI, comments preview)
>>
>> Changing all these places has become really more painful. There is no
>> central place, and a lot of hidden dependencies between UI components
>> exists. Worse examples are those written in JS, that hook into the UI.
>>
>> I should admit that I have not a clear idea of the best way to improve
>> that, but my feeling is that changing so much places simply to adapt our
>> wiki skin to the "a la mode" skin solution (something that will happen
>> again) is not nice.
>>
>> So this thread is now open for anyone to discuss the situation and for
>> anyone interested to provide its input to the discussion.
>>
>> Looking at what I face building the UI with bootstrap, here is what I
>> noticed:
>>
>> 1) Bootstrap customize standard tags, without any css class associated
>> 2) Bootstrap provide standard css classes to skin a given kind of UI
>> component
>> 3) Bootstrap use these class and custom attribute to inject JS
>> interactivity
>>
>> All these are really clean methods and work really well at building very
>> simple html construct while providing nice looking and easy interface.
>>
>> Let's take a concrete example, to build a button, you may use either an a
>> tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
>> You may complement it with additional 'btn-primary', 'btn-success', ... css
>> classes, to choose the kind of button you really want.
>>
>> However, in our XWiki UI, there no single place where we construct buttons,
>> we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
>> we also do so in javascript, and finally in some wiki documents, maybe we
>> also generate some in a java component.
>> All those buttons are usually built the same, with a very similar HTML, but
>> there is no central place where the button markup is produced.
>>
>> And the same is true for most UI component. You may say we don't care, and
>> CSS could solve them all, making any kind of markup look the way we want.
>> But, we will loose the benefit of using existing CSS solution. And there
>> are interesting benefit to that, since those solution gets customized, see
>> BootsWatch for example.
>>
>> Therefore, it seems to me that we need something like an UI generator, so
>> that when you build a application, you would simply says, I want a primary
>> button here, a secondary button there, and it gets created both the way it
>> should for your apps to use it, but also for the UI design we want to use.
>>
>> Defining a list of these UI component is not simple, but we may take
>> Bootstrap as a starting point. There is in Bootstrap a large number of
>> control already, that should cover many UI possibilities.
>>
>> How to provide that UI component to all the places we need it may be less
>> obvious. For example, we need to create button from .vm, XWiki document,
>> XWiki and java Macros, and even from javascript. Also defining how you
>> could expect to interact with each control, from Javascript or from java on
>> the server needs clarification.
>>
>> I have not yet googled, but there may be existing experience regarding
>> these matters on other project. Not reinventing the wheel is always better.
>> Your ideas are welcome.
>>
>> IMO, we really need that if we want our Skin 4.x to be really more usable
>> for customization.
>>
>> WDYT ?
>>
>>
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> eGuilde sarl - CTO
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs