17 Mar
2014
17 Mar
'14
8:21 p.m.
On Mon, Mar 17, 2014 at 5:12 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com> wrote:
CSS
to
net,
using a
and
by
_______________________________________________
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
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>:
to
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 >> 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 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
we
the
> 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 > 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 > 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, >> 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, > 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
>>>> 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