26 Jun
2015
26 Jun
'15
1:44 p.m.
I’ve spoken with Anca and here’s her opinion (barring any misunderstand from my part ;)):
* She mentioned we should talk about Terminal Pages (i.e. no children) vs Non Terminal
Pages, in term of terminology
* Our UI must handle Terminal Pages as well as non Terminal Pages, i.e. we need to
generify all our UIs to handle this. This is very important to Anca
* The UI to create a new page should have an advanced option to be able to create a
Terminal Page. She said she agree to link this feature to the Advanced User profile (for
now, maybe it would be interesting to have it as an option like “hidden documents” later
on).
* She said we should provide a script to let users transform their existing pages from A/B
into A/B/WebHome
* She said we probably don’t need to work on a script to convert parent/child relationship
into Nested Documents since this change could cause existing apps to not work properly and
for her this is an action that has be done manually on a per wiki basis depending on the
usage, etc.
* She said from her POV the Parent/child relationship is not used much by users on
projects she’s been on and she’s seen this used by her or other devs when building apps
and that these app will just have to be modified
* She said we should be careful to not change the structure of current apps in XE for the
moment since that could break some extensions/bookmarks. Personally I believe we shouldn’t
relocate pages in the 7.x timeframe and when we do so (in 8.x probably) we should probably
think about implementing aliases before to handle the move.
* She agrees we should move the breadcrumb/index tree/etc to use Nested Documents and not
be based on the parent/child anymore. She agrees having an option to put it back on if
needed is good enough. However the field in the DB should stay for now.
To sum up:
Q0: +1
Q1, Q1.1, Q1.1.1: +1 with the proviso of having a UI that displays as well Terminal pages
from non Terminal pages
Q1.2: +1 provided we can create terminal pages from the UI
Q2.1: +1 (but keep the parent field in the DB)
Q2.1.1: -1
Q2.1.2: +1
Q2.2: -0
Q2.2.1: -0 (not really needed in her opinion)
@Anca: please correct me if I’ve wrongly expressed what we discussed ;)
Thanks
-Vincent
On 25 Jun 2015 at 15:16:57, Eduard Moraru (enygma2002(a)gmail.com) wrote:
Hi,
On Thu, Jun 25, 2015 at 11:59 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi Marius and all,
On 25 Jun 2015 at 08:19:22, Marius Dumitru Florea (
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
wrote:
[snip]
> There are 2 questions actually:
> A) Do we want to support creating non-WebHome documents from the UI?
Since we can have extensions or scripts/code that create non-WebHome
documents, I think it would be interesting to have the ability to do so in
the UI but only for advanced users.
I think I’d be in favor of doing the following:
* When the user is an advanced user, in the Add > Page UI, have a checkbox
entitled something like “Create a page without children” and when the user
selects it and save, a document with the name entered will be created
instead of a space and a WebHome.
I`ve asked that same question 1 week ago [1] but put it more in the light
of a security issue, since one could perform a denial-of-service-like
attack or a phishing-like attack on a ND by "masking" it with a simple
document that would high-jack existing URLs.
Also, don`t forget that if for a user we can make the difference
unnoticeable, for devs it will make life harder, since they need to query
for 2 types of documents in their code. DB queries are even more sensitive
to this, when, for example, you want to get all the immediate children of a
document. They can be simple documents (documents in the space defined by
the) or ND (WebHomes of subspaces), not o mention the issues of
manipulating the space (path string) in order to get obtain this
information.
Thanks,
Eduard
[1]
http://xwiki.475771.n2.nabble.com/Proposal-Introduce-the-notion-of-Nested-D…
>> Q1. **NS vs ND in the UI**
>>
>
>> Q1.1 The majority agreed that since the final purpose are ND, we
should
>> display ND in the UI, since it
simplifies the mental model of the
user.
>> This implies removing the Space concept
from the UI.
>
> +1
>
>> Q1.1.1 A consequence is hiding the 'WebHome' name in the UI.
>
> +1
>
>>
>> Q1.2 Although the default should be ND, the question is if we want to
give
>> the option to display NS in the UI. This
would be implemented as an
>> advanced and technical option. The main problem is that we might need
to
>> provide UI alternatives for several
components (menus, create step,
etc.)
> B) Do we display differently the WebHome
documents from the
> non-WebHome documents in the UI?
I don’t think we need to display them differently, except maybe to show
that one has children while the other doesn’t have children (terminal leaf
vs node).
No comments on these questions? There are two
important use cases:
* a wiki that has custom code (Velocity/Groovy) in (non-WebHome) wiki
pages is upgraded to 7.2+ (with nested documents)
* an admin installs an extension with non-WebHome pages in XWiki 7.2+
(with nested documents)
In both cases we cannot migrate the non-WebHome pages because it will
break the code. So they have to stay. Do we show these pages in the
document index (livetable / tree)?
Yes
Note that these are not necessarily
technical (hidden) pages. They can be data pages created/managed by an
application/extension (whose code expects non-WebHome documents). Do
we display them differently than the WebHome (nested) documents?
I don’t think we need to display them differently. The only main place
where we need to show a difference IMO is in the Add Page UI: when a user
wants to create a new page under a non-WebHome document, we simply display
a warning saying that this page is a special page that cannot have children.
In other words in the documentation we say that there are 2 types of pages
in XWiki:
* Terminal pages which cannot have children. We can also explain how these
came to be historically.
* Normal pages that can have children.
The
users will ask why they can't add children to these (non-WebHome)
pages. How do we explain this to non-technical users?
Indeed, see above for an idea on how to handle this.
Moreover, since both WebHome and non-WebHome
documents must coexist,
what happens when one hides the other. E.g. an old application has
created (through code) some data page AppData.SomePage; an user sees
the "AppData" document (it's not a space anymore, it's actually
AppData.WebHome) and adds a child (nested) document with the same name
SomePage which actually creates AppData.SomePage.WebHome under the
hood.
Good point. We could add a check in the Add > Page UI to prevent this.
Now what page does the user get when he loads the
URL
/bin/view/AppData/SomePage ?
It’s up to us to decide but I guess the most logical is to get
AppData.SomePage since otherwise there would be no way to access it from
the UI.
The WebHome or the non-WebHome
(application) page? In any case, some users will not get the expected
page. Moreover, which page should be indexed by Solr, the WebHome or
the non-WebHome with the "same" name? If we index both then the users
will complain they get "duplicate" results (with possible different
highlights), and the result links will open the same document (which
one we choose to make accessible, probably the WebHome one).
I agree that we should add a check to prevent the creation of such pages
from the UI. If it’s done by script then I don’t think we should prevent it.
WDYT?
[snip]
Thanks
-Vincent