[Zope-CVS] CVS: Packages/Moztop/moztop/content/lib - datasourcemanager.js:1.1

[Paul Everitt]

Update of /cvs-repository/Packages/Moztop/moztop/content/lib
In directory cvs.zope.org:/tmp/cvs-serv25578/lib

Added Files:
	datasourcemanager.js 
Log Message:
Welcome to refactoring

=== Added File Packages/Moztop/moztop/content/lib/datasourcemanager.js ===
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*- */

function DataSourceManager () {

    /* A prototype to manage the sites database and datasources */

    /*  The constructor is responsible for ....  */

  this.dcns = "http://www.purl.org/dc/1.1#";
  this.oscomrdfns = "http://www.oscom.org/rdf#";
  this.ncns ="http://home.netscape.com/NC-rdf#";

  this.titleprop = this.dcns + "title";
  this.descriptionprop = this.dcns + "description";
  this.resourcetypeprop = this.oscomrdfns + "resourcetypes";
  this.urlprop = this.oscomrdfns + "url";
  this.contentsurlprop = this.oscomrdfns + "contentsurl";
  this.sitetypeprop = this.oscomrdfns + "sitetype";
  this.styleidprop = this.oscomrdfns + "styleid";
  this.subitemsprop = this.ncns + "subitems";
  this.elementid = 'navigation-tree';
  this.sourceurlprop = this.oscomrdfns + "sourceurl";
  this.saveurlprop = this.oscomrdfns + "saveurl";  
  this.previewurlprop = this.oscomrdfns + "previewurl"; 
  
  var twingleurl = getProfileDirURL() + 'twingle';

  // Create some default datasources
  this.datasources = new Array();

  /* These next lines will go away after switching to the array */
  this.sitesds = new RDFDataSource(twingleurl + "/sites.rdf",null);
  this.oscomtypesds = new RDFDataSource(twingleurl + "/oscomtypes.rdf",null);
  this.localsiteds = new RDFDataSource(twingleurl + "/localsite.rdf",null);


  /* Attach these (potentially empty) datasources */
  var tree=document.getElementById(this.elementid);
  tree.database.AddDataSource(this.sitesds.getRawDataSource());
  tree.database.AddDataSource(this.oscomtypesds.getRawDataSource());
  tree.database.AddDataSource(this.localsiteds.getRawDataSource());
  tree.builder.rebuild();

  dump("\nfinished add datasources and rebuilding tree");
}


DataSourceManager.prototype.initializeDatasources = 
function () 
{
    /* Called during startup to find needed datasources, 
     fetch RDF, and build tree */
    return true;
}


DataSourceManager.prototype.addDataSource = 
function (title, rsdurl, rsddom) 
{
    /*   */
    return true;
}


DataSourceManager.prototype.removeDataSource = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype.addSite = 
function (title, rsdurl, rsddom) 
{
    /* Create a new site from the information in the DOM passed in  */



    return true;
}


DataSourceManager.prototype.removeSite = function (rsdurl) 
{
    /*   */
    return true;
}


DataSourceManager.prototype.getDataSource = function (resourceurn) 
{
    /* Given a urn, find the datasource containing that resource.  For 
     sites, the urn is the urn of the root node, whose value is the 
    URL of the rdf file on the server.  For non-remote datasources, like  
    the sites.rdf in the profile dir, the root node urn is concocted. */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}


DataSourceManager.prototype. = function () 
{
    /*   */
    return true;
}



/*  ------------    Utility functions below   ------------- */

function getProfileDirURL ()
{

  // First get the directory service and query interface it to
  // nsIProperties
  var dirService = Components.
      classes['@mozilla.org/file/directory_service;1'].
      getService(Components.interfaces.nsIProperties);

  // Next get the "ProfD" property of type nsIFile from the directory
  // service, FYI this constant is defined in
  // mozilla/xpcom/io/nsAppDirectoryServiceDefs.h

  const NS_APP_USER_PROFILE_50_DIR = "ProfD";
  profileDir = dirService.get(NS_APP_USER_PROFILE_50_DIR,
	Components.interfaces.nsIFile);

  // Now that we have it we can show it's path. See nsIFile for the
  // other things you that can be done with profileDir

	var io_service =
	Components.classes["@mozilla.org/network/io-service;1"].
	getService(Components.interfaces.nsIIOService);
   
  var url = io_service.newFileURI(profileDir)
     .QueryInterface(Components.interfaces.nsIFileURL);
   
  return url.spec;
}


