On Mon, Mar 17, 2014 at 5:12 PM, Jeremie BOUSQUET < [email protected]> wrote:
> Hi, > > > 2014-03-17 15:41 GMT+01:00 Guillaume "Louis-Marie" Delhumeau < > [email protected]>: > > > Hi Guys. > > > > I am starting to do the implementation of Flamingo without integrating > LESS > > into the platform. That is my objective for 6.0. > > > > So I have started to override some templates (.vm files) in my flamingo > > directory, and make them use the default bootstrap classes like ".btn", > > ".navbar", etc... (method B). > > > > But we have some UI elements that are not generated by our templates but > by > > some JavaScript's (example: xwiki-platform-web : > > resources/js/xwiki/actionButton.js). They generate HTML code that match > for > > the colibri skin but not for other skins. > > > > Moreover, we have our own classes (like xform) that are used everywhere > and > > I do not have the time to rewrite them all, which would also break the > > compatibility with Colibri. > > > > This issue has been already explained by Denis: > > http://markmail.org/thread/shd55qxt7w56ypy3 > > > > So I have started to create a kind of "compatibility.css" file, using > LESS, > > that do the mapping between our default classes (like "buttonwrapper") to > > the bootstrap classes. And it works well (method C). > > > > That means that we need this kind of "mixed approach" with both the > XWiki's > > classes and the bootstrap's. (method B+C) > > > > Other thing: I use LESS compiler on my own machine to create the mapping > > CSS file. I am not able to execute the LESS compiler during the maven > build > > because the mojo for less is out-of-date: > > https://github.com/marceloverdijk/lesscss-maven-plugin . So I just > commit > > the compiled file in the repository. This is not very nice but I don't > see > > what else I can do. > > > > Maybe you could use antrun or exec mojo to run rhino/less directly, without > the proper (outdated) mojo ? > Did you try declaring dependency to less (in expected version) as a > dependency of the less lesscss-maven-plugin (like, overloading default > version), if APIs are the same maybe it could work ... From this post [1], it seems possible to use any later version of Less with the plugin. Have you tried that ? [1] http://stackoverflow.com/a/21791432 > > > Thanks, > > Louis-Marie > > > > > > 2014-02-24 17:40 GMT+01:00 Jérôme Velociter <[email protected]>: > > > > > Hi all, > > > > > > > > > On 02/22/2014 11:56 PM, Denis Gervalle wrote: > > > > > >> Hi Cathy, > > >> > > >> To integrate bootstrap with XWiki, several approaches has been > > >> investigated: > > >> > > >> A. Jerome, with the Lyrebird skin, has adapted the bootstrap CSS to > > the > > >> current XWiki markup and templates > > >> B. Myself, with the Bluebird skin, has adapted the XWiki templates > to > > >> the > > >> bootstrap CSS to partially target the Flamingo skin look. > > >> C. You, Cathy, with the Junco skin, has bridge the bootstrap CSS to > > >> adapt > > >> it to the XWiki markup and templates > > >> > > >> The inconvenience with A. was the inability to use any of the existing > > >> bootstrap variations available, and to follow the bootstrap evolution > > >> easily. So, A is no go for me. > > >> > > > > > > I agree, it's definitely not convenient, not maintainable, and locks > the > > > whole thing in a mix of bootstrap and XWiki. > > > > > > Here's an idea though : maybe you can use this strategy for backward > > > compatilibility, by generating a optional compatibility.css file that > > > brings bootstrap CSS to former XWiki markup the same way I did in > > Lyrebird > > > (I've been able to reuse some LESS mixins and inject them under XWiki > CSS > > > selectors for example). > > > > > > Jérôme > > > > > > > > > The inconvenience with B. is that it require the whole XWiki markup to > > be > > >> adapted, including those produced by existing extensions, providing no > > >> compatibility with the past. > > >> The inconvenience with C. is that it require any bootstrap variation > to > > be > > >> "recompiled" (using less) to be adapted. > > >> > > >> My personal idea, that I have defended during the last seminar, is > that > > we > > >> should target a state where we are free to change the HTML markup > > without > > >> breaking existing extensions, and the way I propose to do so was to > > >> provide > > >> more abstraction then we have currently, by providing XWiki macro to > > >> generate most of the HTML needed. From the discussion we had, I have > > >> understand that reaching that point will be not easy, and could be an > > >> unreachable dream, but I am still convinced it could be achieved for a > > lot > > >> of simple applications, so most of them. > > >> > > >> What I would find a very annoying situation, is that we refrain to > > change > > >> our skin, and our html markup, simply to keep the compatibility with > the > > >> past. The currently generated markup is sometime over complex, and > > >> followed > > >> our own rules. I see the bootstrap integration as the occasion to > > choose a > > >> more popular html markup style, that is already widely used on the > net, > > >> and > > >> that could be easily followed by newcomers. Bootstrap propose to use a > > >> very > > >> semantic html markup while providing a complete set of UI features. It > > is > > >> a > > >> far more clean and simple HTML than we have currently IMO. Also, > using a > > >> purely bootstrap based solution, without any adaptation, open us to > the > > >> wide range of bootstrap variation, either paid or free. > > >> > > >> Based on our previous experiences, I have the feeling that we have all > > >> what > > >> we need to get the best of both worlds, and migrate smoothly. We may > use > > >> method C. (Junco) to provide a good compatibility level for existing > > >> extension and to be upgraded templates, while we could use method B. > to > > >> evolve our skin and simplify our markup. And we may also improve at > the > > >> same time, our feature that prevent us to manually generate the HTML. > > >> > > >> Regarding the JS aspect, Louis-Marie is perfectly right, we have to > vote > > >> the deprecation of Prototype.js and the usage of JQuery as our default > > JS > > >> framework. I am confident we could reach a consensus on that point, > and > > >> for > > >> those not yet convince, I remind you this post by Sam Stephenson the > > >> creator of Prototype.js initially mentionned by Jean-Vincent: > > >> > > >> http://sstephenson.us/posts/you-are-not-your-code > > >> > > >> So I invite you to open an independent thread for that vote. > > >> > > >> Thanks, > > >> > > >> > > >> On Wed, Feb 19, 2014 at 7:43 PM, Joshua Marks <[email protected]> > > wrote: > > >> > > >> Curriki geometry is using bookstrap. http://www.currikigeometry.org/ > > >>> > > >>> -----Original Message----- > > >>> From: devs [mailto:[email protected]] On Behalf Of Guillaume > > >>> "Louis-Marie" Delhumeau > > >>> Sent: Wednesday, February 19, 2014 6:37 AM > > >>> To: XWiki Developers > > >>> Subject: Re: [xwiki-devs] [Discussion][Skin] Bootstrap integration > > inside > > >>> platform > > >>> > > >>> Bootstrap is a good choice because: > > >>> 1/ it is well-known > > >>> 2/ it provides a nice grid-system (good for the responsiveness) 3/ it > > >>> offer > > >>> components that developers can re-use > > >>> > > >>> But theses components uses jQuery, and no-choice have been made yet > > about > > >>> the new javascript framework we should use. > > >>> > > >>> Louis-Marie > > >>> > > >>> > > >>> 2014-01-28 13:14 GMT+01:00 Ecaterina Moraru (Valica) < > > [email protected] > > >>> >: > > >>> > > >>> Hi, > > >>>> > > >>>> As part of the 6.0 Roadmap we have as entry the creation/integration > > >>>> of a new Skin inside XWiki. > > >>>> > > >>>> Currently there are 2 proposals for the new skin: > > >>>> Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x > > >>>> Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin > > >>>> > > >>>> Both proposals are done using Twitter's Bootstrap framework ( > > >>>> http://getbootstrap.com). > > >>>> > > >>>> This thread's purpose is to discuss possible problems we might face > by > > >>>> integrating Bootstrap inside platform. You can find the > investigation > > >>>> page at > > >>>> > http://design.xwiki.org/xwiki/bin/view/Proposal/BootstrapIntegration > > >>>> > > >>>> Besides the already mentioned problems I would want to know the > > >>>> community's opinion about this framework. Have you worked with it? > Do > > >>>> you think we should consider some alternatives? See some other > > >>>> frameworks at > > >>>> http://usablica.github.io/front-end-frameworks/compare.html > > >>>> > > >>>> Thanks, > > >>>> Caty > > >>>> _______________________________________________ > > >>>> devs mailing list > > >>>> [email protected] > > >>>> http://lists.xwiki.org/mailman/listinfo/devs > > >>>> > > >>>> _______________________________________________ > > >>> devs mailing list > > >>> [email protected] > > >>> http://lists.xwiki.org/mailman/listinfo/devs > > >>> > > >>> _______________________________________________ > > >>> devs mailing list > > >>> [email protected] > > >>> http://lists.xwiki.org/mailman/listinfo/devs > > >>> > > >>> > > >> > > >> > > > > > > -- > > > Jérôme Velociter > > > +33 786 993 355 > > > @jvelo > > > Open source e-commerce and marketplaces made simple www.mayocat.org > > > 46cl www.46cl.fr > > > > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
