On Thu, Sep 17, 2015 at 12:46 PM, Guillaume Lerouge <[email protected]> wrote:
> Hi Edy,
>
> On Tue, Sep 15, 2015 at 5:10 PM, Eduard Moraru <[email protected]> wrote:
>
>> Hi Guillaume,
>>
>> You propose a single top level/root document, but no top level space. How
>> does that fit into XWiki`s model? What is the reference of this root
>> document? "xwiki:.WebHome", "xwiki:.", ? How do we interact with it? Also,
>> is a random xwiki:Space.Page document supposed to be a child of this
>> implicit root document?
>>
>
> Indeed, I'm probably (widely!) underestimating the amount of work needed to
> make something like this work and the impact. The reference of the "top
> homepage" would indeed have to be something like "xwiki:." (or even just
> "[[]]"!).
>
>
>> What we currently do is that we have the Main Wiki > Current Wiki > Top
>> Level Document > Child Document > Child Document hierarchy. The link to
>> "Current Wiki" goes to whatever the homepage is configured to be. This does
>> not mean that the linked document is the parent of "Top Level Document".
>> The parent of "Top Level Document" is the wiki "Current Wiki". The homepage
>> of that wiki may be different, but that does not make the homepage document
>> a parent of the "Top Level Document".
>>
>
> Actually you have 2 hierarchies, not one:
>
> - Main Wiki > Top Level Document in the main wiki > Child Document >
> Child Document hierarchy
> - Main Wiki > Sub-Wiki > Top Level Document > Child Document > Child
> Document hierarchy
>
> Which means that there are 2 different types of entities that can live
> under "Main Wiki" => it feels to me like a bit of a consistency issue, but
> we can't really avoid it at the moment.
>
>
>> If you consider the homepage of the wiki as the parent of top level
>> documents, you will end up creating pages in the "Blog" space, as Marius
>> exemplified above, because the wiki admin wanted the "Blog" spaces (Nested
>> Document) to be the homepage for his personalized wiki.
>
>
> No, since my point of view on this is that we shouldn't even allow the home
> page to be changed to begin with :-)
>
>
>> We want to allow more configuration in contrast to requiring more
>> code/content change (which would be the alternative when enforcing a fixed
>> homepage document).
>>
>
> Why is that? Why not keep the homepage where it is and let the user put a
> {{display}} macro there if needed? I don't really understand the rationale
> behind this. Changing the content of the homepage it very easy (one click
> on the "Edit" button)...
The upgrade could become a bit more complex if you modify the default home page.
>
> I`m trying to focus more on the actual impact of this, since IMO it's
>> better to make a slight effort in understanding why something happens and,
>> once understood, you either agree with it or live with it, but in both
>> cases you don`t suffer from the side effect caused by a possible solution
>> that would be easier to understand but had an unwanted effect.
>>
>
> Actually the current behavior suits me well overall. The only gripe I have
> is with the special treatment when creating pages from the home page. You
> can see even see it: when you click on the create button from the home,
> first the parent displays "Home" then you have a quick flickering as it
> gets hidden in Javascript...
>
> Now I understand that it's better to start with less changes and add things
> only as needed. We'll see how things goes.
>
>
>> I`m curious how this turns out in practice.
>>
>
> So am I! I guess we'll see when additional user feedback start coming in :-)
>
> Best,
>
> Guillaume
>
>
>> Thanks,
>> Eduard
>>
>> On Tue, Sep 15, 2015 at 5:30 PM, Guillaume Lerouge <[email protected]>
>> wrote:
>>
>> > Hi Marius,
>> >
>> > On Tue, Sep 15, 2015 at 3:23 PM, Marius Dumitru Florea <
>> > [email protected]> wrote:
>> >
>> > > Hi Guillaume,
>> > >
>> > > On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge <
>> [email protected]>
>> > > wrote:
>> > > > Hi Caty,
>> > > >
>> > > > thanks for your message. Please see my answers below.
>> > > >
>> > > > On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) <
>> > > > [email protected]> wrote:
>> > > >
>> > > >> Hi,
>> > > >>
>> > > >> The current behavior was reached after many discussions.
>> > > >>
>> > > >
>> > > > I understand. However, I only got the time to actually try and test
>> XE
>> > > 7.2
>> > > > last week. And based on what Edy said, I'm not the only one who was
>> > > > surprised by the current behavior :-)
>> > > >
>> > > >
>> > > >> Currently the concept of main wiki is expressed as the 'home' icon,
>> > but
>> > > is
>> > > >> not tied to a particular space. This is something we preserved and
>> is
>> > > >> flexible enough for users with custom content to change the location
>> > of
>> > > the
>> > > >> homepage or assigned a different space, for a different subwiki.
>> > > >>
>> > > >
>> > > > I understand this. I'm not questioning the current behavior, but the
>> > > > underlying assumption. Given the new paradigm we're implementing with
>> > > > nested spaces, why would an user want to change the location of the
>> > > > homepage? To me, it's like saying that you would want the top level
>> > > folder
>> > > > on your computer to be something else than the hard drive itself. I
>> > don't
>> > > > understand why that would be useful.
>> > >
>> > > The hard-drive is the wiki not the Main space. Or, if you want to be
>> > > precise, the entire farm is the hard-drive, a wiki is a partition on
>> > > that hard-drive and a space is a folder on a partition. The Main space
>> > > is just one of the top level "folders". Blog, XWiki, Sandbox are also
>> > > at the top level. And you can create new top level "folders". When you
>> > > access XWiki you get redirected to the Main space by default but
>> > > someone may want the Blog space to be opened by default.
>> > >
>> > > >
>> > > > Do you have specific use cases in mind that I might be missing (other
>> > > than
>> > > > "this feature existed before")?
>> > > >
>> > > > Also we needed to showcase differently spaces that are top level, vs.
>> > > pages
>> > > >> inside the Main space, while having the limited number of exceptions
>> > > >> created for the breadcrumb.
>> > > >>
>> > > >
>> > > > I think there are 2 separate problems here:
>> > > >
>> > >
>> > > > 1. Where should we put all of the pages that are currently in the
>> > > "Main"
>> > > > space if we decide that not all of them deserve to be top-level
>> > pages
>> > >
>> > > Pages from the Main space are not top level. Main is top level, and
>> > > Main is on the same level with Blog, Sandbox and XWiki. Check the
>> > > document index tree. I have the feeling you're making a confusion.
>> > >
>> >
>> > I am making an intentional confusion because I think that this is how
>> > end-users are going to perceive it too. I think I understand well enough
>> > XWiki's current model, the reason why there's a Main space to begin with
>> > and the fact that it's just a space among others, not a top-level space
>> by
>> > itself.
>> >
>> > However, we cannot expect that level of implicit knowledge from a fresh
>> new
>> > user. As a new user, I'm on "Main", which to me is the top level page, I
>> > create a new page, and it's created next to Main, not under it. That
>> > doesn't fit with my mental model of how nested pages should work. That
>> new
>> > page should be under Main, not at the same level. Do you see what I mean?
>> >
>> > As pointed out by Caty, I also understand that there are technical
>> > limitations that explain this behavior and that it's tough to overcome
>> them
>> > in the short amount of time that we have as part of the 7.2 release
>> > timeframe. We'll most likely have to keep the current behavior and live
>> > with it for a while. But I know for sure that it is going to create
>> > confusion for some end users, the same way it did for me :-)
>> >
>> > Thanks,
>> >
>> > Guillaume
>> >
>> > > 2. Making it possible to have top-level pages in a coherent manner
>> > > >
>> > > > For 1., pages in the Main space could stay where they are for now.
>> > "Main"
>> > > > would be the legacy space where we put useful tools for the
>> management
>> > of
>> > > > your wiki.
>> > > >
>> > > > I'm discussing the answer for 2. below.
>> > > >
>> > > > Also I wouldn't like that all the URL contain the word 'Main' Imagine
>> > > that
>> > > >> besides the 'xwiki/bin/view/' we would need to also contain the
>> > homepage
>> > > >> space?
>> > > >
>> > > >
>> > > > My very point is that the home page wouldn't (shouldn't?) need to be
>> > > > "Main". It would be "". IE, there would be nothing in the URL to
>> > reflect
>> > > > it. It would be a representation of the wiki itself.
>> > > >
>> > > > I understand that technically this is not feasible right now and that
>> > we
>> > > > *need* to have a specific page be the home page, which is the role
>> > played
>> > > > by Main.WebHome. What I'm saying is that with the new system, I'd
>> > rather
>> > > > have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be
>> the
>> > > > whole wiki. That level would be the top level space (which is exactly
>> > > what
>> > > > has been implemented by the way). Do you see what I mean?
>> > > >
>> > > >
>> > > >> Although we have a convention that a certain page is displayed as
>> > > >> homepage, this is not needed to be in the URL. 'home' icon is a link
>> > for
>> > > >> the homepage, not a physical location. Currently the 'Main' space
>> can
>> > > >> contain pages useful for the display of the homepage, but is an
>> > > 'optional'
>> > > >> space.
>> > > >>
>> > > >
>> > > > What I' suggesting is precisely that the home page be its own
>> document
>> > at
>> > > > the very top of the hierarchy, ABOVE what is currently known as
>> > > > Main.WebHome. This is why while the user is on this page, she should
>> > see
>> > > > only the home icon.
>> > > >
>> > > > Is this making what I mean clearer? I'm just suggesting we push
>> things
>> > > one
>> > > > step further in the direction that has already been established.
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Guillaume
>> > > >
>> > > > Thanks,
>> > > >> Caty
>> > > >>
>> > > >> On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge <
>> > > [email protected]>
>> > > >> wrote:
>> > > >>
>> > > >> > Hi Edy,
>> > > >> >
>> > > >> > thanks for the explanation. Please see my feedback below.
>> > > >> >
>> > > >> > On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <
>> > [email protected]>
>> > > >> > wrote:
>> > > >> >
>> > > >> > > Hi,
>> > > >> > >
>> > > >> > > Yes, "this is not a bug, it's a feature!" :) I had documented it
>> > in
>> > > a
>> > > >> > small
>> > > >> > > paragraph [1] (see the note) but did not feel it was worthy to
>> be
>> > > >> > mentioned
>> > > >> > > in the release notes. Please feel free to rephrase if needed.
>> > > >> > >
>> > > >> > > It's not specifically about "Main", but about the current wiki's
>> > > >> homepage
>> > > >> > > (and "Main.WebHome" is the default homepage that can be changed
>> > from
>> > > >> > > administration).
>> > > >> > >
>> > > >> >
>> > > >> > Does this feature (changing the home page) still makes sense in
>> the
>> > > >> context
>> > > >> > of nested spaces? What is the point to define the home page as
>> > > >> ".../A/B/C"
>> > > >> > when based on the new system, "C" is a sub-sub page?
>> > > >> >
>> > > >> > To me, with nested spaces the home page is always the same and
>> > cannot
>> > > be
>> > > >> > changed. You may want to add a redirect, but this doesn't change
>> the
>> > > fact
>> > > >> > that the top page is the same.
>> > > >> >
>> > > >> >
>> > > >> > > The effort is to try to avoid the situation where a regular user
>> > > lands
>> > > >> on
>> > > >> > > the homepage of the wiki (just accessed the wiki or maybe he
>> > clicked
>> > > >> the
>> > > >> > > logo) and wants to create a document. He enters the title and
>> > > presses
>> > > >> > > "create". Obviously his intention was to create a page, and,
>> more
>> > > often
>> > > >> > > than not (IMO at least), his actual intention was to create a
>> top
>> > > level
>> > > >> > > document and not a child document of the wiki's current
>> homepage.
>> > > >> > >
>> > > >> >
>> > > >> > I agree with this. However, in that case, shouldn't the home page
>> be
>> > > >> simply
>> > > >> > *https://<server>/xwiki/bin/view/* instead of
>> > > >> > *https://<server>/xwiki/bin/view/Main/* ?
>> > > >> >
>> > > >> > Using short URLs, you could even have the home page under
>> *https://
>> > > >> > <server>/
>> > > >> > *and then subpages at *https://<server>/A, **https://
>> <server>/A/B*
>> > > and
>> > > >> so
>> > > >> > on. This would be in line with what most CMS do and it would fix
>> > your
>> > > >> > issue: any page created from the home is a sub-page at the
>> expected
>> > > >> level.
>> > > >> >
>> > > >> > Image the homepage gets changed to
>> "Some.Deep.Document.As.Homepage".
>> > > >> > > Without this "trick", a regular user would end up, by mistake
>> IMO
>> > > (and
>> > > >> by
>> > > >> > > using the "next-next-next" mindset), creating the document
>> > > >> > > "Some.Deep.Document.As.Homepage.NewDocument".
>> > > >> > >
>> > > >> >
>> > > >> > As I said above, I actually think we should remove this feature in
>> > the
>> > > >> > context of nested spaces.
>> > > >> >
>> > > >> >
>> > > >> > > Even if the homepage remains the default one, I see no logical
>> > > reason
>> > > >> in
>> > > >> > > spamming all the new documents with the "Main" prefix, the
>> result
>> > > being
>> > > >> > an
>> > > >> > > artificially deeper hierarchy and longer URL.
>> > > >> > >
>> > > >> >
>> > > >> > Agreed. As mentioned above, ideally we'd remove it.
>> > > >> >
>> > > >> >
>> > > >> > > If a user really intended to create a document as a child of the
>> > > >> homepage
>> > > >> > > (rare usecase IMO), he has all the tools in the UI to simply do
>> > so.
>> > > >> > >
>> > > >> > > I agree that it's a minor consistency dent, but IMO the benefit
>> > > >> justifies
>> > > >> > > it.
>> > > >> > >
>> > > >> >
>> > > >> > I don't quite agree that it's minor. One of the implied goals of
>> > > nested
>> > > >> > spaces is to be able to have consistent URL naming (I know exactly
>> > > where
>> > > >> > page *https://<server>/A/B/C *is). Having a special case for Main
>> > > breaks
>> > > >> > this.
>> > > >> >
>> > > >> > Similarly, when on the home page on the main wiki, I don't
>> > understand
>> > > why
>> > > >> > the breadcrumb shows both the "home" icon and "Home" text. Why
>> keep
>> > > both
>> > > >> > when the icon would be enough?
>> > > >> >
>> > > >> > Thanks,
>> > > >> >
>> > > >> > Guillaume
>> > > >> >
>> > > >> > WDYT? (interested in more opinions on this since I've already had
>> 2
>> > > >> > > eyebrows raised on this topic :) )
>> > > >> > >
>> > > >> > > Thanks,
>> > > >> > > Eduard
>> > > >> > >
>> > > >> > > ---------
>> > > >> > > [1]
>> > > >> > >
>> > > >> > >
>> > > >> >
>> > > >>
>> > >
>> >
>> http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusingtheAddPageaction
>> > > >> > >
>> > > >> > > On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <
>> > > >> [email protected]>
>> > > >> > > wrote:
>> > > >> > >
>> > > >> > > > Hi Devs,
>> > > >> > > >
>> > > >> > > > I started trying out XE 7.2 (SNAPSHOT from around 12:30 today)
>> > > and I
>> > > >> > was
>> > > >> > > > very impressed, the changes look quite good!
>> > > >> > > >
>> > > >> > > > While playing with it, I had a question about how the "Main"
>> > > space is
>> > > >> > > > handled. Here's what I did: from .../xwiki/bin/view/Main/, I
>> > > clicked
>> > > >> > the
>> > > >> > > > "create" button and created a sub page, then a sub-sub page.
>> > > Here's
>> > > >> > what
>> > > >> > > I
>> > > >> > > > got:
>> > > >> > > >
>> > > >> > > > - .../xwiki/bin/view/SubPage/SubSubPage
>> > > >> > > >
>> > > >> > > > Although I was expecting this:
>> > > >> > > >
>> > > >> > > > - .../xwiki/bin/view/Main/SubPage/SubSubPage
>> > > >> > > >
>> > > >> > > > So I was wondering whether this was the expected behavior, and
>> > > >> whether
>> > > >> > it
>> > > >> > > > had been discussed before?
>> > > >> > > >
>> > > >> > > > Congrats & Thanks,
>> > > >> > > >
>> > > >> > > > Guillaume
>>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
