Hi Cathy, To integrate bootstrap with XWiki, several approaches has been investigated: A. Jerome, with the Lyrebird skin, has adapted the bootstrap CSS to the current XWiki markup and templates B. Myself, with the Bluebird skin, has adapted the XWiki templates to the bootstrap CSS to partially target the Flamingo skin look. C. You, Cathy, with the Junco skin, has bridge the bootstrap CSS to adapt it to the XWiki markup and templates The inconvenience with A. was the inability to use any of the existing bootstrap variations available, and to follow the bootstrap evolution easily. So, A is no go for me. The inconvenience with B. is that it require the whole XWiki markup to be adapted, including those produced by existing extensions, providing no compatibility with the past. The inconvenience with C. is that it require any bootstrap variation to be "recompiled" (using less) to be adapted. My personal idea, that I have defended during the last seminar, is that we should target a state where we are free to change the HTML markup without breaking existing extensions, and the way I propose to do so was to provide more abstraction then we have currently, by providing XWiki macro to generate most of the HTML needed. From the discussion we had, I have understand that reaching that point will be not easy, and could be an unreachable dream, but I am still convinced it could be achieved for a lot of simple applications, so most of them. What I would find a very annoying situation, is that we refrain to change our skin, and our html markup, simply to keep the compatibility with the past. The currently generated markup is sometime over complex, and followed our own rules. I see the bootstrap integration as the occasion to choose a more popular html markup style, that is already widely used on the net, and that could be easily followed by newcomers. Bootstrap propose to use a very semantic html markup while providing a complete set of UI features. It is a far more clean and simple HTML than we have currently IMO. Also, using a purely bootstrap based solution, without any adaptation, open us to the wide range of bootstrap variation, either paid or free. Based on our previous experiences, I have the feeling that we have all what we need to get the best of both worlds, and migrate smoothly. We may use method C. (Junco) to provide a good compatibility level for existing extension and to be upgraded templates, while we could use method B. to evolve our skin and simplify our markup. And we may also improve at the same time, our feature that prevent us to manually generate the HTML. Regarding the JS aspect, Louis-Marie is perfectly right, we have to vote the deprecation of Prototype.js and the usage of JQuery as our default JS framework. I am confident we could reach a consensus on that point, and for those not yet convince, I remind you this post by Sam Stephenson the creator of Prototype.js initially mentionned by Jean-Vincent: http://sstephenson.us/posts/you-are-not-your-code So I invite you to open an independent thread for that vote. Thanks, On Wed, Feb 19, 2014 at 7:43 PM, Joshua Marks <[email protected]> wrote:

Curriki geometry is using bookstrap. http://www.currikigeometry.org/

-----Original Message----- From: devs [mailto:[email protected]] On Behalf Of Guillaume "Louis-Marie" Delhumeau Sent: Wednesday, February 19, 2014 6:37 AM To: XWiki Developers Subject: Re: [xwiki-devs] [Discussion][Skin] Bootstrap integration inside platform

Bootstrap is a good choice because: 1/ it is well-known 2/ it provides a nice grid-system (good for the responsiveness) 3/ it offer components that developers can re-use

But theses components uses jQuery, and no-choice have been made yet about the new javascript framework we should use.

Louis-Marie

2014-01-28 13:14 GMT+01:00 Ecaterina Moraru (Valica) <[email protected]>:

...

Hi,

As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki.

Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin

Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com).

This thread's purpose is to discuss possible problems we might face by integrating Bootstrap inside platform. You can find the investigation page at http://design.xwiki.org/xwiki/bin/view/Proposal/BootstrapIntegration

Besides the already mentioned problems I would want to know the community's opinion about this framework. Have you worked with it? Do you think we should consider some alternatives? See some other frameworks at http://usablica.github.io/front-end-frameworks/compare.html

Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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

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

-- Denis Gervalle SOFTEC sa - CEO

Hi all, On 02/22/2014 11:56 PM, Denis Gervalle wrote:

Hi Cathy,

To integrate bootstrap with XWiki, several approaches has been investigated:

A. Jerome, with the Lyrebird skin, has adapted the bootstrap CSS to the current XWiki markup and templates B. Myself, with the Bluebird skin, has adapted the XWiki templates to the bootstrap CSS to partially target the Flamingo skin look. C. You, Cathy, with the Junco skin, has bridge the bootstrap CSS to adapt it to the XWiki markup and templates