/* 

Email with requirements


From: Paul Everitt <paul@zope-europe.org>
Date: Jeu mars 20, 2003  10:59:44 Europe/Paris
To: Stephan Richter <stephan.richter@tufts.edu>
Subject: DISCUSS: Proposal from last night's discussion


Clearly we need to write down something and agree to it, before jumping into code or doing checkins.  Below is a statement of the problem and the beginning of a proposal to solve it.

I haven't gone too far into writing an API yet, as we should agree on this part first.

--Paul


Summary

Moztop needs to manage the RDF datasources associated with each remote
Zope site.  This proposal covers the responsibilities needed by this
component and a proposed implementation.

Problem

The data in remote datasites is encoded in RDF and loaded as a
datasource in Moztop.  To make working with this RDF easier, we use
the RDFDataSource object from rdfds.js to provide an easier API.

However, Moztop still needs a way grab an RDFDataSource from a list of
all the datasources, as well as other operations.  Thus we need a
component that manages all the datasources.

Responsibilities

  Adding a datasource

    When the site developer adds a new Zope site to their Moztop, the
    component needs to retrieve the RDF, update the sites database,
    and update the tree.

  Reloading a datasource

    If the server data have been changed by someone other than the
    current user, then the RDF is out of date.  In this case, Moztop
    needs to reload the RDF data.  This will involve grabbing the
    datasource, retrieving the RDF, reloading the data, and
    reattaching the datasource to the tree.

    Note that this responsibility also applies when Moztop is
    restarted, thus making this responsibility a common and critical
    one.

  Removing a datasource

    If a user deletes a site, the datasource manager needs to ensure
    that the datasource is removed.  Also, when the Moztop is
    restarted, there shouldn't be a connection to the server to
    retrieve data that won't be displayed.

  Attaching a datasource to the tree

    This is a simple but common activity.  When a datasource is
    created, and also (I believe) when data have changed, the tree
    needs to be rebuilt.

    This is a visually painful process, as the tree collapses.  It
    would be interesting to find techniques to avoid this.

  Detatching a datasource

    There may be circumstances where a datasource is removed from the
    tree and removed from memory, but not permanently.  For instance,
    this might be as part of another sequence, such as reloading.

  Grabbing the appropriate datasource to make a change

    When the site developer makes a change to a resource, the RDF
    model must be updated.  While read-only operations can be made on
    the composite datasource, changes require grabbing the correct
    site datasource.

    Thus, this responsibility requires being given a resource, and
    giving back the datasource that contains that resource.

    There are other situations that require grabbing the correct
    datasource.  For instance, when a site developer selects a site
    and selects reload, the correct datasource for that site must be
    used.

  Saving a datasource

    For datasources where the RDF comes from a Zope server, there
    should be *no* circumstances under which the datasource should be
    saved.  All changes should be sent to the server, which is the
    authoritative copy of the content.  The datasource contents should
    be considered volatile.

    However, datasources such as the sites database are managed by
    Moztop in the local profile directory.  These will need to be
    flushed to disk as appropriate.

  Dumping a datasource

    When debugging, it is very important to see the contents of a
    datasource.  This responsibility can be fulfilled in a number of
    ways (using the dump command, logging something to the log
    manager, creating a visual inspector, etc.)

  Managing in-mem and remote datasources

    The classic Mozilla technique for remote datasources is to create
    a pair: a read-only datasource representing the remote content and
    an in-memory datasource where all local changes are made.  With a
    model like this, you never have to worry about losing changes when
    refreshing the remote content.

  Performing operations on all datasources

    Some of these operations will apply not just to one datasource,
    but to all datasources in the list.  For instance, dumping all
    datasource contents for debugging purposes is a very common
    activity.

Scenarios

  Site developer adds site

  Site developer deletes site

  Site developer reloads site contents

  Site developer restarts Moztop

  Site developer choses "Debug->Dump Datsources"

Proposed Architecture

  I propose an architecture where we create a JavaScript prototype
  called DataSourceManager.  It will be located in its own JavaScript
  module stored in a top-level "lib" directory.

  An instance of this called "dsm" will be declared as a global in
  moztop.js and initialized in initMoztop (which is called by
  moztop.xul as the onload action).  The initialization happens after
  the initialization of the global logging service, thus allowing dsm
  to log messages during its initialization.

  The dsm variable will be global to all scripts in the main window.
  Like the log manager, it will need to be passed explicitly to
  dialogs and wizards.

  The central architectural idea for dsm is that you "lookup" a
  datasource via a method, instead of directly accessing it via a
  property or variable.  This allows dsm to use a datasource attached
  to tree.database and return an instance of RDFDataSource.

Proposed DataSourceManager API

  constructor() -> return null

    Does this do all the work to open the sites database, retrieve all
    the remote RDF, create all the datsources, attach to tree, etc.?

*/