25 Feb
2010
25 Feb
'10
12:21 p.m.
On Wed, Feb 24, 2010 at 11:21, Vincent Massol <vincent(a)massol.net> wrote:
On Feb 24, 2010, at 11:11 AM, Jerome Velociter wrote:
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
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