The inconvenience with A. was the inability to use any of the existing bootstrap variations available, and to follow the bootstrap evolution easily. So, A is no go for me.

I agree, it's definitely not convenient, not maintainable, and locks the whole thing in a mix of bootstrap and XWiki. Here's an idea though : maybe you can use this strategy for backward compatilibility, by generating a optional compatibility.css file that brings bootstrap CSS to former XWiki markup the same way I did in Lyrebird (I've been able to reuse some LESS mixins and inject them under XWiki CSS selectors for example). Jérôme

The inconvenience with B. is that it require the whole XWiki markup to be adapted, including those produced by existing extensions, providing no compatibility with the past. The inconvenience with C. is that it require any bootstrap variation to be "recompiled" (using less) to be adapted.

My personal idea, that I have defended during the last seminar, is that we should target a state where we are free to change the HTML markup without breaking existing extensions, and the way I propose to do so was to provide more abstraction then we have currently, by providing XWiki macro to generate most of the HTML needed. From the discussion we had, I have understand that reaching that point will be not easy, and could be an unreachable dream, but I am still convinced it could be achieved for a lot of simple applications, so most of them.

What I would find a very annoying situation, is that we refrain to change our skin, and our html markup, simply to keep the compatibility with the past. The currently generated markup is sometime over complex, and followed our own rules. I see the bootstrap integration as the occasion to choose a more popular html markup style, that is already widely used on the net, and that could be easily followed by newcomers. Bootstrap propose to use a very semantic html markup while providing a complete set of UI features. It is a far more clean and simple HTML than we have currently IMO. Also, using a purely bootstrap based solution, without any adaptation, open us to the wide range of bootstrap variation, either paid or free.

Based on our previous experiences, I have the feeling that we have all what we need to get the best of both worlds, and migrate smoothly. We may use method C. (Junco) to provide a good compatibility level for existing extension and to be upgraded templates, while we could use method B. to evolve our skin and simplify our markup. And we may also improve at the same time, our feature that prevent us to manually generate the HTML.

Regarding the JS aspect, Louis-Marie is perfectly right, we have to vote the deprecation of Prototype.js and the usage of JQuery as our default JS framework. I am confident we could reach a consensus on that point, and for those not yet convince, I remind you this post by Sam Stephenson the creator of Prototype.js initially mentionned by Jean-Vincent:

http://sstephenson.us/posts/you-are-not-your-code

So I invite you to open an independent thread for that vote.

Thanks,

On Wed, Feb 19, 2014 at 7:43 PM, Joshua Marks <[email protected]> wrote:

...

Curriki geometry is using bookstrap. http://www.currikigeometry.org/

-----Original Message----- From: devs [mailto:[email protected]] On Behalf Of Guillaume "Louis-Marie" Delhumeau Sent: Wednesday, February 19, 2014 6:37 AM To: XWiki Developers Subject: Re: [xwiki-devs] [Discussion][Skin] Bootstrap integration inside platform

Bootstrap is a good choice because: 1/ it is well-known 2/ it provides a nice grid-system (good for the responsiveness) 3/ it offer components that developers can re-use

But theses components uses jQuery, and no-choice have been made yet about the new javascript framework we should use.

Louis-Marie

2014-01-28 13:14 GMT+01:00 Ecaterina Moraru (Valica) <[email protected]>:

...

Hi,

As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki.

Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin

Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com).

This thread's purpose is to discuss possible problems we might face by integrating Bootstrap inside platform. You can find the investigation page at http://design.xwiki.org/xwiki/bin/view/Proposal/BootstrapIntegration

Besides the already mentioned problems I would want to know the community's opinion about this framework. Have you worked with it? Do you think we should consider some alternatives? See some other frameworks at http://usablica.github.io/front-end-frameworks/compare.html

Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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

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

-- Jérôme Velociter +33 786 993 355 @jvelo Open source e-commerce and marketplaces made simple www.mayocat.org 46cl www.46cl.fr

Hi, 2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau < [email protected]>:

Hi Guys.

I am starting to do the implementation of Flamingo without integrating LESS into the platform. That is my objective for 6.0.

So I have started to override some templates (.vm files) in my flamingo directory, and make them use the default bootstrap classes like ".btn", ".navbar", etc... (method B).

