Re: [xwiki-devs] [Brainstorming] Applications / Skin dependence

Hi, This is a very complex subject, I read the proposal but it's difficult to choose ... Some thoughts below, more than answers. I'm in now way a css expert anyway :) There could be some additional info on extensions repository, telling you what is the "favorite skin" of an existing application. Something like "Best viewed with Flamingo-style skin". For this example, you would put most efforts on the look of the app under flamingo skin, and just minimal maintenance on how it looks with colibri (ie, check that functionalities are fulfilled, even if display is not optimal). Whatever the solution (branch not branch var1 2 3 4 ...), it's always a logical branch in terms of maintenance/validation, so it's always a cost for the application owner. Sometimes the line between pure presentation and "feature" is blurred. For example creating items from a pop-up (modal), to me it's not something that should depend on the skin. It only depends on your app. And it's already possible without bootstrap or flamingo, "bundled in XE" (like, users creation form). The way you display form fields is pure presentation (grid/columns/vertical/horizontal), but it's difficult to anticipate some semantic meaning of your fields when you use vertical layout / colibri, that would affect how you display them in a grid with bootstrap. Going back to your examples in [1], (i) and (ii) screenshots, from the bootstrap version I could define that there is a "title" zone (left column), an "assignment" zone (left column, over 2 sub-columns), a "status" zone (right column), and a "description" zone (below). I would use those names as css classes, then assign them a style according to the skin (bootstrap grids and whatever I want or nothing in colibri). But this I can only define once I migrated to a grid display, from the original view with colibri (vertical layout), I think I'd never have though about such structure. But putting in place this structure with proper css classes is a good thing for my app, whatever the skin. The fact that it won't improve the display in colibri is not an issue, at least it will not destroy anything. Putting directly the bootstrap "col-*" css classes in my html, has no semantics, mixes presentation with source, and has no benefit apart realizing a strong dependency to bootstrap which is not good for the future. Another question maybe, will colibri be considered an old skin, or an alternative skin ? Usually xwiki team supports only one skin at a time (after some kind of deprecation period), but the problem is that skins like colibri have a longer life-cycle and are more customized by users than older skins used to be (at least, I think). Currently in extension repository there are not so much "full" skins (custom or standard), there are quite a few colorthemes for colibri though, maybe because it's quite easy to create and package a color theme, but it's not so easy to create and package a complete xwiki skin. If creating and packaging skins gets easier (which is an objective I suppose, and is already easier than before), logically there should be more and more custom skins available. It would become even more difficult to solve the problem of presentation of an application depending on the skin. It would be interesting to know what real use of colibri skin is made by existing applications. To explain : in my app (mail archive), I used when I could css classes described by the vertical layout standard ("xform", etc). And I started to implement using velocity variables for colors coming from the ColorTheme, to adapt to the one selected. Apart from that, for the most "customized" views (like the topics view with answers), I generated completely custom HTML and specific css classes - I do not rely at all on colibri for this, except for the colors, because there's nothing fitting my needs in colibri (or in extensions I know). For these pages I completely assume skin compatibility, but at the same time I have nothing to do, except maybe add some mappings with bootstrap classes to improve display, if needed. All this reminds me of a discussion started by Denis on the same topic [2]. I tend to share the same view as Denis about this, that having more standard ways of producing html in xwiki could help solving nicely most issues with skins compatibilities. For example $doc.display is nice, but does only a very small part of the job it could do IMHO. So I started to write some velocity macros to generate form fields from both an XClass field definition, and the translation page prefix. Don't know if it's a good way to go, but based on some naming rules for fields translations (like, prefix.fieldname.hint, prefix.fieldname.label, etc...), if a translation exist or not, I display a field with or without xHint, label, etc. I also have a macro that you can pass an array of field names and that displays the corresponding form with vertical layout. Many things are missing, and the number of arguments of those macros is a bit big (but most of them are optional), but it allowed me to removed many boilerplate html (or boilerplate (% %) sequences, alternatively) from most of my pages with forms. And I like the fact that if a translation for a hint is not available in a language, then it's just not displayed, and I don't have to code this condition everywhere.

Regarding my second remark about semantics, what would be missing is some macro to create a group of fields (ie a fieldset) with a specific css class (as that one can't be generic and depends on your app always and on the meaning of the fields). The semantics of fields do not always relate with where you display them and how they are grouped, but usually, as a good practice, it should. Maybe such macros already exist (maybe in AWM), but they're not published as a public api (or I'm not aware of it). To sum up moving to a new skin should not unlock new functionalities in your app, or else I think you're relying too much on this new skin. It should just unlock new ways of presenting your app UI. I'm more in favor of var3 (relying on a standard), as the parts mostly concerned are forms, and such a standard already exists for forms. If there's a way to have it cleanly adapt for colibri and flaming, and maybe introduce only new rules that may be implemented only with flamingo, I think it could work / be enough. If the standard is materialized by some sort of xwiki api, and applications rely on the standard, and the skins rely on the api, then you lower the maintenance activities. BR, Jeremie [1] http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation [2] http://markmail.org/message/shd55qxt7w56ypy3 2014-04-16 14:08 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>: Hi,