Hi, On Thu, Jun 25, 2015 at 11:59 AM, [email protected] <[email protected]> wrote:
> Hi Marius and all, > > On 25 Jun 2015 at 08:19:22, Marius Dumitru Florea ( > [email protected](mailto:[email protected])) > wrote: > > [snip] > > > >> 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.) > > > > > > > > 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. > > > > 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. > 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-Documents-td7594966.html#a7595203 > > WDYT? > > [snip] > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
