7 Aug
2019
7 Aug
'19
2:22 p.m.
Hi everyone,
I'm following up on a thread started in 2015 about the best practices regarding app
pages organization:
- https://xwiki.markmail.org/message/657vcm6ylkz4yytc
- https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…
In this thread, the idea of introducing a dedicated common root area for all application
technical pages was suggested by Denis:
https://xwiki.markmail.org/message/kk5l3dwjmpfelkzp
I'm wondering why this idea was not pushed further (it's not strictly incompatible
with the current best practices, but most of the recent applications have their top level
area, except a few like Notifications or ChartJS).
Comparing with how other platforms do is inspirational (Microsoft Windows "Program
Files" was mentioned in the thread). On Debian, the Maven package is installed in
/usr/share/maven/ while files used and produced by Maven can be located anywhere. Along
the same line, I would see as a user and developer experience improvement if we had the
following structure:
1) Code:
XWiki
|- MyApp
|- MyAppClass
|- MyAppSheet
|- ...
2) Data: the pages created by MyApp could then typically be located by default in a MyApp
space at the root of the wiki, the user could however choose which default space to use,
or leave it empty (then the space from where the user fires the create action could be
used, for instance, or any scriptable rule).
Another issue I see with the current practice (raised by Clément A. orally) is that some
application names may conflict with names the user would like to use for content that is
not strictly related to the app. Not necessarily a big deal with one thousand of
applications, but might become one with more, wouldn't it?
I understand that the layout proposed above would raise technical issues (XWiki space
permissions for instance, mentionned in the 2015 thread, and others), however what's
your view on it from a design perspective? (sorry if I overlooked strong arguments already
expressed against it)
Cheers
Stéphane
20 Aug
20 Aug
10:44 a.m.
Hi Stephane and all,
On 7 Aug 2019, at 14:22, Stéphane Laurière
<slauriere(a)xwiki.com> wrote:
Hi everyone,
I'm following up on a thread started in 2015 about the best practices regarding app
pages organization:
- https://xwiki.markmail.org/message/657vcm6ylkz4yytc
- https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…
In this thread, the idea of introducing a dedicated common root area for all application
technical pages was suggested by Denis:
https://xwiki.markmail.org/message/kk5l3dwjmpfelkzp
I'm wondering why this idea was not pushed further (it's not strictly
incompatible with the current best practices, but most of the recent applications have
their top level area, except a few like Notifications or ChartJS).
Indeed, right now, the best practice is a top level space named after the app
(https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…).
I guess the reason we didn’t do anything else is because we lacked an agreed proposal
simply.
Comparing with how other platforms do is inspirational
(Microsoft Windows "Program Files" was mentioned in the thread). On Debian, the
Maven package is installed in /usr/share/maven/ while files used and produced by Maven can
be located anywhere. Along the same line, I would see as a user and developer experience
improvement if we had the following structure:
1) Code:
XWiki
|- MyApp
|- MyAppClass
|- MyAppSheet
|- …
I don’t think it’s a good idea to put the apps directly under the XWiki space. I feel it
would be better to have an “Applications” subspace as in:
XWiki
|_ Applications
|_ MyApp
|_ …
|_ Users
|_ …
This allows to put other things in the XWiki space, such as users for example.
Note that for me the main reason to avoid putting spaces at the root is to avoid using up
namespaces that can then no longer be used by users. In this spirit the minimum we could
do is reserve only the “XWiki” space.
2) Data: the pages created by MyApp could then
typically be located by default in a MyApp space at the root of the wiki, the user could
however choose which default space to use, or leave it empty (then the space from where
the user fires the create action could be used, for instance, or any scriptable rule).
Why not. I’m just not sure I would mix app data pages with pure content pages and use up
namespaces at the root (you end up with the same issue as I mentioned above and you
below). I agree that data pages shouldn’t go in the /XWiki/Applications space though which
should be readonly.
So there are some other options:
* In /XWiki/Data/MyApp
* Reserve another namespace entry at the root (“Data”): /Data/MyApp
You said " the user could however choose which default space to use”. How would you
plan to implement this? Right now, this would work only if the app provides a template and
the user uses this template to create a new page. For example the FAQ app doesn’t do that
and it provides a UI to create a new FAQ entry and this goes in /FAQ/ directly.
Another issue I see with the current practice (raised by Clément A. orally) is that some
application names may conflict with names the user would like to use for content that is
not strictly related to the app. Not necessarily a big deal with one thousand of
applications, but might become one with more, wouldn't it?
Sure and you get the same issue with your proposal of putting app data at the root under
/MyApp, no?
I understand that the layout proposed above would
raise technical issues (XWiki space permissions for instance, mentionned in the 2015
thread, and others), however what's your view on it from a design perspective? (sorry
if I overlooked strong arguments already expressed against it)
Thanks for starting this thread again.
One other point missing in this discussion is the migration from the current status to any
target. How would we achieve it? How do we migrate an app to follow any new best practice
without breaking users? (Idea:
https://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases).
Let’s start the discussion ;)
Thanks
-Vincent
Cheers
Stéphane
22 Aug
22 Aug
9:39 a.m.
Hi Vincent, Hi all,
It's different imho because my proposal is that, outside the "XWiki" space,
only users would create new spaces, never the applications directly without first asking
the user for a space name explicitely.
I'm wondering if it's a good idea to reserve a space for data and to have one data
subspace per app: first, along the operating system analogy, it's not very common to
store files per their application origin basis, is it, or is the analogy irrelevant?
Second, the line between what we call "data" and "content" is getting
more and more blurry (the Jupyter notebooks, just like XWiki are good examples of this),
so the user may end up with page hierarchies that are difficult to understand.
Regarding the "XWiki" space, we probably agree that it is meant to be a
"system" space, do we? If that's the case, I'm wondering if storing the
users and groups in that space is the best option, because they are actually writable
data. It's a bit specific since they are transversal, and their classes come with the
platform, but it remains writable data. Their code could be located in the XWiki space,
but the instances could be elsewhere, in a configurable location. Also, prefixing each
user and group page with "XWiki" may not please all developers imho: imagine you
develop a Facebook like, should the user wall URLs contain "XWiki"? It's
always possible to add URL rewriting rules, but that's more complex. The underlying
reason could be brand marketing though, which is important.
Following up on the operating system analogy, we could also consider log files (and
possibly other aspects?). Even though most of the XWiki logs are currently stored on the
file system, that could be interesting at some point to store some of them directly in the
wiki for easing their archiving and consultation, couldn't it? In that case, we could
also reserve a dedicated root space for them. Having very few top level reserved spaces
such as "Logs", "Users", "Groups" (provided their name is
configurable, also for localization reasons) might be acceptable, what do you think?
This looks powerful, I'm looking into it.
Cheers
Stéphane
Hi Stephane and all,
The default implementation I would propose would consist in creating data in the space
from which the creation request occurs. Do you foresee some issues with that behaviour? If
needed, we could add a field in the TemplateProvider class that would accept a script
letting developers or users implement any rule for determining which space should be used.
By "this would work only if the app provides a template", do you mean a
TemplateProvider? Would this be then that TemplateProviders are not considered as a best
practice already?
On 7 Aug 2019, at 14:22, Stéphane Laurière
<slauriere(a)xwiki.com> wrote:
Hi everyone,
I'm following up on a thread started in 2015 about the best practices regarding app
pages organization:
- https://xwiki.markmail.org/message/657vcm6ylkz4yytc
- https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…
In this thread, the idea of introducing a dedicated common root area for all application
technical pages was suggested by Denis:
https://xwiki.markmail.org/message/kk5l3dwjmpfelkzp
I'm wondering why this idea was not pushed further (it's not strictly
incompatible with the current best practices, but most of the recent applications have
their top level area, except a few like Notifications or ChartJS).
Indeed, right now, the best practice is a top level space named after the app
(https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…).
I guess the reason we didn’t do anything else is because we lacked an agreed proposal
simply.
Comparing with how other platforms do is
inspirational (Microsoft Windows "Program Files" was mentioned in the thread).
On Debian, the Maven package is installed in /usr/share/maven/ while files used and
produced by Maven can be located anywhere. Along the same line, I would see as a userand
developer experience improvement if we had the following structure:
1) Code:
XWiki
|- MyApp
|- MyAppClass
|- MyAppSheet
|- …
I don’t think it’s a good idea to put the apps directlyunder the XWiki space. I feel it
would be better to have an “Applications” subspace as in:
XWiki
|_ Applications
|_ MyApp
|_ …
|_ Users
|_ …
This allows to put other things in the XWiki space, such as users for example.
Note that for me the main reason to avoid putting spaces at the root isto avoid using up
namespaces that can then no longer be used by users. In this spirit the minimum we could
do is reserve only the “XWiki” space.
2) Data: the pages created by MyApp could then
typically be located bydefault in a MyApp space at the root of the wiki, the user could
howeverchoose which default space to use, or leave it empty (then the space from where the
user fires the create action could be used, for instance, or any scriptable rule).
Why not. I’m just not sure I would mix app data pages with purecontent pages and use up
namespaces at the root (you end up with the same issue as I mentioned above and you
below). I agree that data pages shouldn’t go in the /XWiki/Applications space though which
should be readonly.
So there are some other options:
* In /XWiki/Data/MyApp
* Reserve another namespace entry at the root (“Data”):/Data/MyApp
You said " the user could however choose which default space to use”. How would you
plan to implement this? Right now, this would work only if the app provides a template and
the user uses this template to create a new page. For example the FAQ app doesn’t do that
and it provides a UI to create a new FAQ entry and this goes in /FAQ/ directly. Another issue
I see with the current practice (raised by Clément A. orally) is that some application
names may conflict with names the user would like to use for content that is not strictly
related to the app. Not necessarily a big deal with one thousand of applications, but
might become one with more, wouldn't it?
Sure and you get the same issue with your proposal of putting app data at the root under
/MyApp, no? I understand
that the layout proposed above would raise technical issues (XWiki space permissions for
instance, mentionned in the 2015 thread, and others), however what's your view on it
from a design perspective? (sorry if I overlooked strong arguments already expressed
against it)
Thanks for starting this thread again.
One other point missing in this discussion is the migration from the current status to
any target. How would we achieve it? How do we migrate anapp to follow any new best
practice without breaking users? (Idea:
https://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases). Let’s start the discussion ;)
Thanks
-Vincent
--
Stéphane Laurière
XWiki – https://xwiki.com
Cheers
Stéphane
2:26 p.m.
Hi Stephane,
It's different imho because my proposal is that, outside the "XWiki" space,
only users would create new spaces, never the applications directly without first asking
the user for a space name explicitely.
I'm wondering if it's a good idea to reserve a space for data and to have one
data subspace per app: first, along the operating system analogy, it's not very common
to store files per their application origin basis, is it, or is the analogy irrelevant?
On Windows at least this concept exists as you have 2 locations:
* Location for app code
* Location for app data
And then users created directories and folders for their own data.
It’s the same for all OSes AFAIK. On unix, you get /var/… for app data.
This looks powerful, I'm looking into it.
Cheers
Stéphane
On 22 Aug 2019, at 09:39, Stéphane Laurière
<slauriere(a)xwiki.com> wrote:
Hi Vincent, Hi all,
Yes, having data scattered eveyrwhere in the wiki instead of in a single place.
And have data saved in places you don’t want because you’re not paying attention to the
location you’re at.
This then makes it very hard to remove all data, move it to somewhere else, put
permissions on them, etc. Any bulk action becomes hard and requires scripting.
Hi Stephane and all,
The default implementation I would propose would consist in creating data in the space
from which the creation request occurs. Do you foresee some issues with that behaviour?
On 7 Aug 2019, at 14:22, Stéphane Laurière
<slauriere(a)xwiki.com> wrote:
Hi everyone,
I'm following up on a thread started in 2015 about the best practices regarding app
pages organization:
- https://xwiki.markmail.org/message/657vcm6ylkz4yytc
- https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…
In this thread, the idea of introducing a dedicated common root area for all application
technical pages was suggested by Denis:
https://xwiki.markmail.org/message/kk5l3dwjmpfelkzp
I'm wondering why this idea was not pushed further (it's not strictly
incompatible with the current best practices, but most of the recent applications have
their top level area, except a few like Notifications or ChartJS).
Indeed, right
now, the best practice is a top level space named after the app
(https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…).
I guess the reason we didn’t do anything else is because we lacked an agreed proposal
simply.
Comparing with how other platforms do is
inspirational (Microsoft Windows "Program Files" was mentioned in the thread).
On Debian, the Maven package is installed in /usr/share/maven/ while files used and
produced by Maven can be located anywhere. Along the same line, I would see as a userand
developer experience improvement if we had the following structure:
1) Code:
XWiki
|- MyApp
|- MyAppClass
|- MyAppSheet
|- …
I don’t think it’s a good idea to put the apps directlyunder the XWiki
space. I feel it would be better to have an “Applications” subspace as in:
XWiki
|_ Applications
|_ MyApp
|_ …
|_ Users
|_ …
This allows to put other things in the XWiki space, such as users for example.
Note that for me the main reason to avoid putting spaces at the root isto avoid using up
namespaces that can then no longer be used by users. In this spirit the minimum we could
do is reserve only the “XWiki” space.
2) Data: the pages created by MyApp could then
typically be located bydefault in a MyApp space at the root of the wiki, the user could
howeverchoose which default space to use, or leave it empty (then the space from where the
user fires the create action could be used, for instance, or any scriptable rule).
Why not. I’m just not sure I would mix app data pages with purecontent pages and use up
namespaces at the root (you end up with the same issue as I mentioned above and you
below). I agree that data pages shouldn’t go in the /XWiki/Applications space though which
should be readonly.
So there are some other options:
* In /XWiki/Data/MyApp
* Reserve another namespace entry at the root (“Data”):/Data/MyApp
You said " the user could however choose which default space to use”. How would you
plan to implement this? Right now, this would work only if the app provides a template and
the user uses this template to create a new page. For example the FAQ app doesn’t do that
and it provides a UI to create a new FAQ entry and this goes in /FAQ/ directly. If needed, we could add a field in the
TemplateProvider class that would accept a script letting developers or users implement
any rule for determining which space should be used. By "this would work only if the
app provides a template", do you mean a TemplateProvider? Would this be then that
TemplateProviders are not considered as a best practice already?
As you said it’s a best practice only not something mandatory. For example the FAQ app
doesn’t provide a template provider right now and even if it did, it still has a UI to
create new entries. So that would also need to be removed. Is that good or bad, I don’t
know for sure. It has both pros and cons.
Another
issue I see with the current practice (raised by Clément A. orally) is that some
application names may conflict with names the user would like to use for content that is
not strictly related to the app. Not necessarily a big deal with one thousand of
applications, but might become one with more, wouldn't it?
Sure and you get the
same issue with your proposal of putting app data at the root under /MyApp, no? Second, the line between what we call "data"
and "content" is getting more and more blurry (the Jupyter notebooks, just like
XWiki are good examples of this), so the user may end up with page hierarchies that are
difficult to understand.
I don’t know what Jupyter notebooks are but what I know is that mixing apps with content
is hard for users and thus it would make sense to me to have a location for app data that
is separate by default from pure content created by users. This has been asked countless
times and we’re doing hacks to try to spearate them (for ex, see the Applications Panel
and the Navigation Panels).
Regarding the "XWiki" space, we probably agree that it is meant to be a
"system" space, do we?
Yes.
If that's the case, I'm wondering if storing
the users and groups in that space is the best option, because they are actually writable
data.
Sure. We could consider users as app data for the User App. And thus put them in the User
app data location for example.
It's a bit specific since they are transversal,
and their classes come with the platform, but it remains writable data. Their code could
be located in the XWiki space, but the instances could be elsewhere, in a configurable
location. Also, prefixing each user and group page with "XWiki" may not please
all developers imho
This is a different topic. The goal here is to have a user/group API independent of the
implementation and storing users and groups in the wiki would be just one implementation.
This means slome mapping between user/group id and storage location.
: imagine you develop a Facebook like, should the user
wall URLs contain "XWiki"? It's always possible to add URL rewriting rules,
but that's more complex. The underlying reason could be brand marketing though, which
is important.
Following up on the operating system analogy, we could also consider log files (and
possibly other aspects?). Even though most of the XWiki logs are currently stored on the
file system, that could be interesting at some point to store some of them directly in the
wiki for easing their archiving and consultation, couldn't it? In that case, we could
also reserve a dedicated root space for them. Having very few top level reserved spaces
such as "Logs", "Users", "Groups" (provided their name is
configurable, also for localization reasons) might be acceptable, what do you think?
I think I would prefer just 2 top level: “XWiki” and “App Data”. Regarding logs they could
be considered as app data from a System app for example.
Interesting discussion, more feedback needed too :)
Thanks
-Vincent
I
understand that the layout proposed above would raise technical issues (XWiki space
permissions for instance, mentionned in the 2015 thread, and others), however what's
your view on it from a design perspective? (sorry if I overlooked strong arguments already
expressed against it)
Thanks for starting this thread again.
One other point missing in this discussion is the migration from the current status to
any target. How would we achieve it? How do we migrate anapp to follow any new best
practice without breaking users? (Idea:
https://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases). Let’s start the discussion ;)
Thanks
-Vincent
>
> Cheers
>
> Stéphane
>
--
Stéphane Laurière
XWiki – https://xwiki.com
3:44 p.m.
FTR I’ve discussed with Stephane verbally and Stephane will send a new mail with 3-4
questions we’ve identified.
Thanks
-Vincent
On 22 Aug 2019, at 14:26, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Stephane,
It's different imho because my proposal is that, outside the "XWiki" space,
only users would create new spaces, never the applications directly without first asking
the user for a space name explicitely.
I'm wondering if it's a good idea to reserve a space for data and to have one
data subspace per app: first, along the operating system analogy, it's not very common
to store files per their application origin basis, is it, or is the analogy irrelevant?
On Windows at least this concept exists as you have 2 locations:
* Location for app code
* Location for app data
And then users created directories and folders for their own data.
It’s the same for all OSes AFAIK. On unix, you get /var/… for app data.
On 22 Aug 2019, at 09:39, Stéphane Laurière
<slauriere(a)xwiki.com> wrote:
Hi Vincent, Hi all,
Yes, having data scattered eveyrwhere in the wiki instead of in a single place.
And have data saved in places you don’t want because you’re not paying attention to the
location you’re at.
This then makes it very hard to remove all data, move it to somewhere else, put
permissions on them, etc. Any bulk action becomes hard and requires scripting.
Hi Stephane and all,
The default implementation I would propose would consist in creating data in the space
from which the creation request occurs. Do you foresee some issues with that behaviour?
On 7 Aug 2019, at 14:22, Stéphane Laurière
<slauriere(a)xwiki.com> wrote:
Hi everyone,
I'm following up on a thread started in 2015 about the best practices regarding app
pages organization:
- https://xwiki.markmail.org/message/657vcm6ylkz4yytc
- https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…
In this thread, the idea of introducing a dedicated common root area for all application
technical pages was suggested by Denis:
https://xwiki.markmail.org/message/kk5l3dwjmpfelkzp
I'm wondering why this idea was not pushed further (it's not strictly
incompatible with the current best practices, but most of the recent applications have
their top level area, except a few like Notifications or ChartJS).
Indeed, right
now, the best practice is a top level space named after the app
(https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr…).
I guess the reason we didn’t do anything else is because we lacked an agreed proposal
simply.
Comparing with how other platforms do is
inspirational (Microsoft Windows "Program Files" was mentioned in the thread).
On Debian, the Maven package is installed in /usr/share/maven/ while files used and
produced by Maven can be located anywhere. Along the same line, I would see as a userand
developer experience improvement if we had the following structure:
1) Code:
XWiki
|- MyApp
|- MyAppClass
|- MyAppSheet
|- …
I don’t think it’s a good idea to put the apps directlyunder the XWiki space.
I feel it would be better to have an “Applications” subspace as in:
XWiki
|_ Applications
|_ MyApp
|_ …
|_ Users
|_ …
This allows to put other things in the XWiki space, such as users for example.
Note that for me the main reason to avoid putting spaces at the root isto avoid using up
namespaces that can then no longer be used by users. In this spirit the minimum we could
do is reserve only the “XWiki” space.
2) Data: the pages created by MyApp could then
typically be located bydefault in a MyApp space at the root of the wiki, the user could
howeverchoose which default space to use, or leave it empty (then the space from where the
user fires the create action could be used, for instance, or any scriptable rule).
Why not. I’m just not sure I would mix app data pages with purecontent pages and use up
namespaces at the root (you end up with the same issue as I mentioned above and you
below). I agree that data pages shouldn’t go in the /XWiki/Applications space though which
should be readonly.
So there are some other options:
* In /XWiki/Data/MyApp
* Reserve another namespace entry at the root (“Data”):/Data/MyApp
You said " the user could however choose which default space to use”. How would you
plan to implement this? Right now, this would work only if the app provides a template and
the user uses this template to create a new page. For example the FAQ app doesn’t do that
and it provides a UI to create a new FAQ entry and this goes in /FAQ/ directly. If needed, we could add a field in the
TemplateProvider class that would accept a script letting developers or users implement
any rule for determining which space should be used. By "this would work only if the
app provides a template", do you mean a TemplateProvider? Would this be then that
TemplateProviders are not considered as a best practice already?
As you said it’s a best practice only not something mandatory. For example the FAQ app
doesn’t provide a template provider right now and even if it did, it still has a UI to
create new entries. So that would also need to be removed. Is that good or bad, I don’t
know for sure. It has both pros and cons.
Another
issue I see with the current practice (raised by Clément A. orally) is that some
application names may conflict with names the user would like to use for content that is
not strictly related to the app. Not necessarily a big deal with one thousand of
applications, but might become one with more, wouldn't it?
Sure and you get the
same issue with your proposal of putting app data at the root under /MyApp, no? Second, the line between what we call
"data" and "content" is getting more and more blurry (the Jupyter
notebooks, just like XWiki are good examples of this), so the user may end up with page
hierarchies that are difficult to understand.
I don’t know what Jupyter notebooks are but what I know is that mixing apps with content
is hard for users and thus it would make sense to me to have a location for app data that
is separate by default from pure content created by users. This has been asked countless
times and we’re doing hacks to try to spearate them (for ex, see the Applications Panel
and the Navigation Panels).
Regarding the "XWiki" space, we probably agree that it is meant to be a
"system" space, do we?
Yes.
If that's the case, I'm wondering if
storing the users and groups in that space is the best option, because they are actually
writable data.
Sure. We could consider users as app data for the User App. And thus put them in the User
app data location for example.
It's a bit specific since they are
transversal, and their classes come with the platform, but it remains writable data. Their
code could be located in the XWiki space, but the instances could be elsewhere, in a
configurable location. Also, prefixing each user and group page with "XWiki" may
not please all developers imho
This is a different topic. The goal here is to have a user/group API independent of the
implementation and storing users and groups in the wiki would be just one implementation.
This means slome mapping between user/group id and storage location.
: imagine you develop a Facebook like, should the
user wall URLs contain "XWiki"? It's always possible to add URL rewriting
rules, but that's more complex. The underlying reason could be brand marketing though,
which is important.
Following up on the operating system analogy, we could also consider log files (and
possibly other aspects?). Even though most of the XWiki logs are currently stored on the
file system, that could be interesting at some point to store some of them directly in the
wiki for easing their archiving and consultation, couldn't it? In that case, we could
also reserve a dedicated root space for them. Having very few top level reserved spaces
such as "Logs", "Users", "Groups" (provided their name is
configurable, also for localization reasons) might be acceptable, what do you think?
I think I would prefer just 2 top level: “XWiki” and “App Data”. Regarding logs they
could be considered as app data from a System app for example.
Interesting discussion, more feedback needed too :)
Thanks
-Vincent
>
>>> I understand that the layout proposed above would raise technical issues
(XWiki space permissions for instance, mentionned in the 2015 thread, and others), however
what's your view on it from a design perspective? (sorry if I overlooked strong
arguments already expressed against it)
>> Thanks for starting this thread again.
>> One other point missing in this discussion is the migration from the current
status to any target. How would we achieve it? How do we migrate anapp to follow any new
best practice without breaking users? (Idea:
https://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases).
>
> This looks powerful, I'm looking into it.
>
> Cheers
>
> Stéphane
>
>
>> Let’s start the discussion ;)
>> Thanks
>> -Vincent
>>>
>>> Cheers
>>>
>>> Stéphane
>>>
>
>
> --
> Stéphane Laurière
> XWiki – https://xwiki.com
1844
days inactive
1859
days old
4 comments
2 participants
participants (2)
-
Stéphane Laurière -
Vincent Massol