+1 for the separation.
Thanks,
Caty
On Wed, Aug 3, 2011 at 15:04, Guillaume Lerouge <guillaume(a)xwiki.com> wrote:
Hi,
On Wed, Aug 3, 2011 at 1:21 PM, Vincent Massol <vincent(a)massol.net> wrote:
See below
On Aug 3, 2011, at 1:08 PM, Denis Gervalle wrote:
> On Wed, Aug 3, 2011 at 11:39, Vincent Massol <vincent(a)massol.net>
wrote:
>
>> Hi Denis,
>>
>> On Aug 3, 2011, at 11:19 AM, Denis Gervalle wrote:
>>
>>> Hi Vincent,
>>>
>>> Why are you proposing 2 booleans ? Is there non-technical application
>> spaces
>>> ?
>>
>> Here's an example: The Scheduler space:
>> - it's a technical space (i.e. not shown to all users)
>> - it's an application space (i.e. shown in the Application Panel for
>> advanced users)
>>
>> A second example: The Blog space:
>> - it's a non technical space (i.e. shown to all users)
>> - it's an application space (i.e. shown to all in the Application
Panel)
>
>
>> Another example: The Sandbox space:
>> - it's a non technical space (i.e. shown to all users)
>> - it's not an application space (i.e. not shown in the Application
Panel
> but
shown in the Spaces list in the Dashboard - i.e. in the "Content"
spaces
>> list)
>>
>>> Maybe a static list for qualifying spaces would be better and more
>> flexible,
>>> WDYT ?
>>> Or else, why not having a boolean for really hiding spaces, the true
>>> replacement of blacklistedspaces (there could be non-technical spaces
>> that
>>> admin want to hide anyway) and maybe a static list for qualifying
them
if
>>> you have identified this need?
>>
>> To do that you'd need two lists for hiding spaces: one for simple
users
and
>> one for advanced users. That's because both categories of users don't
>> necessarily match in term of needs.
>>
>> I'm fine to have 3 booleans for each space if you think we need to
have
>> this use case (i.e. ability to not show
spaces for advanced users -
I'm
still unsure we want to do this though):
- is an application space?
- is hidden for simple users (replacing technical space idea)?
- is hidden for advanced users?
This is going worse IMHO. Finally we needs filtering spaces based on
users
> and "types" of space. Reading this, I am more in favor of
"typing"
spaces
(a
single extensible static list), and compute the
blacklistedspaces list
based
on these "types", as well as any other
list of spaces you may imagine,
like
> the list of application spaces. For the blacklistedspaces, computing
the
> list in velocity is finally not so bad, and
could be adapted depending
on
your use
cases. "Typing" spaces would only helps doing it better.
WDYT?
If I understand correctly you're in agreement with all that I've proposed
in my initial email except for the implementation part for which you're
suggesting to use a single "types" property that would hold all possible
space types (rather than having several boolean fields). Something
similar
to tags basically.
I'm very fine with this. I even like it since it's a generalization.
It means though that we need to have some "well-known types" on which we
can depend. Based on the use cases defined so far we would have 3
possible
values:
- "technical": only visible for advanced users
- "application": listed in the Application Panel (and excluded from the
Spaces list in the dashboard)
- "hidden": not displayed to anyone including advanced users (we'd need
to
define more clearly in which screens they'd
be hidden and in which others
they'd be visible to advanced users though)
I'm proposing to start with "technical" and "application" for
now.
Well, 4 types actually, if you also include the normal "content" space
type.
I'm fine with this solution too since it answers the problem of typing
spaces as described above.
Guillaume
WDYT?
Thanks
-Vincent
>
> Denis
>
>
>> What do others think? Do we need the ability to hide spaces for
advanced
>
users?
>
> Thanks
> -Vincent
>
>> Your idea seams to me interesting but will probably fall short or be
> misused
>> on the long term...
>>
>> Denis
>>
>> On Tue, Aug 2, 2011 at 19:05, Vincent Massol <vincent(a)massol.net>
wrote:
>>>
>>>> Hi devs,
>>>>
>>>> I'd like to propose 2 small changes that should make a huge
difference
> for
>>> our users.
>>>
>>> 1) Introduce the notion of technical spaces
>>>
>>> The idea is that in WebPreferences for a space we should have a
boolean
>>> property mentioning if the space is a
technical space or not.
>>> This will allow to:
>>> * Remove the blacklistedspaces variable
>>> * List only non technical spaces for simple users
>>>
>>> 2) Introduce the notion of Application spaces
>>>
>>> The idea is that in WebPreferences for a space we should have a
boolean
>>>> property mentioning if the space is an application space or not.
>>>> This will allow to:
>>>> * Replace the Quick Links Panel with an Applications Panel listing
all
>>>> spaces that are application
spaces
>>>> * Only list Content spaces in the Spaces Gadget in the Dashboard
>>>> * Add the ability for extensions to declare new applications that
>>>> automatically appear in the Applications Panel
>>>>
>>>> I'd also like to suggest adding a global admin preferences to
quickly
>>> select all spaces that are application and/or technical spaces
(imagine
> a
>>> list of all spaces with 2 checkboxes for each space listed). This
makes
> it
>>> very easy for the admin to reconfigure what are application spaces
(thus
>>>> showing in the app panel) and what spaces should be hidden for
simple
>> users.
>>>> Of course modifying these would modify the WebPreferences of the
said
>>>> spaces.
>>>>
>>>> In addition to make this autodiscoverable I'd suggest that for
admins
>> the
>>>> Application Panel should have a link to this admin feature.
Something
>> like
>>>> "Configure Applications...".
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>> PS: I'm very excited about these 2 ideas since they're simple
and
IMO
> will
>>> make XE much easier to use and understand for people starting to use
it.
_______________________________________________
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