1 Feb
2013
1 Feb
'13
12:43 p.m.
On Fri, Feb 1, 2013 at 11:52 AM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
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?
What we are discussing is mainly to get away from producing the same html
in several places of our standard UI, so we can change it easily for
creating different kind of skins. Currently, to produce a button in the
XWiki UI, we always use the same html, but we produce that same HTML from
different places in the source code, and it is therefore not easy to change
the way button are rendered (to conform with markup require by bootstrap
for example).
Usually, you do not really care about the HTML since you can use a custom
CSS to change its appearance. But here, we definitely want to the opposite,
adapting our HTML to support existing CSS like bootstrap, and benefit of
all the derived CSS based on it very easily.
In no way, this will change your ability to use HTML in XWiki, we will
propose additional way to produce UI elements that will
integrate seamlessly with the XWiki UI. For exampke, when you write an
extension, you may want your extension to look like the rest of the UI, and
not reinvent the button.
paul
On 1 févr. 2013, at 11:09, Jean-Vincent Drean wrote:
--
Jean-Vincent Drean,
XWiki.
_______________________________________________
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
eGuilde sarl - CTO
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 <paul(a)hoplahup.net>
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 <dgl(a)softec.lu> 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
> 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