29 Jan
2013
29 Jan
'13
7:10 p.m.
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