[daisy] Navigation tree improvements ideas

[Marc Portier]

some random ideas on this:

Bruno Dumon wrote:
> 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.
> 

what is the advantage over allowing that group at id is not filled, and
then handle the node as described?

on the other hand, both 'separator' and 'title' seem to be not related
to anything the navigation component should actually know about?

IIUC then these are more concerned with introducing placeholders for
styling to react upon? As such, introducing them inside the
node-language seems like opening the door to an endless list of requests
for possible new-node-types?

>From this assumption I'd prefer an approach that keeps the navigation
more opaque to these kind of things:

IDEA: introduce *one* extra unspecified 'node' that just gets
transferred over in an opaque way to allow any weird thing people might
be dreaming about,

- we could of course sample it's use through providing the basic styling
effects in our default skin for the ones you mentioned above that get
introduced as

<node type="separator" />>
<node type="title" title="i18n:my-title.label" />

and would immediately allow the weirdest stuff that our navigation
component should never worry about

<node type="my-hardcoded-type">
  <my-link href="...">whatever</my-link>
  <my-link href="...">whatever</my-link>
  <my-link href="...">whatever</my-link>
  <my-link href="...">whatever</my-link>
</node>

<node type="google-search-box" />

<node type="advertisements-from-server-xyz" />

<node type="pictures-from-flickr" owner="flickraccount-name" />

<node type="headlines-from-blog" feed-url="..."/>

Hm, I think I can anticipate a response on these last referring me to
publisher-requests that should be pulling out different navtrees in
stead, while I think this is about allowing the nav-tree-editor to be
arbitrarily positioning these in his overall nav-tree, rather then him
needing to ask a more programming-type of guy to be changing
pubrequests, styling and whatnot ?


I might even get adventurous and place daisy-system links at arbitrary
positions in the nav-tree:

<node type="daisy-search-box"/>
<node type="daisy-recent-changes"/>

wdyt?
Just tell me if I'm overlooking some obvious mistakes in my reasoning...

> * 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.
> 

drooling...

> * 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)
> 

saliva hitting the floor now...

> * 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".
> 

dunno what this is about, example?
(isn't this also a complete styling/wiki-related issue?)

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

giving that 'link' nodes don't really relate to daisy (or do they?), why
not move this under my previous catch-all 'node' idea as <node
type="link"> as well?

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

as hinted in my <node> samples, I think it would be nice if people could
have typical daisy-system-links referenced from arbitrary positions in
the navigation

HTH,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo at outerthought.org                              mpo at apache.org