But we have some UI elements that are not generated by our templates but by some JavaScript's (example: xwiki-platform-web : resources/js/xwiki/actionButton.js). They generate HTML code that match for the colibri skin but not for other skins.

Moreover, we have our own classes (like xform) that are used everywhere and I do not have the time to rewrite them all, which would also break the compatibility with Colibri.

This issue has been already explained by Denis: http://markmail.org/thread/shd55qxt7w56ypy3

So I have started to create a kind of "compatibility.css" file, using LESS, that do the mapping between our default classes (like "buttonwrapper") to the bootstrap classes. And it works well (method C).

That means that we need this kind of "mixed approach" with both the XWiki's classes and the bootstrap's. (method B+C)

Other thing: I use LESS compiler on my own machine to create the mapping CSS file. I am not able to execute the LESS compiler during the maven build because the mojo for less is out-of-date: https://github.com/marceloverdijk/lesscss-maven-plugin . So I just commit the compiled file in the repository. This is not very nice but I don't see what else I can do.

Maybe you could use antrun or exec mojo to run rhino/less directly, without the proper (outdated) mojo ? Did you try declaring dependency to less (in expected version) as a dependency of the less lesscss-maven-plugin (like, overloading default version), if APIs are the same maybe it could work ...

Thanks, Louis-Marie

2014-02-24 17:40 GMT+01:00 Jérôme Velociter <[email protected]>:

...

Hi all,

On 02/22/2014 11:56 PM, Denis Gervalle wrote:

...

Hi Cathy,

To integrate bootstrap with XWiki, several approaches has been investigated:

A. Jerome, with the Lyrebird skin, has adapted the bootstrap CSS to the current XWiki markup and templates B. Myself, with the Bluebird skin, has adapted the XWiki templates to the bootstrap CSS to partially target the Flamingo skin look. C. You, Cathy, with the Junco skin, has bridge the bootstrap CSS to adapt it to the XWiki markup and templates

The inconvenience with A. was the inability to use any of the existing bootstrap variations available, and to follow the bootstrap evolution easily. So, A is no go for me.

I agree, it's definitely not convenient, not maintainable, and locks the whole thing in a mix of bootstrap and XWiki.

Here's an idea though : maybe you can use this strategy for backward compatilibility, by generating a optional compatibility.css file that brings bootstrap CSS to former XWiki markup the same way I did in Lyrebird (I've been able to reuse some LESS mixins and inject them under XWiki CSS selectors for example).

Jérôme

The inconvenience with B. is that it require the whole XWiki markup to be

...

adapted, including those produced by existing extensions, providing no compatibility with the past. The inconvenience with C. is that it require any bootstrap variation to be "recompiled" (using less) to be adapted.

My personal idea, that I have defended during the last seminar, is that we should target a state where we are free to change the HTML markup without breaking existing extensions, and the way I propose to do so was to provide more abstraction then we have currently, by providing XWiki macro to generate most of the HTML needed. From the discussion we had, I have understand that reaching that point will be not easy, and could be an unreachable dream, but I am still convinced it could be achieved for a lot of simple applications, so most of them.

What I would find a very annoying situation, is that we refrain to change our skin, and our html markup, simply to keep the compatibility with the past. The currently generated markup is sometime over complex, and followed our own rules. I see the bootstrap integration as the occasion to choose a more popular html markup style, that is already widely used on the net, and that could be easily followed by newcomers. Bootstrap propose to use a very semantic html markup while providing a complete set of UI features. It is a far more clean and simple HTML than we have currently IMO. Also, using a purely bootstrap based solution, without any adaptation, open us to the wide range of bootstrap variation, either paid or free.

Based on our previous experiences, I have the feeling that we have all what we need to get the best of both worlds, and migrate smoothly. We may use method C. (Junco) to provide a good compatibility level for existing extension and to be upgraded templates, while we could use method B. to evolve our skin and simplify our markup. And we may also improve at the same time, our feature that prevent us to manually generate the HTML.

Regarding the JS aspect, Louis-Marie is perfectly right, we have to vote the deprecation of Prototype.js and the usage of JQuery as our default JS framework. I am confident we could reach a consensus on that point, and for those not yet convince, I remind you this post by Sam Stephenson the creator of Prototype.js initially mentionned by Jean-Vincent:

