6 Jan
2016
6 Jan
'16
9:39 a.m.
Hi Edy and all,
On 5 Jan 2016 at 11:52:24, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
Hi Randy,
From your choice of words (and your continued usage of the now deprecated
"spaces" macro on the homepage, as observed in the screenshot you`ve
provided), I understand that you still see things in terms of "creating
spaces" and "creating documents inside spaces" in 7.4 and, IMO, that`s
really the issue.
In case you`ve missed it from the release notes, starting with 7.2, we`ve
introduced the notion of Nested Pages [1], which means that you no longer
have the notion of "pages inside spaces", but always "pages inside
pages".
Technically, it is actually implemented by always creating a "space" when
you create a page from the UI, but the user should see it as if he is
always creating a page.
= Use Case 1 =
When your users go to your homepage and create a new page "under the Main
space", they are actually creating a nested page (old "space"), under the
homepage (document called "Main") of your wiki. If you change [2] the
homepage of your wiki to point to a different document instead (say
"Some.Other.Homepage"), I`m fairly sure that you do not want your users to
start creating new pages as children of that page (e.g.
"Some.Other.Homepage.NewUserPage"), because that is what the alternative
would lead to.
The logic behind the original decision of handling the homepage differently
was that, even as Guillaume was hinting, the homepage is seen as the "root"
of your wiki. Creating a page from the root should result in creating top
level pages, not child pages. If you wanted to create a child page of
something from the homepage, you would explicitly do so by selecting a
parent. Not selecting a parent while on the homepage would logically imply
that you want to create a page in the wiki (i.e. top page).
I`m curious why do you find it normal the other way around, i.e. landing on
the wiki (i.e. not navigating somewhere in particular) + creating a new
page => resulting in creating a child page of the "Main" page (which
happens to be the homepage).
If you always create child pages of the homepage ("Main" page), on the long
run, all your URLs will be /Main/This/Page, /Main/That/Page,
/Main/That/Other/Page, etc... but ultimately, what is this "Main", and why
is it that important to drag it along in all your page URLs? (of course,
again, if you change your homepage to "Some.Other.Homepage", all your urls
will be prefixed by that!)
= Use case 2 =
Now, another way of looking at this would be that, for some reason, you
*really* want to keep all your content under some top level page (e.g. as
Vincent suggested, a "Content" container page), perhaps to separate it from
applications (which, for historic reasons, currently are also located in
the top level) like Blog, Sandbox, etc. or any other reason.
The only limitation in this usecase is if you also want to use that
container page ("Main", "Content", etc.) as your homepage. In this
case,
indeed, I see no other solution but to modify the createinline.vm template
or for us to drop this behavior altogether.
---
Conclusion so far:
We have 2 use cases regarding a new page's parent. They can both coexist,
except that, in some cases, the 2nd use case is limited by the first use
case. If we consider this limitation to be a deal breaker, then we are left
with 2 choices:
A. Drop use case 1 (i.e. always propose the current page as parent of the
new page, regardless if the current page is the homepage or not)
B. Make use case 1 configurable (i.e. enable or disable it completely, in
case you are suffering from the limitation of the second use case; this
allows the user to decide if it's useful or not)
Of course, if option B is what we go for, we also need to figure out where
we would put such a configuration.
I would be in favor of option B (since I obviously believe that use case 1
is something useful for the majority of cases), but have no idea on the
location of the configuration.
WDYT?
I agree about what you’ve said above. However I think the main problem comes from the fact
that the user doesn’t know:
* That he’s on a special page (home page). He sees himself/herself on the Main/WebHome
page, i.e. in the Main space.
* The user doesn’t realize that the home page of his/her wiki is a virtual page that can
be configured to point to any page and that it just happens that by default it’s been set
to point to Main.WebHome.
* It can even be argued that the home page doesn’t exist and that the user is redirected
to the page configured in the main wiki’s descriptor, i.e. Main.WebHome and thus when you
click “+” to add a new page you’re not on the home page anywhere but on Main.WebHome.
So, I see 2 choices:
1) Option A, i.e. "drop use case 1 (i.e. always propose the current page as parent of
the new page, regardless if the current page is the homepage or not)."
2) Find a way to make the home page special and different from Main.WebHome. It could be a
special URL as suggested by Guillaume in a previous post, such as
http://localhost:8080/xwiki/bin/view/ and it would redirect to a special resource type for
the home page, which would be served as a template. For
example: http://localhost:8080/xwiki/home. This would be easy to implement. Of course we
would keep the ability to configure where the home page of the main wiki points to in the
Admin UI and /home would be used only when no custom configuration is defined so that it
would still be easy for users to configure what they want to display on the home page. In
order to make it simpler we could even introduce a "Home Page” entry in the Admin UI.
We would also need to find some different content for Main.WebHome.
I haven’t thought about all the consequences of 2) but at first sight it seems it could be
something that could work and could even solve the issue we currently have of it being
hard to edit. Note that the home page wouldn’t have an Edit button. Seen differently, the
home page would be controllable only by an Admin, which IMO can make sense.
So, all in all, I think I’d be in favor of solution 2) (unless some gotchas). Barring
that, I’d prefer solution 1) instead of option B above.
WDYT?
Thanks
-Vincent
Thanks for all your feedback so far and I`m counting
on your help and
anyone else interested to reach a conclusion regarding this.
-Eduard
----------
[1] http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization
[2]
http://www.xwiki.org/xwiki/bin/view/FAQ/How+to+change+the+home+page+destina…
On Mon, Jan 4, 2016 at 3:13 PM, Randy Havens <
Randy.Havens(a)cityofrochester.gov> wrote:
> > So if we bring
> > back the old behavior as-is we'd still have to find a solution for
> > top-level space creation.
>
> That’s already taken care of. This is how I always created spaces before:
> (this is a screenshot from my 7.4 instance, so I know that it is still an
> option)
>
> [cid:image001.png@01D146C6.3625A240]
> > A suggestion I had now that nested spaces are activated by default was to
> > make the home page of the wiki be "above" every other space. Said
> > differently, the home page would reside directly at
> > https:///xwiki/bin/view/
> > without anything else being mentioned. From that page you'd be able to
> > create top-level spaces, and every other page would behave as expected,
> > including Main.WebHome. I think this is what would feel the most natural,
> > but it causes many underlying issues, notably because a page with no
> > document reference cannot really exist in XWiki right now.
>
> I agree. This seems to be a sensible solution.
>
>
> image001.png (23K) <
> http://xwiki.475771.n2.nabble.com/attachment/7597376/0/image001.png>
6 Jan
6 Jan
1:54 p.m.
Hi Vincent,
Thanks for creating a new thread, since that`s what I should have done
myself.
I approached this as a discussion about what is the good/sensible default
that better fits 80-90% of the user's needs, as opposed to not having this
default and the user ending up with "Main" (or whetever else) everywhere
(i.e. cons of not doing Use Case 1).
On Wed, Jan 6, 2016 at 10:39 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi Edy and all,
On 5 Jan 2016 at 11:52:24, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) wrote:
Why would the user care at this point?
Are you talking about the case when a user actually wants to create a new
sub-page under the Main page? In this case we would have a 3rd Use Case
that I have not covered in my previous mail, which, indeed, would be
affected by Use Case 1.
* The user doesn’t realize that the home page of his/her wiki is a virtual
Hi Randy,
From your choice of words (and your continued usage of the now deprecated
"spaces" macro on the homepage, as observed in the screenshot you`ve
provided), I understand that you still see things in terms of "creating
spaces" and "creating documents inside spaces" in 7.4 and, IMO, that`s
really the issue.
In case you`ve missed it from the release notes, starting with 7.2, we`ve
introduced the notion of Nested Pages [1], which means that you no longer
have the notion of "pages inside spaces", but always "pages inside
pages".
Technically, it is actually implemented by always
creating a "space" when
you create a page from the UI, but the user should see it as if he is
always creating a page.
= Use Case 1 =
When your users go to your homepage and create a new page "under the Main
space", they are actually creating a nested page (old "space"), under the
homepage (document called "Main") of your wiki. If you change [2] the
homepage of your wiki to point to a different document instead (say
"Some.Other.Homepage"), I`m fairly sure that you do not want your users
to
start creating new pages as children of that page
(e.g.
"Some.Other.Homepage.NewUserPage"), because that is what the alternative
would lead to.
The logic behind the original decision of handling the homepage
differently
was that, even as Guillaume was hinting, the
homepage is seen as the
"root"
of your wiki. Creating a page from the root
should result in creating top
level pages, not child pages. If you wanted to create a child page of
something from the homepage, you would explicitly do so by selecting a
parent. Not selecting a parent while on the homepage would logically
imply
that you want to create a page in the wiki (i.e.
top page).
I`m curious why do you find it normal the other way around, i.e. landing
on
the wiki (i.e. not navigating somewhere in
particular) + creating a new
page => resulting in creating a child page of the "Main" page (which
happens to be the homepage).
If you always create child pages of the homepage ("Main" page), on the
long
run, all your URLs will be /Main/This/Page,
/Main/That/Page,
/Main/That/Other/Page, etc... but ultimately, what is this "Main", and
why
is it that important to drag it along in all your
page URLs? (of course,
again, if you change your homepage to "Some.Other.Homepage", all your
urls
will be prefixed by that!)
= Use case 2 =
Now, another way of looking at this would be that, for some reason, you
*really* want to keep all your content under some top level page (e.g. as
Vincent suggested, a "Content" container page), perhaps to separate it
from
applications (which, for historic reasons,
currently are also located in
the top level) like Blog, Sandbox, etc. or any other reason.
The only limitation in this usecase is if you also want to use that
container page ("Main", "Content", etc.) as your homepage. In this
case,
indeed, I see no other solution but to modify the createinline.vm
template
or for us to drop this behavior altogether.
---
Conclusion so far:
We have 2 use cases regarding a new page's parent. They can both coexist,
except that, in some cases, the 2nd use case is limited by the first use
case. If we consider this limitation to be a deal breaker, then we are
left
with 2 choices:
A. Drop use case 1 (i.e. always propose the current page as parent of the
new page, regardless if the current page is the homepage or not)
B. Make use case 1 configurable (i.e. enable or disable it completely, in
case you are suffering from the limitation of the second use case; this
allows the user to decide if it's useful or not)
Of course, if option B is what we go for, we also need to figure out
where
we would put such a configuration.
I would be in favor of option B (since I obviously believe that use case
1
is something useful for the majority of cases),
but have no idea on the
location of the configuration.
WDYT?
I agree about what you’ve said above. However I think the main problem
comes from the fact that the user doesn’t know:
* That he’s on a special page (home page). He sees himself/herself on the
Main/WebHome page, i.e. in the Main space.
page that can be configured to point to any page and
that it just happens
that by default it’s been set to point to Main.WebHome.
* It can even be argued that the home page doesn’t exist and that the user
is redirected to the page configured in the main wiki’s descriptor, i.e.
Main.WebHome and thus when you click “+” to add a new page you’re not on
the home page anywhere but on Main.WebHome.
So, I see 2 choices:
1) Option A, i.e. "drop use case 1 (i.e. always propose the current page
as parent of the new page, regardless if the current page is the homepage
or not)."
2) Find a way to make the home page special and different from
Main.WebHome. It could be a special URL as suggested by Guillaume in a
previous post, such as http://localhost:8080/xwiki/bin/view/ and it would
redirect to a special resource type for the home page, which would be
served as a template. For example: http://localhost:8080/xwiki/home. This
would be easy to implement. Of course we would keep the ability to
configure where the home page of the main wiki points to in the Admin UI
and /home would be used only when no custom configuration is defined so
that it would still be easy for users to configure what they want to
display on the home page. In order to make it simpler we could even
introduce a "Home Page” entry in the Admin UI. We would also need to find
some different content for Main.WebHome.
I find this solution a bit too complicated on first sight and it might
cause more problems than it fixes.
On the plus side, it would maybe help differentiating where the user comes
*from*. For example, if the user is on /xwiki/home, then he's on the
homepage and we can apply UseCase1, but if the user is on
/xwiki/bin/view/Main/, then he is just browsing to a page and there we
can/should not apply UseCase1 since if he wants to create a new page there,
he most likely wants the current page as parent. This advantage would help
in Use Case 3, identified above.
Configuring and getting the homepage programatically would still be done as
before, so overall, this would just be a resource/action/template that is
linked to from the logo, nothing more.
However, the question still remains for the limitation on Use Case 2, if
the admin wants to funnel new pages under a certain parent page (which is
the same as the homepage), so we still need a configuration (a.k.a. Option
B) to be able to support that as well.
I haven’t thought about all the consequences of 2) but at first sight it
seems it could be something that could work and could even solve the issue
we currently have of it being hard to edit. Note that the home page
wouldn’t have an Edit button. Seen differently, the home page would be
controllable only by an Admin, which IMO can make sense.
So, all in all, I think I’d be in favor of solution 2) (unless some
gotchas). Barring that, I’d prefer solution 1) instead of option B above.
I might also be inclined towards solution 2) because it solves Use Case 3 +
has the ability to control the UI (remove the edit button). I`m not a fan
of the complexity of this solution though and the questions it could rise
on the long run... "What is this home, is it a resource? Can I use it
programatically? etc..."
My main objective was to remove the "Main" aspect out of XWiki`s URLs since
it`s something we no longer technically/actually/really need (compared to
the pre-ND XWiki versions, where the space part was *technically*
mandatory, so we came up with "Main").
Any other thoughts?
Thanks,
Eduard
WDYT?
Thanks
-Vincent
Thanks for all your feedback so far and I`m
counting on your help and
anyone else interested to reach a conclusion regarding this.
-Eduard
----------
[1]
http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization
[2]
http://www.xwiki.org/xwiki/bin/view/FAQ/How+to+change+the+home+page+destina…
On Mon, Jan 4, 2016 at 3:13 PM, Randy Havens <
Randy.Havens(a)cityofrochester.gov> wrote:
> > So if we bring
> > back the old behavior as-is we'd still have to find a solution for
> > top-level space creation.
>
> That’s already taken care of. This is how I always created spaces
before:
> (this is a screenshot from my 7.4 instance,
so I know that it is still
an
> option)
>
> [cid:image001.png@01D146C6.3625A240]
> > A suggestion I had now that nested spaces are activated by default
was
to
> > make the home page of the wiki be
"above" every other space. Said
> > differently, the home page would reside directly at
> > https:///xwiki/bin/view/
> > without anything else being mentioned. From that page you'd be able
to
> > create top-level spaces, and every
other page would behave as
expected,
> > including Main.WebHome. I think this is
what would feel the most
natural,
> > but it causes many underlying issues,
notably because a page with no
> > document reference cannot really exist in XWiki right now.
>
> I agree. This seems to be a sensible solution.
>
>
> image001.png (23K) <
> http://xwiki.475771.n2.nabble.com/attachment/7597376/0/image001.png>
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
7:11 p.m.
Hi,
On Wed, Jan 6, 2016 at 1:54 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi Vincent,
Thanks for creating a new thread, since that`s what I should have done
myself.
I approached this as a discussion about what is the good/sensible default
that better fits 80-90% of the user's needs, as opposed to not having this
default and the user ending up with "Main" (or whetever else) everywhere
(i.e. cons of not doing Use Case 1).
On Wed, Jan 6, 2016 at 10:39 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
when
alternative
top
landing
as
in
coexist,
the
case
Agreed. However, should the admin decide to include another page to act as
the home, wouldn't it be possible to put a link that would send the user to
edit that page (same as we do for the "Welcome" widget right now)?
Hi Edy and all,
On 5 Jan 2016 at 11:52:24, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) wrote:
> Hi Randy,
>
> From your choice of words (and your continued usage of the now
deprecated
> "spaces" macro on the homepage, as
observed in the screenshot you`ve
> provided), I understand that you still see things in terms of "creating
> spaces" and "creating documents inside spaces" in 7.4 and, IMO,
that`s
> really the issue.
>
> In case you`ve missed it from the release notes, starting with 7.2,
we`ve
> introduced the notion of Nested Pages [1],
which means that you no
longer
have the
notion of "pages inside spaces", but always "pages inside
pages".
> Technically, it is actually implemented by always creating a "space"
> you create a page from the UI, but the user
should see it as if he is
> always creating a page.
>
> = Use Case 1 =
>
> When your users go to your homepage and create a new page "under the
Main
> space", they are actually creating a
nested page (old "space"), under
the
homepage
(document called "Main") of your wiki. If you change [2] the
homepage of your wiki to point to a different document instead (say
"Some.Other.Homepage"), I`m fairly sure that you do not want your users
to
> start creating new pages as children of that page (e.g.
> "Some.Other.Homepage.NewUserPage"), because that is what the would
lead to.
The logic behind the original decision of handling the homepage
differently
was that, even as Guillaume was hinting, the
homepage is seen as the
"root"
> of your wiki. Creating a page from the root should result in creating level
pages, not child pages. If you wanted to create a child page of
something from the homepage, you would explicitly do so by selecting a
parent. Not selecting a parent while on the homepage would logically
imply
> that you want to create a page in the wiki (i.e. top page).
>
> I`m curious why do you find it normal the other way around, i.e. on
course,
the wiki (i.e. not navigating somewhere in
particular) + creating a new
page => resulting in creating a child page of the "Main" page (which
happens to be the homepage).
If you always create child pages of the homepage ("Main" page), on the
long
run, all your URLs will be /Main/This/Page,
/Main/That/Page,
/Main/That/Other/Page, etc... but ultimately, what is this "Main", and
why
> is it that important to drag it along in all your page URLs? (of again, if
you change your homepage to "Some.Other.Homepage", all your
urls
> will be prefixed by that!)
>
> = Use case 2 =
>
> Now, another way of looking at this would be that, for some reason, you
> *really* want to keep all your content under some top level page (e.g. Vincent
suggested, a "Content" container page), perhaps to separate it
from
> applications (which, for historic reasons, currently are also located > the top level) like Blog, Sandbox, etc. or
any other reason.
>
> The only limitation in this usecase is if you also want to use that
> container page ("Main", "Content", etc.) as your homepage. In
this
case,
indeed, I
see no other solution but to modify the createinline.vm
template
> or for us to drop this behavior altogether.
>
> ---
>
> Conclusion so far:
> We have 2 use cases regarding a new page's parent. They can both > except that, in some cases, the 2nd use case
is limited by the first
use
case. If
we consider this limitation to be a deal breaker, then we are
left
> with 2 choices:
> A. Drop use case 1 (i.e. always propose the current page as parent of > new page, regardless if the current page is
the homepage or not)
> B. Make use case 1 configurable (i.e. enable or disable it completely,
in
case you
are suffering from the limitation of the second use case; this
allows the user to decide if it's useful or not)
Of course, if option B is what we go for, we also need to figure out
where
> we would put such a configuration.
>
> I would be in favor of option B (since I obviously believe that use 1
Why would the user care at this point?
Are you talking about the case when a user actually wants to create a new
sub-page under the Main page? In this case we would have a 3rd Use Case
that I have not covered in my previous mail, which, indeed, would be
affected by Use Case 1.
* The user doesn’t realize that the home page of his/her wiki is a virtual
is something useful for the majority of cases),
but have no idea on the
location of the configuration.
WDYT?
I agree about what you’ve said above. However I think the main problem
comes from the fact that the user doesn’t know:
* That he’s on a special page (home page). He sees himself/herself on the
Main/WebHome page, i.e. in the Main space.
page that can be configured to point to any page
and that it just happens
that by default it’s been set to point to Main.WebHome.
* It can even be argued that the home page doesn’t exist and that the
user
is redirected to the page configured in the main
wiki’s descriptor, i.e.
Main.WebHome and thus when you click “+” to add a new page you’re not on
the home page anywhere but on Main.WebHome.
So, I see 2 choices:
1) Option A, i.e. "drop use case 1 (i.e. always propose the current page
as parent of the new page, regardless if the current page is the homepage
or not)."
2) Find a way to make the home page special and different from
Main.WebHome. It could be a special URL as suggested by Guillaume in a
previous post, such as http://localhost:8080/xwiki/bin/view/ and it
would
redirect to a special resource type for the home
page, which would be
served as a template. For example: http://localhost:8080/xwiki/home.
This
would be easy to implement. Of course we would
keep the ability to
configure where the home page of the main wiki points to in the Admin UI
and /home would be used only when no custom configuration is defined so
that it would still be easy for users to configure what they want to
display on the home page. In order to make it simpler we could even
introduce a "Home Page” entry in the Admin UI. We would also need to find
some different content for Main.WebHome.
I find this solution a bit too complicated on first sight and it might
cause more problems than it fixes.
On the plus side, it would maybe help differentiating where the user comes
*from*. For example, if the user is on /xwiki/home, then he's on the
homepage and we can apply UseCase1, but if the user is on
/xwiki/bin/view/Main/, then he is just browsing to a page and there we
can/should not apply UseCase1 since if he wants to create a new page there,
he most likely wants the current page as parent. This advantage would help
in Use Case 3, identified above.
Configuring and getting the homepage programatically would still be done as
before, so overall, this would just be a resource/action/template that is
linked to from the logo, nothing more.
However, the question still remains for the limitation on Use Case 2, if
the admin wants to funnel new pages under a certain parent page (which is
the same as the homepage), so we still need a configuration (a.k.a. Option
B) to be able to support that as well.
I haven’t thought about all the consequences of
2) but at first sight it
seems it could be something that could work and could even solve the
issue
we currently have of it being hard to edit. Note
that the home page
wouldn’t have an Edit button. Seen differently, the home page would be
controllable only by an Admin, which IMO can make sense.
So, all in all, I think I’d be in favor of solution 2)
(unless some
I also like Solution 2) as outlined by Vincent. The only downside I see is
the fact that there will no longer be an "Edit" button on the homepage, but
then on most wikis I've seen users are not supposed to change it anyway,
it's left to the wiki admin / initiator, especially when that page acts as
a dashboard.
The next question (could be for another thread) if we do this would be to
decide whether our current homepage (which is Dashboard.WebHome) is the
best default homepage for XWiki or whether there's a better default option.
I know that on many wikis I remove it altogether to replace it with simply
the activity stream.
Thanks,
Guillaume
Thanks,
gotchas). Barring that, I’d prefer solution 1)
instead of option B above.
I might also be inclined towards solution 2) because it solves Use Case 3 +
has the ability to control the UI (remove the edit button). I`m not a fan
of the complexity of this solution though and the questions it could rise
on the long run... "What is this home, is it a resource? Can I use it
programatically? etc..."
My main objective was to remove the "Main" aspect out of XWiki`s URLs since
it`s something we no longer technically/actually/really need (compared to
the pre-ND XWiki versions, where the space part was *technically*
mandatory, so we came up with "Main").
Any other thoughts?
Eduard
still
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
WDYT?
Thanks
-Vincent
http://www.xwiki.org/xwiki/bin/view/FAQ/How+to+change+the+home+page+destina…
Thanks for all your feedback so far and I`m
counting on your help and
anyone else interested to reach a conclusion regarding this.
-Eduard
----------
[1]
http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization
[2]
On Mon, Jan 4, 2016 at 3:13 PM, Randy Havens <
Randy.Havens(a)cityofrochester.gov> wrote:
> > So if we bring
> > back the old behavior as-is we'd still have to find a solution for
> > top-level space creation.
>
> That’s already taken care of. This is how I always created spaces
before:
> > (this is a screenshot from my 7.4 instance, so I know that it is an
no
> option)
>
> [cid:image001.png@01D146C6.3625A240]
> > A suggestion I had now that nested spaces are activated by default
was
to
> > make the home page of the wiki be
"above" every other space. Said
> > differently, the home page would reside directly at
> > https:///xwiki/bin/view/
> > without anything else being mentioned. From that page you'd be able
to
> > create top-level spaces, and every
other page would behave as
expected,
> > including Main.WebHome. I think this is
what would feel the most
natural,
> > > but it causes many underlying issues, notably because a page with > >
document reference cannot really exist in XWiki right now.
>
> I agree. This seems to be a sensible solution.
>
>
> image001.png (23K) <
> http://xwiki.475771.n2.nabble.com/attachment/7597376/0/image001.png>
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
3176
days inactive
3176
days old
2 comments
3 participants
participants (3)
-
Eduard Moraru -
Guillaume Lerouge -
vincent＠massol.net