[Zope-Moz] ANNOUNCE: Zope management tree in Mozilla

[Shalabh Chaturvedi]

From: Martijn Pieters <mj@digicool.com>
> > From: Shalabh Chaturvedi [mailto:shalabh@pspl.co.in]
> >
>          <snipped>
>
> > I think there are some design issues with the way it is now, though.
> > Please look at my comments:
> > http://www.zope.org/Members/shalabh/Mozilla/zide/underthehood
> > if you haven't already. They're towards the end of the page.
> >
>
> I'll list them here, together with other comments, and give my thoughts.
> I'll use 'tree view' for the left hand view (which is displaying a
> tree), and 'detail view' about the right hand side.
>
> 1. Two datasources with overlap:
>
> I have thought about this one as well. We might run into trouble
> persisting the tree (storing state across sessions) though. If we use a
> separate datasource to avoid duplication of RDF data, we'd have to make
> the tree an aggregate of all these datasources, adding datasources as we
> go.
>                             <snipped>
>
> If we use an aggregation of datasources to build up the tree, we'd have
> to:
>  - Add datasources on opening of a treeitem.
>  - Remove datasources on closing (so they are not needlessly loaded when
> opening a new session).
>  - Persist the list of datasources to make sure that all data for the
> visible part of the tree is available.

I hadn't thought about persistence yet - which is a major issue. Otherwise, I
already have a something like the above (almost) done. What I have here uses
contents.rdf for the tree-view generation too. It starts off with the root
contents.rdf as the only datasource and as the user expands treeitems, other
contents.rdfs get added as datasources to the tree-view. It doesn't remove any
datasources on collapse right now. If you were to collapse and expand any
item, it would make an unnecessary call to 'AddDataSource' and add a
datasource again - (this seems to work ok but probably isn't the way it should
be done. There could be a list of 'loaded' datasources (in a javasript array,
for example) that we maintain and avoid unnecessary loads.)

An unrelated small functionality I've put in is a zp:Empty attibute in the RDF
which is set to "true" <dtml-if tpValues>. It is used in the XUL so that
twisties are shown only for non-empty treeitems.

I think we can do without removing the datasources on closing treeitems. Once
the user has expanded a tree item, we can let the corresponding contents.rdf
remain a datasource.

We have the persistence problem and I'll experiment here to look for a
solution. We may not remove datasources on collapse but we do not need to
persist all the loaded datasources across sessions.

> The last one might be the tricky bit, I am not sure if this will be
> possible. If you can't persist the datasources attribute of the tree,
> we'd have to copy the URIs of the datasources into an attribute of our
> own, and have Mozilla persist this attribute. This means that we will
> have to have JavaScript maintain this list, as we can't get it from the
> tree itself, the current API doesn't give us any means of obtaining it.
> For an example of the JavaScript trick, have a look at the onUnload code
> of the bookmarks window
> (chrome/bookmarks/content/default/bookmarks(.xul|.js). Paul: this XUL
> file also shows double-click detection in JavaScript).
>
> A point against multiple datasources for the tree view: Right now, the
> tree is perceived as fast, because all data is in memory. When using
> separate datasources, Mozilla will fetch every datasource separately,
> each time you expand an item. Mozilla does not use any caching at the
> moment, as soon as all references to a datasource are removed, the
> datasource is discarded.

This problem goes away if we choose not to unload a datasource every time a
treeitem is collapsed. This will cause some delay only the first time a tree
is expanded. Since the details-view also uses the same set of datasources
(.../contents.rdf) though one at a time an not aggregrate, this mechanism will
also provide caching for the details-view datasources. The tree-view would
always contain a reference to all the datasources corresponding to treeitems
opened at least once.
There will be occasional requirements to reload or refresh a datasource. Once
a refresh is done on one source, it would affect the both the tree-view and
details-view as it is common.

> 2. Style sheet for the icons.
>
>                <snipped>
>
> For now, I'll stick with my method of specifying the icon URL in the
> RDF. The icon URL seems to be highly specific to the object in question.

Seems fine. There isn't much point to keeping id to icon mappings in a CSS (I
was hoping icons map one-to-one onto metatypes, so we could use a stylesheet
for type to icon mappings).

> 3. Refreshing datasources
>
>                 <snipped>
>
> >
> > This brings out another point - we would need our own namespace. I
> > suggest you come up with any url under www.zope.org that we
> > can use as a
> > namespace uri. We can then define elements which dont exist in the
> > Dublin Core, RDF and others.
> >
>
> Of course. Right now, Mozilla does not check for the existence of the
> URL, it is just a unique identifier.

I don't think it even has to be a valid 'URL'. Any URI would also do. So a
string like 'zope:rdf#' should be valid too, and remain valid.

> We should use standard namespaces as much as possible though, so that
> Zope RDF data can be integrated into other datasources as well.
>
> Along this line: I chose Dublin Core names for many properties, but they
> are not really appropriate. Dublin Core is intended for library card
> type data, the real meaning of the property names I used does not
> overlap with what they mean in my little RDF hack. Anyone have better
> ideas on this?

I feel we should use standard namespaces only for properties which _mean_ the
same within and outside the zope context. There isn't much that overlaps. All
the more reason to start defining a zope namespace.


>                                          <snipped>
>
> For now, while we are still in the experimental phase, I'll collect all
> experiments into one codebase. In future we will have to move to a
> Python Product and separate Mozilla chrome package however, and these
> can reside in the CVS.

Fine. There is a lot more investigation and experimentation required (at least
on my side ;-)

~Shalabh