2014-04-30 15:55 GMT+02:00 Jeremie BOUSQUET <[email protected]>:
> > > > 2014-04-30 15:24 GMT+02:00 Jeremie BOUSQUET <[email protected]>: > > 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. >> > > For example, #showFieldsFromPropClassName, with some divs to group some > fields that can be displayed/hidden: > > https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/xwiki-contrib-mailarchive-admin-ui/src/main/resources/MailArchiveCode/AdminSheet.xml#L178-L191 > ... and related translations for the whole admin page, including some error cases: https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/xwiki-contrib-mailarchive-admin-ui/src/main/resources/MailArchiveCode/Translations.xml#L38-L79 > > >> 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) <[email protected]>: >> >> Hi, >>> >>> With the new Flamingo skin and with the design investigations done on >>> existing Applications, there are more and more questions related to: >>> * how will the applications be displayed on the new skin, while >>> conserving >>> the same look on the old skin; >>> * how much an application should preserve previous functionality and how >>> many efforts are we putting in adapting the functionality for new >>> layouts; >>> * when do we create a new application vs. when do we retire one; >>> * etc. >>> >>> This question applies in general to applications and you can also read >>> some >>> discussions about applications like Panels [1] or ColorThemes [2]. >>> >>> In this thread I want to discuss some variants related to application's >>> presentation: >>> >>> http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVariants >>> >>> I am interested in our position regarding this topic and if we have like >>> a >>> 'standard' solution or if the answer depends on the application in cause. >>> >>> Thanks, >>> Caty >>> >>> [1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements >>> [2] >>> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
