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

[Martijn Pieters]

> -----Original Message-----
> From: Shalabh Chaturvedi [mailto:shalabh@pspl.co.in]
> 
> From: Martijn Pieters <mj@digicool.com>
> 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.)

And a little bit further on in his email:
> 
> 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 problem here is that the server will get unnecessarily flooded with
requests for RDF data that is not visible in the tree anymore, when
restoring the tree in a later session.

I believe that the idea is very good, especially from a caching point of
view. But we have to make sure that we don't persist any more
datasources than we have to. Here's my idea:

Every time a user opens up a branch, the new datasource gets added to a
JavaScript dictionary (to use a Python term). We could maybe avoid
adding the datasource to the tree when already in the dictionary, but
this makes no difference to Mozilla right now. If it already has a
datasource loaded, it won't do so again.

Now, when a user closes a branch, we remove the datasource name _only
from the dictionary_. And when the window is closed, we persist the
dictionary. On reopening the window, the dictionary is populated with
the persisted data, and we add all these datasources to the tree again.

I'll go and implement this today.

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

If you remove the 'container="true"' attribute, the above hack is not
necessary, as Mozilla will find out whether or not they are empty by
itself.

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

I know, but it would be wise to choose a possible URL anyway, for future
extensions. I think it'd be better to use a valid RDF Schema here. One
reason is the Last Modified date. Mozilla has support for a RDF Date
Literal, used in the bookmarks RDF for example. There is no support for
them in XML RDF Datasources yet, pending the work on XML Schemas, which
in turn will take RDF Schemas into account. In all likelihood, to be
able to support Date literals in XML RDF Datasources, we'll need a valid
RDF Schema.

I propose to use the following URL:

  http://www.zope.org/Resources/Mozilla/RDF

So the namespace will be something like:

 xmlns:zope="http://www.zope.org/Resources/Mozilla/RDF#"

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

Agreed.

Let's get cracking!

-- 
Martijn Pieters, Software Engineer 
| Digital Creations http://www.digicool.com 
| Creators of Zope      http://www.zope.org 
| mailto:mj@digicool.com       ICQ: 4532236
| PGP:
http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 
-------------------------------------------