[daisy] Navigation tree improvements ideas

[Bruno Dumon]

Hi,

I'm trying to consolidate the ideas for things we would wish to do with
navigation trees but are currently not possible. The result is below.
We'll likely only implement a few of these things in the short term, but
it's good to have a view on future requirements so that these can be
considered in the current design decissions.

* a new node type: 'separator': a non-clickable node, simply rendered as
a separator line between two other nodes.

* a new node type: 'title': similar to a group node, but doesn't have an
ID of its own, hence it doesn't become part of the navigation hierarchy
path and the URL in the browser. Since this node has no ID, it is not
addressable and so even in contextualized mode it will include its
children, though collapse/expand can still work client side.

* Handling link fields in query nodes. Currently one can create a
navigation hierarchy by selecting multiple values in a query node, for
example "select $MyField, name where true". The hierarchical nodes
created by this are however always group nodes. In case the selected
field is a link field, we should create a document node instead, linking
to the document specified by the link field (if the link field would
have no value, we can fall back to the current "(blank)" group node).

Currently the query node works so that the last selected value is bound
to the document represented by the query result row (each row in the
result set of a Daisy query always corresponds to one document). In case
this last selected field is a link, it should now however link to the
document specified in the link node.

* Handling hierarchical fields in query nodes. A hierarchical field
returns a hierarchical path, i.e. values like

  Animals/Four-leggged/Dogs
  Animals/Fish
  Animals/Four-legged/Cats

So if one selects a hierarchical field, this would create a similar
hierarchy in the navigation. (again, needs to be able to cope with null
values)

* Nesting of nodes inside query nodes. Currently a query node cannot
have children. This item is about allowing any sort of node to be
embedded inside a query node. The embedded nodes will need a mechanism
to refer to the document and selected values of the current query result
row (possibly even from multiple query-node ancestors).

This will make possible doing dynamic navigation tree imports based on a
query, nested queries, or nested link nodes whereby the href of the link
can be customised by the values selected in the query.

[ When nesting query nodes within query nodes one will need to be aware
of performance issues: executing a query which returns 100 results is
nothing special, but if then a 100 subqueries need to be executed,
things can quickly become heavy. ]

When nesting nodes inside a query node, it will likely be the case that
the parent query node will select multiple values, and with the current
implementation this would mean the query node would use all these values
to create a navigation hierarchy. Hence we need some way of telling the
query node not to do that. This could be done by having a new property
on the query node that tells how many of the selected values should be
used by the query node itself to create nodes. It should be possible
that this property is zero, so that the query node itself does not
create any nodes at all.

What I'm leaving out from this current discussion is the exact syntax to
be used to reference values from a query node. It should however have
the possibility to encode (format) values for use in the where clause of
a Daisy query (i.e. format as string, date, number, ...), or to
uri-encode them for use in link-href parameters. Possibly this could use
the syntax from the PropertyResolver class.

* Make it possible to use a "mount point" or "base path" variable in
link nodes. Currently to create link nodes to e.g. extensions URLs one
needs to use absolute paths like "/daisy/...". The mount point variable
would remove this hardcoded path.

Actually we need two mount point variables:
 - one for the global mount point
 - one for the site

I'd like to keep the navigation manager free from Daisy Wiki concepts
like sites, so the second one could be name e.g. "contextPath".

* New attributes for link nodes:
    - target: to open the link in a new window/frame/...
    - method: get or post

That's it. Comments on the above are welcome, as well as other
navigation feature wishes in order to complete the picture.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org