[Discussion][Skin] Bootstrap integration inside platform

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

[Discussion][Skin] Bootstrap integration inside platform

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
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Discussion][Skin] Bootstrap integration inside platform

Guillaume "Louis-Marie" Delhumeau
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) <[hidden email]>:

> 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
> [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: [Discussion][Skin] Bootstrap integration inside platform

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

-----Original Message-----
From: devs [mailto:[hidden email]] 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) <[hidden email]>:

> 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
> [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: [Discussion][Skin] Bootstrap integration inside platform

Denis Gervalle-2
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 <[hidden email]> wrote:

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



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

Re: [Discussion][Skin] Bootstrap integration inside platform

vmassol
Administrator
Hi Denis/All,

On 22 Feb 2014 at 23:57:15, Denis Gervalle ([hidden email](mailto:[hidden email])) 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.
> 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.

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:[hidden email]] 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
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Discussion][Skin] Bootstrap integration inside platform

Jérôme Velociter
In reply to this post by Denis Gervalle-2
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 <[hidden email]> wrote:
>
>> Curriki geometry is using bookstrap. http://www.currikigeometry.org/
>>
>> -----Original Message-----
>> From: devs [mailto:[hidden email]] 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) <[hidden email]>:
>>
>>> 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
>>> [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
>>
>
>


--
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Discussion][Skin] Bootstrap integration inside platform

Guillaume "Louis-Marie" Delhumeau
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 <[hidden email]>:

> 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 <[hidden email]> wrote:
>>
>>  Curriki geometry is using bookstrap. http://www.currikigeometry.org/
>>>
>>> -----Original Message-----
>>> From: devs [mailto:[hidden email]] 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) <[hidden email]
>>> >:
>>>
>>>  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
>>>> [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
>>>
>>>
>>
>>
>
> --
> 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
> [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: [Discussion][Skin] Bootstrap integration inside platform

jerem
Hi,


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

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>
> wrote:
> >>
> >>  Curriki geometry is using bookstrap. http://www.currikigeometry.org/
> >>>
> >>> -----Original Message-----
> >>> From: devs [mailto:[hidden email]] 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) <
> [hidden email]
> >>> >:
> >>>
> >>>  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
> >>>> [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
> >>>
> >>>
> >>
> >>
> >
> > --
> > 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
> > [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: [Discussion][Skin] Bootstrap integration inside platform

Denis Gervalle-2
On Mon, Mar 17, 2014 at 5:12 PM, Jeremie BOUSQUET <
[hidden email]> wrote:

> Hi,
>
>
> 2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau <
> [hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > wrote:
> > >>
> > >>  Curriki geometry is using bookstrap. http://www.currikigeometry.org/
> > >>>
> > >>> -----Original Message-----
> > >>> From: devs [mailto:[hidden email]] 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) <
> > [hidden email]
> > >>> >:
> > >>>
> > >>>  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
> > >>>> [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
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > 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
> > > [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
>



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

Re: [Discussion][Skin] Bootstrap integration inside platform

Guillaume "Louis-Marie" Delhumeau
Thanks Denis.

It works, indeed.


2014-03-17 20:21 GMT+01:00 Denis Gervalle <[hidden email]>:

> On Mon, Mar 17, 2014 at 5:12 PM, Jeremie BOUSQUET <
> [hidden email]> wrote:
>
> > Hi,
> >
> >
> > 2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau <
> > [hidden email]>:
> >
> > > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>
> > > wrote:
> > > >>
> > > >>  Curriki geometry is using bookstrap.
> http://www.currikigeometry.org/
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: devs [mailto:[hidden email]] 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) <
> > > [hidden email]
> > > >>> >:
> > > >>>
> > > >>>  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
> > > >>>> [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
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > > > --
> > > > 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
> > > > [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
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs