On Wed, Feb 24, 2010 at 11:21, Vincent Massol <[email protected]> wrote:
> > On Feb 24, 2010, at 11:11 AM, Jerome Velociter wrote: > > > On 2/24/10 8:35 AM, Vincent Massol wrote: > >> > >> On Feb 24, 2010, at 12:36 AM, Jerome Velociter wrote: > >> > >>> Hello devs, > >>> > >>> When we are using XWiki for public web sites, most of the time we want > >>> to hide some elements in the UI for guest users (and sometimes for > >>> authenticated users as well). > >>> Currently, it's not elegant to do so : either we have to create a > custom > >>> skin, override a couple of templates (with all the merging nightmare it > >>> bringd when upgrading the wiki) - either we create a SSX to "hide" > >>> visually elements. > >>> None of those solutions are really satisfactory. The first one is > >>> painful, the second one is only a workaround and can be a pain too > >>> (there is no way currently to use a SSX "under certain conditions") > >>> > >>> Before we can handle all this nicely using Interface eXtensions, I > >>> propose to make couple of light changes to some templates to make our > >>> life easier : > >>> > >>> 1) Add 4 variables in layoutvars.vm : > >>> * $displayContentMenu // display or not the content menu (view, edit > >>> links, etc.) true by default > >>> * $displayMainMenu // display or not the main menu (wiki and space > >>> links, user profile) true by default > >> > >> Is this notion not specific to colibri only? Do we want to make it a > generic feature for all skins or do we want to add an empty > skinlayoutvars.vm in templates/ that are there so that skins fill it with > skin-specific vars? > > > > I tend to think we don't want to introduce skin-specific variables. > > I would agree only if the concept are supposed to be generic for all > possible skins. Otherwise if each skin introduces its own concepts, it's > going to be a mess after a while. > > > I would say we have all four variables in templates/ and > > displayContentMenu is ignored for older skins as they had no content > > menu (i.e. everything was in the "main menu"). My description of the > > main menu above was colibri specific indeed > > Let's see what others think. It's not obvious that the number of menus is > generic to all skins. Having at least one menu is probably generic. Having 2 > I'm not sure. Some skins would work fine with only 1 menu. > > Imagine a future skin adds 2 more menus (making it 4 in total). I'm not > sure if it would mean that the Colibri skin didn't use 2 menus. It could > also mean that that new skin has the concepts of 4 menus that other skins > don't have. > > I'm personally +0 on either choice. > > Thanks > -Vincent > > >>> * $displayDocExtra // display or not the tabs with doc extra links > >>> (comments, attachments, etc.) true by default > >> > >> Don't we already have a variable for hiding the doc extra tabs? We need > to make sure we use the same one. > > > > I will check that, yes. > > > > Jerome. > >> > >>> * $displayShortcuts // display or not the document shortcuts (those are > >>> in the line written under the document title) > >>> > >>> (this is XWIKI-4394 "Allow some UI elements not to be displayed by > >>> setting a variable") > >>> > >>> 2) Add a "extravars.vm" template that remains empty by default. This > >>> will allow to override values from xwikivars/layoutvars without the > need > >>> to override them (and introducing the merging pain upon upgrade). > >>> > >>> (this is XWIKI-4927 "We need a way to be able to override variables > from > >>> xwikivars.vm / layoutvars.vm without overriding these templates") > >>> > >>> Please let me know what you think, I would like to move forward with > >>> this during 2.3 > >> > >> +1 > >> > >> Thanks > >> -Vincent > Hello devs, As you may know, we build web sites since a while with XWiki and we have had to face the issues describe by Jerome. Modified VMs was really a pain for us when we need to upgrade to a newer XWiki version. This is why during our move from 1.4 to 1.9, we have mostly stopped using VM in our own skins, and we now apply the needed changes directly into the .vm on the server using patches, which are a more maintainable (I have move them to 2.2 in less then an hour). So there is not only the issue regarding hidding interface for which we need to do so (we had advanced google analytics, accessibility markup, company logo, additionnal docextras (rigths), ...). Since we host a farm, with many different XWiki requiring different behaviors, these patches should also be customizable from the preferences of each wikis. In particular, we have a patch for hiding interface elements, not only menus but also tags, authors, docextras globally and separately (also taking care of removing related menu options), copyrights, version,... , that extends the capacity initially available through the old hidden preferences named showcomments, showattachements,... To allow easy customization directly from XWikiPreferences without cluttering the XWikiPreference class (like the several show... does IMO), we have only added a single multi-valued static list, that list what we want hidden. We have also categorized several kind of users: guest, users, editors, managers, admin and all, based on some predefined group (XWikiAllGroup, XWikiEditGroup, XWikiManagerGroup,...) and we provide a leveled hiding of each interface element in a manner that guest do not see what users can't see, guest and users do not see what editors can't see, and so on... This has reveal to be really easy and practical, since we have a consistent and uncluttered interface for each kind of users, and the behavior is customizable for each spaces. Since this is a more featured extension, the trade of, compare to Jerome proposal, is that it is a less flexible approach, the velocity code being already written with some predefined behavior. Anyway, I hope you were interested by my story. If you want more, I am open to share any of these patches... but to be really useful in a general case, additional tuning is probably required. Thanks for reading me. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
