Correct Jean-Vincent, and I was probably too harsh describing it, but I understood Ecaterina's point to be a strive for a radical request to move away from html. Maybe this can be described in several stages?
paul On 1 févr. 2013, at 11:09, Jean-Vincent Drean wrote: > AFAIU the thread is not about breaking things, it's about using xwiki > syntax and macros (mostly for forms since the 2.0 syntax covers a lot > of the html markup) to benefit from a standardized styling. Existing > HTML would still be working, and it would be possible to write apps > with HTML, but you'd have to handle styling on your own. > > On Thu, Jan 31, 2013 at 10:20 PM, Paul Libbrecht <[email protected]> wrote: >> >> Breaking the very broad toolset and knowledge of developers in HTML to >> create XWiki content and applications is, to me, suicidal. >> Who would be ready to replace most of its html by macros? >> >> Paul >> >> >> On 31 janv. 2013, at 15:26, Ecaterina Moraru (Valica) wrote: >> >>> Hi Denis, >>> >>> When we discussed the Vertical Forms Standard [1] Thomas mentioned >>> something about "commons tools to follow that standard (like form related >>> wiki macros for example)". Some considered that having macros for standard >>> HTML controls will just duplicate HTML language. >>> >>> One advantage of having such macros would be that for example (let's say >>> the macros will be defined in macros.vm) if you want to change the classes >>> used by the controls (like .buttonwrapper class for example), you are just >>> changing the macros, not all the places that call them. >>> >>> This way you could easily change what classes you assign to a button for >>> example from span.buttonwrapper input.button.secondary to >>> button.btn.btn-primary (bootstrap way - of course we will also need to >>> standardize the usage component: input, button, a, etc.) >>> >>> The example above refers mostly to standard HTML elements. Of course if you >>> want to use other types of components from different frameworks you will >>> need to rewrite the templates, and this always calls for a new skin. >>> >>> I thought about new skins for XWiki and since I joined the project we >>> mostly deprecated old skins than creating new ones. But one problem I have >>> is the concept of base skin. For me the base skin should be something very >>> minimal. >>> It should contain just the typography, standard controls, the grid, the >>> reset, anyway elements that are not layout dependent and that will work for >>> any skin. I'm not sure about templates, because mostly templates refer to >>> layout and how you arrange things and what functionality you reveal and >>> where, and this usually change with a new skin. Technical the base skin >>> should contain the Standard, the base for things that will remain the same >>> no matter what. Right now Colibri covers much more than that. >>> >>> And this standard is absolutely necessary also for the way we go with >>> extensions. We know very well that in an Open Source project, everybody >>> codes with his own style and having a common ground is essential from a >>> consistency point of view. All the applications that will be created and >>> published by the community members should have a common style that could >>> make them integrate well inside XWiki, no matter of the creator. >>> >>> So the conclusion is that for this we will need a very well documented >>> standard and the tools to enforce it. Not sure what this means. >>> >>> Also other things worth discussing is colorthemes variables and macros >>> against LESS variables and mixins. >>> Also the Bootstrap / LESS is also a direction bet, just like Prototype vs. >>> JQuery, and the solution we pick it would be great if it would be loosely >>> coupled. >>> >>> Thanks, >>> Caty >>> >>> P.S. Another discussion somehow related to extensibility is [Discussion] >>> Problematic ColorTheme extensibility >>> http://markmail.org/thread/ex6fgou6fl6vjwfr >>> >>> [1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms >>> >>> >>> On Tue, Jan 29, 2013 at 8:10 PM, Denis Gervalle <[email protected]> wrote: >>> >>>> Hi Devs, >>>> >>>> As you may have noted from a previous mail, I have given a try to skin >>>> XWiki differently, based on Bootstrap. There is certainly many ways to get >>>> it done, but IMO, building over any pre-made css solution requires an >>>> adaptation of the HTML generated. >>>> >>>> In the early days of XWiki, the were few places were we have HTML >>>> generated. Most of the html produce came from three major places: >>>> 1) .vm templates including macros.vm >>>> 2) java generated (#display()) >>>> 3) XWiki tech document >>>> >>>> While 2) and 3) either provide very basic markup or customizable one and >>>> are not so much, and 1) was fully customizable by skins, to work out a new >>>> skin was not too complex. >>>> >>>> Today however, the UI of XWiki has considerably increase its complexity, >>>> and the source of HTML has followed, added to the above 3: >>>> 4) XWiki and Java macros >>>> 5) JavaScript (ie: annotation UI, comments preview) >>>> >>>> Changing all these places has become really more painful. There is no >>>> central place, and a lot of hidden dependencies between UI components >>>> exists. Worse examples are those written in JS, that hook into the UI. >>>> >>>> I should admit that I have not a clear idea of the best way to improve >>>> that, but my feeling is that changing so much places simply to adapt our >>>> wiki skin to the "a la mode" skin solution (something that will happen >>>> again) is not nice. >>>> >>>> So this thread is now open for anyone to discuss the situation and for >>>> anyone interested to provide its input to the discussion. >>>> >>>> Looking at what I face building the UI with bootstrap, here is what I >>>> noticed: >>>> >>>> 1) Bootstrap customize standard tags, without any css class associated >>>> 2) Bootstrap provide standard css classes to skin a given kind of UI >>>> component >>>> 3) Bootstrap use these class and custom attribute to inject JS >>>> interactivity >>>> >>>> All these are really clean methods and work really well at building very >>>> simple html construct while providing nice looking and easy interface. >>>> >>>> Let's take a concrete example, to build a button, you may use either an a >>>> tag, an input tag, a button tag or whatever, and set it a 'btn' css class. >>>> You may complement it with additional 'btn-primary', 'btn-success', ... css >>>> classes, to choose the kind of button you really want. >>>> >>>> However, in our XWiki UI, there no single place where we construct buttons, >>>> we do so in some velocity macros of macros.vm, we do so in .vm of the UI, >>>> we also do so in javascript, and finally in some wiki documents, maybe we >>>> also generate some in a java component. >>>> All those buttons are usually built the same, with a very similar HTML, but >>>> there is no central place where the button markup is produced. >>>> >>>> And the same is true for most UI component. You may say we don't care, and >>>> CSS could solve them all, making any kind of markup look the way we want. >>>> But, we will loose the benefit of using existing CSS solution. And there >>>> are interesting benefit to that, since those solution gets customized, see >>>> BootsWatch for example. >>>> >>>> Therefore, it seems to me that we need something like an UI generator, so >>>> that when you build a application, you would simply says, I want a primary >>>> button here, a secondary button there, and it gets created both the way it >>>> should for your apps to use it, but also for the UI design we want to use. >>>> >>>> Defining a list of these UI component is not simple, but we may take >>>> Bootstrap as a starting point. There is in Bootstrap a large number of >>>> control already, that should cover many UI possibilities. >>>> >>>> How to provide that UI component to all the places we need it may be less >>>> obvious. For example, we need to create button from .vm, XWiki document, >>>> XWiki and java Macros, and even from javascript. Also defining how you >>>> could expect to interact with each control, from Javascript or from java on >>>> the server needs clarification. >>>> >>>> I have not yet googled, but there may be existing experience regarding >>>> these matters on other project. Not reinventing the wheel is always better. >>>> Your ideas are welcome. >>>> >>>> IMO, we really need that if we want our Skin 4.x to be really more usable >>>> for customization. >>>> >>>> WDYT ? >>>> >>>> >>>> -- >>>> Denis Gervalle >>>> SOFTEC sa - CEO >>>> eGuilde sarl - CTO >>>> _______________________________________________ >>>> 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 > > > > -- > Jean-Vincent Drean, > XWiki. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
