[Zope-Moz] ANNOUNCE: Zope management tree in Mozilla
Martijn Pieters
mj@digicool.com
Mon, 10 Jan 2000 14:48:03 -0500
> From: Shalabh Chaturvedi [mailto:shalabh@pspl.co.in]
>
> From: Martijn Pieters <mj@digicool.com>
> > From: Shalabh Chaturvedi [mailto:shalabh@pspl.co.in]
> <snipped>
> > > I've worked more on this and produced an 'explorer-like'
> view of the
> > > Zope intallation.
> > > Here's a screenshot :
> > > http://www.zope.org/Members/shalabh/Mozilla/zide/zide.gif
> > > Get the entire thing here:
> > > http://www.zope.org/Members/shalabh/Mozilla/zide
> > >
> > > Martijn : should we merge this into your stream?
> > >
> >
> > This is perfect. With your permission, I do want to take
> your code and
> > go along this path.
>
> Sure. I hereby grant you permission ;-).
> I am an ignoramus on license issues, though - maybe you can mention if
> there are any.
>
We'll use ZPL, as Paul suggested. I see you 'agreed'. =) It means it'll
be Open Source, and we can include it in the Zope distribution, which is
probably the ultimate goal.
> 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.
Right now, the open state of every treeitem is persisted, so that next
time round, the tree is expanded exactly as it was last time. It also
takes care of the state of a subtree that is collapsed (so collapsing a
subtree doesn't mean you have to individually expand its subitems one by
one again later).
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.
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.
2. Style sheet for the icons.
I take it you switched to a style sheet for the icons because you wanted
to have the twisties visible. I solved this problem in a different way,
avoiding the (in my opinion) ugly CSS. If we were to use CSS for this,
we could also use a type attribute on the item, and use something like
treeitem[type='Folder'] > ....
to select the different items and specify their icons. This would be
feasible if there was a central registry in Zope of meta-types and their
icon URLs. I have a feeling however, that icons and metatypes do not map
one on one (the common and methods propertysheets of ZClasses don't have
a metatype for example).
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.
3. Refreshing datasources
If you use the Components.interfaces.nsIRDFRemoteDataSource interface
(http://lxr.mozilla.org/seamonkey/source/rdf/base/idl/nsIRDFRemoteDataSo
urce.idl) you can call Refresh() on the datasource to reload it.
4. Placing XUL, CSS and JS files in chrome dir.
This is, I think, something we will have to move to eventually. Zope has
to provide services for resource discovery and manipulation, but the
Mozilla interface is a separate entity. Placing the interface in the
Mozilla chrome also allows you to create a management environment for
multiple Zope servers, allowing drag and drop manipulation between Zope
servers.
> > Ideas:
> >
> > - Include a toolbar, menus and contextual menus. They don't
> have to be
> > functional yet, their just there for the idea, and to see
> what kind of
> > commands we can come up with.
>
> This one's simple.
Yes, but we also have to decide on how to communicate the contents of
the toolbar, depending on what item has been selected. It might be
necessary that Products register resource discovery methods on
initialisation, so that authors of a Product can specify what actions
can take place on objects, and what methods to call. This way not only
ZopeStudio, but also other IDEs can manipulate these objects, and
Products can in one fell swoop support multiple IDEs, including future
ones.
>
> > - The right hand side view, and the available commands for
> each object
> > should be dependant on the kind of object displayed/selected. This
> list
> > should in the future probably come from each object type itself. The
> RDF
> > for the object should next to the ID, Title, Metatype and Last
> Modified
> > date also include a seeAlso URL attribute pointing to the
> command RDF
> > structure.
>
> 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.
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?
> > If no such attribute is present, then the original HTML management
> > interface of the object should be displayed.
> >
> > - Implement double-clicking on items in the right hand side view,
> which
> > then can open new windows for showing edit views of the items.
> > Right-hand clicking and menu/toolbar options can take care of views
> like
> > permissions and properties.
> >
>
> These ideas seem to be the way to do it. Along the way we also need to
> decide what all different kinds of windows
> (edit/properties/security/custom) it would throw up and what exactly
> would they contain. Maybe we should collect all these at one place?
Many views, like the property sheets and security views should indeed be
central, but their data is object specific.
> Also, what will be the process for further code development?
Paul gave some answers to this already.
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.
--
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
-------------------------------------------