[xwiki-devs] [Discussion][Skin] Bootstrap integration inside platform

List overview All Threads
Download

newer

older

[xwiki-devs]...

[xwiki-devs] [VOTE] Create...

Ecaterina Moraru (Valica)

28 Jan 2014 28 Jan '14

1:14 p.m.

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

Show replies by date

Guillaume "Louis-Marie" Delhumeau

19 Feb 19 Feb

3:36 p.m.

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) <valicac(a)gmail.com>om>:

...

Joshua Marks

7:43 p.m.

New subject: [xwiki-devs] [Discussion][Skin] Bootstrap integration inside platform

Curriki geometry is using bookstrap. http://www.currikigeometry.org/ -----Original Message----- From: devs [mailto:devs-bounces@xwiki.org] 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) <valicac(a)gmail.com>om>:

...

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Denis Gervalle

22 Feb 22 Feb

11:56 p.m.

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 <jmarks(a)curriki.org> wrote:

...

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

vincent＠massol.net

24 Feb 24 Feb

1:34 p.m.

New subject: [xwiki-devs] [Discussion][Skin] Bootstrap integration inside platform

Hi Denis/All, On 22 Feb 2014 at 23:57:15, Denis Gervalle (dgl@softec.lu(mailto:dgl@softec.lu)) wrote:

...

I think there’s a way out of this. I can imagine at least 2 options: 1) Since each skin is allowed to have its own templates so it would be possible to move the current templates in the colibri skin’s directory for example and start fresh with some new templates. Then once we have the new skin, deprecate colibri if we don’t want to maintain 2 skins but continue to make it available through extensions.xwiki.org 2) Package the current templates in a legacy zip and allow users to install it if they need backward compatibility. Variation to this: make it configurable for XWiki to choose which template dir to use through a configuration option (right now it looks in templates/ AFAIK). The idea would be to allow having several templates directories to support backward compatibility.

...

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.

Yes please open a vote on this. Thanks -Vincent

...

Thanks, On Wed, Feb 19, 2014 at 7:43 PM, Joshua Marks wrote: > Curriki geometry is using bookstrap. http://www.currikigeometry.org/ > > -----Original Message----- > From: devs [mailto:devs-bounces@xwiki.org] 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) : > > > 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

Jérôme Velociter

5:40 p.m.

New subject: [xwiki-devs] [Discussion][Skin] Bootstrap integration inside platform

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

...

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 <jmarks(a)curriki.org> wrote:

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

Guillaume "Louis-Marie" Delhumeau

17 Mar 17 Mar

3:41 p.m.

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. Thanks, Louis-Marie 2014-02-24 17:40 GMT+01:00 Jérôme Velociter <jerome(a)velociter.fr>fr>:

...

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

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 <jmarks(a)curriki.org> wrote: Curriki geometry is using bookstrap. http://www.currikigeometry.org/

-----Original Message----- From: devs [mailto:devs-bounces@xwiki.org] 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) <valicac(a)gmail.com

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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________

devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list devs(a)xwiki.org 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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Jeremie BOUSQUET

5:12 p.m.

Hi, 2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com>gt;:

...

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 <jerome(a)velociter.fr>fr>:

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.

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

> 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

> "recompiled" (using less) to be adapted. > > My personal idea, that I have defended during the last seminar, is that

> 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

> 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

> 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 <jmarks(a)curriki.org>

wrote:

> > Curriki geometry is using bookstrap. http://www.currikigeometry.org/ >> >> -----Original Message----- >> From: devs [mailto:devs-bounces@xwiki.org] 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) <

valicac(a)gmail.com

>: 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 > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Denis Gervalle

8:21 p.m.

On Mon, Mar 17, 2014 at 5:12 PM, Jeremie BOUSQUET < jeremie.bousquet(a)gmail.com> wrote:

...

Hi, 2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com>gt;:

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

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.

...

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 <jerome(a)velociter.fr>fr>:

the >> current XWiki markup and templates >> B. Myself, with the Bluebird skin, has adapted the XWiki templates

>> 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

be >> "recompiled" (using less) to be adapted. >> >> My personal idea, that I have defended during the last seminar, is

that

> should target a state where we are free to change the HTML markup

without

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.

>> 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 <jmarks(a)curriki.org>

wrote:

inside

about

>> the new javascript framework we should use. >> >> Louis-Marie >> >> >> 2014-01-28 13:14 GMT+01:00 Ecaterina Moraru (Valica) <

valicac(a)gmail.com >>> >: >>> >>> 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

>>>> 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?

>> 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 >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > >

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

Guillaume "Louis-Marie" Delhumeau

18 Mar 18 Mar

11:04 a.m.

Thanks Denis. It works, indeed. 2014-03-17 20:21 GMT+01:00 Denis Gervalle <dgl(a)softec.lu>lu>:

...

On Mon, Mar 17, 2014 at 5:12 PM, Jeremie BOUSQUET < jeremie.bousquet(a)gmail.com> wrote:

Hi, 2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com>gt;:

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

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

LESS, > that do the mapping between our default classes (like "buttonwrapper")

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 <jerome(a)velociter.fr>fr>: > > > 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

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

> >> 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

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

> be > >> adapted, including those produced by existing extensions, providing

>> compatibility with the past. >> The inconvenience with C. is that it require any bootstrap variation

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

> >> 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.

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.

>> 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 <jmarks(a)curriki.org> > wrote: > >> > >> Curriki geometry is using bookstrap.

http://www.currikigeometry.org/

> >>> > >>> -----Original Message----- > >>> From: devs [mailto:devs-bounces@xwiki.org] 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/

> >>> 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) < > valicac(a)gmail.com > >>> >: > >>> > >>> 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

>>>> 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?

>>> 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 >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> 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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

3835

days inactive

3884

days old

xwiki-devs@xwiki.org

Manage subscription

9 comments

7 participants

tags (0)

participants (7)

Denis Gervalle
Ecaterina Moraru (Valica)
Guillaume "Louis-Marie" Delhumeau
Jeremie BOUSQUET
Joshua Marks
Jérôme Velociter
vincent＠massol.net