Re: [xwiki-devs] [Iteration][UX] Nested: Livetable

See below. On 03/07/2015 09:56, vincent(a)massol.net wrote: > Hi Jean, > > See below > > On 2 Jul 2015 at 15:43:56, Jean SIMARD > (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote: > >> This is an interesting example. Let's get back a few seconds on the >> first mail of this thread. The topic was about how to integrate the >> nested concept into LT. If I paraphrase what I understand: how to >> display the complete path to a document in a LT (list of all spaces from >> ROOT to the document). But in this example (LT of extensions), the path >> is not an interesting information. I don't really care where this page >> is stored into the wiki (and I guess, you don't too, right?). What's >> important is the name of the extension, the category and a few other >> information. >> >> So maybe the real question is: do we care about displaying "path" of a >> document in a LT? (and not, do we care to keep LT like I first said). >> It's still a bit fuzzy in my head but this is how I think about that at >> the moment: path is a technical information (therefore, useless for the >> end-user), but title of the page, category, author, etc. are meaningful >> information to the end-user. Does it make any sense to you? >> >> Trying to imagine some use cases where this path is useful to the >> end-user (and not just technical), I got some (see below) but as you'll >> see, I'm not sure it should be the way to implement them: >> >> 1) Using Task Manager Application with Project Management Application, >> you could store all tasks of a project into a subspace (therefore the >> name of the subspace could be the name of the project >> 1.problem) Title of the project is probably already a field into the >> Project Management AWM and what you really want in the LT is this title, >> not the name of the sub-space (sub-space is only a technical solution to >> store tasks without colliding between projects) >> >> 2) With Blog Application, you store articles in a hierarchy of >> year/month/day. >> 2.problem) Indeed, the date is useful information but here again, I >> guess that you can already get the date from the document itself and >> therefore, it's only a technical solution for storage which is not very >> useful to the end-user. >> >> Can you think about a real use case where you need this path? (I guess >> my brain is already to biased on the topic so help me!!!). > > You need this path for all use cases actually since this is the only way > you can identify the document name or title you’re looking at. If you > have a document with the “Team” title, how do you know what it means? Is > this the HR Team, the Product Team, the Research Team, etc. The only way > to identify a document is by looking at its path.

I don't understand. If these Team documents are different documents, even if the document name (not title) is the same (only the path differs), they will have different objects and/or have same objects (with different values in properties) and/or different titles. It is these information that you want to display in order to differentiate the lines in your livetable. If these document are exactly the same, I don't see the point to have clones of documents in a wiki (ok, it could happen but I don't feel like we should support this use case).

-- Jean Simard