[daisy] Navigation tree improvements ideas

[Bruno Dumon]

On Fri, 2006-09-01 at 14:23 +0200, Marc Portier wrote:
> 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?

It's really a completely different thing with a quite different
behaviour, so I think a different tag would be more appropriate.

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

If you follow this reasoning, you could start to consider the navigation
tree as an arbitrary XML document with some tags in it that have a
special meaning. Maybe I'm stretching it a bit, though first you talk
about one generic 'node' tag and then you give an example with a
'my-link' tag nested in the generic node tag.

Still, it's an interesting idea that would offer a lot of flexibility.
Just to play the role of the conservative side, I see some issues
though:

- the navigation tree editor would not know about these new node types,
it would need to become customizable through a schema to support the
custom node types.

- possibly the navigation tree manager would need to know about the new
node types too, if the implementation of the new nodes is more
appropriate to be done over there (e.g. because they need contextualized
behaviour)

- the navigation tree becomes less standard. If something like 'title'
or 'separator' nodes are things that are useful to everyone, why not
introduce them in the navigation tree language, with their clearly
attached semantics?

- the navigation tree is an end-user tool, not a programmer's tool, so
it should stay simple.

- none of your examples are really convincing ;-) (a search box in the
middle of a navigation tree? flickr photos in the middle of a navigation
tree? The feed include is a nice idea though)

<snipped the drooling stuff/>
> > 
> > * 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?)

e.g. now to link to an extension you have to do

<link url="/daisy/mysite/ext/myextension"/>

and this could become

<link url="${mountPoint}/${contextPath}/ext/myextension"/>

How would you make this a styling issue? The link needs some way to
indicate something needs to be put in front of the URL, and it seems
like a good thing to introduce a standarised syntax for this.

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

They do relate to navigation trees, they are a common enough requirement
to have them directly inside the navigation tree language. A bit like
HTML versus XML I think?

>  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=
-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org