http://sstephenson.us/posts/you-are-not-your-code

So I invite you to open an independent thread for that vote.

Thanks,

On Wed, Feb 19, 2014 at 7:43 PM, Joshua Marks <[email protected]> wrote:

Curriki geometry is using bookstrap. http://www.currikigeometry.org/

...

-----Original Message----- From: devs [mailto:[email protected]] On Behalf Of Guillaume "Louis-Marie" Delhumeau Sent: Wednesday, February 19, 2014 6:37 AM To: XWiki Developers Subject: Re: [xwiki-devs] [Discussion][Skin] Bootstrap integration

inside

...

platform

Bootstrap is a good choice because: 1/ it is well-known 2/ it provides a nice grid-system (good for the responsiveness) 3/ it offer components that developers can re-use

But theses components uses jQuery, and no-choice have been made yet about the new javascript framework we should use.

Louis-Marie

2014-01-28 13:14 GMT+01:00 Ecaterina Moraru (Valica) < [email protected]

...

:

Hi,

...

As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki.

Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin

Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com).

This thread's purpose is to discuss possible problems we might face by integrating Bootstrap inside platform. You can find the investigation page at http://design.xwiki.org/xwiki/bin/view/Proposal/BootstrapIntegration

Besides the already mentioned problems I would want to know the community's opinion about this framework. Have you worked with it? Do you think we should consider some alternatives? See some other frameworks at http://usablica.github.io/front-end-frameworks/compare.html

Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________

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

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

-- Jérôme Velociter +33 786 993 355 @jvelo Open source e-commerce and marketplaces made simple www.mayocat.org 46cl www.46cl.fr

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

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

Thanks Denis. It works, indeed. 2014-03-17 20:21 GMT+01:00 Denis Gervalle <[email protected]>:

On Mon, Mar 17, 2014 at 5:12 PM, Jeremie BOUSQUET < [email protected]> wrote:

...

Hi,

2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau < [email protected]>:

...

Hi Guys.

I am starting to do the implementation of Flamingo without integrating LESS into the platform. That is my objective for 6.0.

So I have started to override some templates (.vm files) in my flamingo directory, and make them use the default bootstrap classes like ".btn", ".navbar", etc... (method B).

But we have some UI elements that are not generated by our templates but by some JavaScript's (example: xwiki-platform-web : resources/js/xwiki/actionButton.js). They generate HTML code that match for the colibri skin but not for other skins.

Moreover, we have our own classes (like xform) that are used everywhere and I do not have the time to rewrite them all, which would also break the compatibility with Colibri.

This issue has been already explained by Denis: http://markmail.org/thread/shd55qxt7w56ypy3

So I have started to create a kind of "compatibility.css" file, using LESS, that do the mapping between our default classes (like "buttonwrapper") to the bootstrap classes. And it works well (method C).

That means that we need this kind of "mixed approach" with both the XWiki's classes and the bootstrap's. (method B+C)

Other thing: I use LESS compiler on my own machine to create the mapping CSS file. I am not able to execute the LESS compiler during the maven build because the mojo for less is out-of-date: https://github.com/marceloverdijk/lesscss-maven-plugin . So I just commit the compiled file in the repository. This is not very nice but I don't see what else I can do.

Maybe you could use antrun or exec mojo to run rhino/less directly, without the proper (outdated) mojo ? Did you try declaring dependency to less (in expected version) as a dependency of the less lesscss-maven-plugin (like, overloading default version), if APIs are the same maybe it could work ...

From this post [1], it seems possible to use any later version of Less with the plugin. Have you tried that ?

[1] http://stackoverflow.com/a/21791432

...

...

Thanks, Louis-Marie

2014-02-24 17:40 GMT+01:00 Jérôme Velociter <[email protected]>:

...

Hi all,

On 02/22/2014 11:56 PM, Denis Gervalle wrote:

...

Hi Cathy,

To integrate bootstrap with XWiki, several approaches has been investigated:

A. Jerome, with the Lyrebird skin, has adapted the bootstrap CSS

to

...

...

the

...

...

current XWiki markup and templates B. Myself, with the Bluebird skin, has adapted the XWiki templates to the bootstrap CSS to partially target the Flamingo skin look. C. You, Cathy, with the Junco skin, has bridge the bootstrap CSS to adapt it to the XWiki markup and templates

