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