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