The inconvenience with A. was the inability to use any of the existing bootstrap variations available, and to follow the bootstrap evolution easily. So, A is no go for me.

I agree, it's definitely not convenient, not maintainable, and locks the whole thing in a mix of bootstrap and XWiki.

Here's an idea though : maybe you can use this strategy for backward compatilibility, by generating a optional compatibility.css file that brings bootstrap CSS to former XWiki markup the same way I did in Lyrebird (I've been able to reuse some LESS mixins and inject them under XWiki CSS selectors for example).

Jérôme

The inconvenience with B. is that it require the whole XWiki markup to be

...

adapted, including those produced by existing extensions, providing no compatibility with the past. The inconvenience with C. is that it require any bootstrap variation to be "recompiled" (using less) to be adapted.

My personal idea, that I have defended during the last seminar, is that we should target a state where we are free to change the HTML markup without breaking existing extensions, and the way I propose to do so was to provide more abstraction then we have currently, by providing XWiki macro to generate most of the HTML needed. From the discussion we had, I have understand that reaching that point will be not easy, and could be an unreachable dream, but I am still convinced it could be achieved for a lot of simple applications, so most of them.

What I would find a very annoying situation, is that we refrain to change our skin, and our html markup, simply to keep the compatibility with the past. The currently generated markup is sometime over complex, and followed our own rules. I see the bootstrap integration as the occasion to choose a more popular html markup style, that is already widely used on the net, and that could be easily followed by newcomers. Bootstrap propose to use a very semantic html markup while providing a complete set of UI features. It is a far more clean and simple HTML than we have currently IMO. Also, using a purely bootstrap based solution, without any adaptation, open us to the wide range of bootstrap variation, either paid or free.

Based on our previous experiences, I have the feeling that we have all what we need to get the best of both worlds, and migrate smoothly. We may use method C. (Junco) to provide a good compatibility level for existing extension and to be upgraded templates, while we could use method B. to evolve our skin and simplify our markup. And we may also improve at the same time, our feature that prevent us to manually generate the HTML.

Regarding the JS aspect, Louis-Marie is perfectly right, we have to vote the deprecation of Prototype.js and the usage of JQuery as our default JS framework. I am confident we could reach a consensus on that point, and for those not yet convince, I remind you this post by Sam Stephenson the creator of Prototype.js initially mentionned by Jean-Vincent:

http://sstephenson.us/posts/you-are-not-your-code

So I invite you to open an independent thread for that vote.

Thanks,

On Wed, Feb 19, 2014 at 7:43 PM, Joshua Marks <[email protected]> wrote:

Curriki geometry is using bookstrap. http://www.currikigeometry.org/

...

-----Original Message----- From: devs [mailto:[email protected]] On Behalf Of Guillaume "Louis-Marie" Delhumeau Sent: Wednesday, February 19, 2014 6:37 AM To: XWiki Developers Subject: Re: [xwiki-devs] [Discussion][Skin] Bootstrap integration

inside

...

platform

Bootstrap is a good choice because: 1/ it is well-known 2/ it provides a nice grid-system (good for the responsiveness) 3/ it offer components that developers can re-use

But theses components uses jQuery, and no-choice have been made yet about the new javascript framework we should use.

Louis-Marie

2014-01-28 13:14 GMT+01:00 Ecaterina Moraru (Valica) < [email protected] >:

Hi, > > As part of the 6.0 Roadmap we have as entry the creation/integration > of a new Skin inside XWiki. > > Currently there are 2 proposals for the new skin: > Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x > Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin > > Both proposals are done using Twitter's Bootstrap framework ( > http://getbootstrap.com). > > This thread's purpose is to discuss possible problems we might face by > integrating Bootstrap inside platform. You can find the investigation > page at > http://design.xwiki.org/xwiki/bin/view/Proposal/BootstrapIntegration > > Besides the already mentioned problems I would want to know the > community's opinion about this framework. Have you worked with it? Do > you think we should consider some alternatives? See some other > frameworks at > http://usablica.github.io/front-end-frameworks/compare.html > > Thanks, > Caty > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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

-- Jérôme Velociter +33 786 993 355 @jvelo Open source e-commerce and marketplaces made simple www.mayocat.org 46cl www.46cl.fr

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

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

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

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs