On 24 Aug 2015 at 13:34:29, Marius Dumitru Florea
([email protected](mailto:[email protected])) wrote:
> On Mon, Aug 24, 2015 at 1:14 PM, [email protected] wrote:
> > Hi Gaby,
> >
> > On 24 Aug 2015 at 10:02:43, Gabriela Smeria
> > ([email protected](mailto:[email protected])) wrote:
> >
> >> Hello all,
> >>
> >> The final decision for this thread will also affect Notes application,
> >> which uses Space Index macro.
> >
> > Indeed we also need to decide what to do about the {{spaceindex}} macro
> > (which lists all document in a space).
> >
>
> > IMO we should use the {{documentTree}} macro using the “root” parameter
> > instead.
>
> By replacing the live table with a tree the users won't be able to:
I’ve never suggested that we should replace a LT by a Tree! :)
I’ve said that we should replace the use of the {{spaceindex}} by
{{documentTree}}.
AFAIK Space Index Macro is not using a LT (See
http://extensions.xwiki.org/xwiki/bin/view/Extension/SpaceIndex+Macro). Am I
wrong?
Thanks
-Vincent
> * see directly the author/creator and the last modification / creation date
> * filter by page name or author
> * sort by creation / modification date
>
> I'd rather make the space index a "localized" version of the wiki
> document index, i.e. limited to a specified space (nested document).
> The user should at least be able to choose between tree view and list
> view.
>
> Thanks,
> Marius
>
> >
> > I’ve modified the title of http://jira.xwiki.org/browse/XWIKI-12362 to
> > include the Space Index macro.
> >
> > So my take is:
> >
> > * Keep those 2 macros for now for backward-compatibility reasons
> > * Just make sure they don’t break with Nested Spaces/Documents
> > * Don’t improve them and instead recommend in the documentation to use the
> > DocumentTree macro
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> >
> >> So please consider this thing too.
> >> See http://jira.xwiki.org/browse/NOTES-2. I've already thought of a
> >> solution, but the final decision from here will influence a lot the fix .
> >>
> >> Thanks,
> >> Gabriela
> >>
> >>
> >>
> >>
> >>
> >> *Gabriela Smeria*
> >> *Web Developer*
> >> [email protected]
> >> skype: smeria.gabriela
> >>
> >> On Wed, Aug 19, 2015 at 12:36 PM, Ecaterina Moraru (Valica) <
> >> [email protected]> wrote:
> >>
> >> > On Wed, Aug 19, 2015 at 11:29 AM, Marius Dumitru Florea <
> >> > [email protected]> wrote:
> >> >
> >> > > Everyone seems to agree, so far, that the spaces macro can be replaced
> >> > > by the document tree macro. We'll have to decide whether we keep this
> >> > > macro in the Index Application or we move it to contrib (so that
> >> > > anyone that wants to use it can install it). I guess we can leave it
> >> > > in the Index Application for 7.x.
> >> > >
> >> > > As for showing navigation information (i.e. the document tree) on the
> >> > > dashboard, most of you seem to find it useful. My only worry is that
> >> > > we'll provide multiple ways to do the same thing:
> >> > >
> >> > > * document index tree
> >> > > * breadcrumb tree (probably)
> >> > > * dashboard document tree
> >> > >
> >> > > Moreover, Caty's initial design of the Home page for Flamingo didn't
> >> > > include the spaces macro
> >> > > http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4xHomepage .
> >> > > There may be more important information to display on the home page
> >> > > instead of the document tree (which you can access from the Document
> >> > > Index).
> >> > >
> >> >
> >> > The focus of Flamingo proposal was not the Homepage.
> >> > I've included the macro in the proposals for Workspaces
> >> >
> >> > http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/Home.png
> >> >
> >> > http://design.xwiki.org/xwiki/bin/download/Improvements/WorkspaceHomepage/WorkspaceTech.png
> >> > with their main purpose as light navigation.
> >> >
> >> > Still these proposals are focused for the Groupware Flavor. In
> >> > documentations the Trees are very important.
> >> >
> >> > I think the breadcrumb tree will be enough for a Groupware Flavor, but we
> >> > will need to test it.
> >> >
> >> > Thanks,
> >> > Caty
> >> >
> >> >
> >> > >
> >> > > On Mon, Aug 10, 2015 at 10:59 AM, Eduard Moraru
> >> > > wrote:
> >> > > > Hi,
> >> > > >
> >> > > > IMO, we can use the document tree macro to achieve both usecases of
> >> > > > the
> >> > > > previous documents and spaces macros, so no need to have more than 1
> >> > > > navigation macro for this.
> >> > > >
> >> > > > +1 for (2)
> >> > > >
> >> > > > Re (3), we could wait and see how the tree navigation works out and,
> >> > > > if
> >> > > > users find that to be easy enough, we could eventually do (3). For
> >> > > > now
> >> > > > however, having some navigation in the dashboard is in line with the
> >> > > > "overview" nature of the dashboard itself, so I think we could keep
> >> > > > it.
> >> > > >
> >> > > > Thanks,
> >> > > > Eduard
> >> > > >
> >> > > > On Fri, Aug 7, 2015 at 3:15 PM, Gabriela Smeria <
> >> > > [email protected]>
> >> > > > wrote:
> >> > > >
> >> > > >> Hello Vincent,
> >> > > >>
> >> > > >> I'm +0 for (3), because as you said, sol5+sol6 it's more likely to
> >> > > >> be
> >> > > >> chosen, but I think this will not be sufficient. Displaying a
> >> > > >> (future)
> >> > > >> Document Tree Macro on Dashboard it will help a lot the users to
> >> > > >> find
> >> > > out
> >> > > >> where are the documents localized in the hierarchy or at least have
> >> > > >> a
> >> > > big
> >> > > >> picture about it, without entering every page and check the
> >> > breadcrumb.
> >> > > >> And they can't use the Go To functionality if they don't know
> >> > previously
> >> > > >> where the document is localized.
> >> > > >> But that's just my opinion.
> >> > > >>
> >> > > >> Thanks,
> >> > > >> Gabriela
> >> > > >>
> >> > > >> *Gabriela Smeria*
> >> > > >> *Web Developer*
> >> > > >> [email protected]
> >> > > >> skype: smeria.gabriela
> >> > > >>
> >> > > >> On Fri, Aug 7, 2015 at 12:42 PM, [email protected] <
> >> > [email protected]
> >> > > >
> >> > > >> wrote:
> >> > > >>
> >> > > >> > Hi Gaby,
> >> > > >> >
> >> > > >> > On 7 Aug 2015 at 10:40:51, Gabriela Smeria (
> >> > [email protected]
> >> > > >> > (mailto:[email protected])) wrote:
> >> > > >> >
> >> > > >> > > Hello Marius,
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > On Fri, Jun 12, 2015 at 1:30 PM, Marius Dumitru Florea <
> >> > > >> > > [email protected]> wrote:
> >> > > >> > >
> >> > > >> > > > Hi guys,
> >> > > >> > > >
> >> > > >> > > > The wiki home page displays, by default, the list of spaces
> >> > > >> > > > that
> >> > > >> exist
> >> > > >> > > > in the wiki (hidden or not, depending on the user profile
> >> > > settings).
> >> > > >> > > > This is done using the
> >> > > >> > > >
> >> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Spaces+Macro
> >> > > .
> >> > > >> As
> >> > > >> > > > we have started to work on adding support for nested
> >> > > >> spaces/documents,
> >> > > >> > > > we need to review the purpose of this macro. Is it still
> >> > relevant
> >> > > to
> >> > > >> > > > display a list of spaces when there is a tree hierarchy? It
> >> > > >> > > > only
> >> > > >> makes
> >> > > >> > > > sense if you want to display just the list of direct children
> >> > of a
> >> > > >> > > > given node.
> >> > > >> > > >
> >> > > >> > > > I see the following options:
> >> > > >> > > >
> >> > > >> > > > (1) Display the list of top level nodes (space/document) on
> >> > > >> > > > the
> >> > > wiki
> >> > > >> > > > home page. No tree. The rationale is that loading the tree
> >> > > >> > > > (even
> >> > > if
> >> > > >> > > > done lazy) is more expensive that displaying a static list of
> >> > > links.
> >> > > >> > > > For this we can extend the Spaces Macro with a parameter to
> >> > > specify
> >> > > >> > > > the parent node. When this parameter is not specified the
> >> > > >> > > > macro
> >> > > will
> >> > > >> > > > list the top level nodes. (In the context of nested documents
> >> > > >> > > > we
> >> > > >> could
> >> > > >> > > > introduce a new macro Document List instead)
> >> > > >> > > >
> >> > > >> > >
> >> > > >> > > -0 for (1), because even though it takes less time to display a
> >> > > list of
> >> > > >> > top
> >> > > >> > > level nodes, I don't think it's achieving the concept of Nested
> >> > > Spaces
> >> > > >> > > (Documents), since what will be shown it is what is shown now,
> >> > > without
> >> > > >> > the
> >> > > >> > > Nested Spaces concept implemented.
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > > (2) Display the tree hierarchy on the wiki home page, using
> >> > > >> > > >
> >> > > >> >
> >> > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro
> >> > > >> > > > .Of course, the tree will be lazy loaded, and only the top
> >> > > >> > > > level
> >> > > >> nodes
> >> > > >> > > > are displayed initially. If we do this then we can probably
> >> > > deprecate
> >> > > >> > > > the Spaces Macro and advice the users to use the Document Tree
> >> > > Macro
> >> > > >> > > > instead.
> >> > > >> > > >
> >> > > >> > >
> >> > > >> > > +1 for (2), because this is what we want in the end, to see (or
> >> > > >> > > at
> >> > > >> least
> >> > > >> > to
> >> > > >> > > have the possibility to visualize) a hierarchy of Nested Spaces
> >> > > >> > (Documents)
> >> > > >> >
> >> > > >> > See also my proposal (3) in my previous answer on this thread.
> >> > > >> >
> >> > > >> > WDYT about it?
> >> > > >> >
> >> > > >> > Thanks
> >> > > >> > -Vincent
> >> > > >> >
> >> > > >> > > > WDYT?
> >> > > >> > > >
> >> > > >> > > > Thanks,
> >> > > >> > > > Marius
> >> > > >> >
> >> > > >> > > Thanks,
> >> > > >> > > Gabriela
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
