Rereading this email, I'm hearing "more flexibility" :-) Which is not
surprising to me.
Exhibit is a different beast than Timeline, and I was in design hell
when I started writing Exhibit even after having written Timeline a few
months before. Timeline is quite self-contained: it's a rectangular box
that you drop wherever you want into your page and that's almost the end
of the story. Exhibit, on the other hand, has many parts and, thus, does
not happily want to be wrapped as a single widget, especially as a
faceted browsing widget. So perhaps we should break it into smaller pieces.
-----
The first piece to break of is the database. But there's more to just
breaking off the database. We web developers have enjoyed the presence
of the global variable "document" that lets us manipulate the document
object model and create dynamic web pages. I'm hoping that we can
introduce another global variable called "database". It will get
automatically populated with data linked from the web page and it lets
us manipulate that data through a database-like interface. For example,
you can write something like this:
<head>
<script type="text/javascript" src=".../exhibit-api.js"></script>
<link rel="data" type="rdf/json" href="my-recipes.json" />
<script>
function initialize() {
var recipes = database.getSubjects("type", "Recipe");
for (var recipe in recipes) {
...
}
var database2 = database.createDatabase();
database2.loadData("my-friends.json");
...
}
</script>
<body onload="initialize();">
...
</body>
</head>
Initially, you would need to include exhibit-api.js to get "database".
But after a while, perhaps your browser will come built-in with a native
implementation of "database". Now if "database" is built in, then it can
load data from other domains, too, and we won't need the JSONP hack.
Some interplay between the "database" on each web page and Piggy Bank is
possible.
-----
Once the database is broken off, it's more natural to break the UI off
into small pieces. It'd be nice to write small blobs of html code as
follows and place them _anywhere_ on the page:
<!-- define a collection of items -->
<div ex:role="collection"
ex:query="select ?x from ?x type Recipe"
id="recipes-collection"></div>
<!-- create a view and bind it to the collection above -->
<div ex:role="view"
ex:collection="recipes-collection"
ex:viewClass="Exhibit.TileView"></div>
<!-- create another view that will be displayed in parallel with the
first view -->
<div ex:role="view"
ex:collection="recipes-collection"
ex:viewClass="Exhibit.TimelineView"></div>
<!-- create a facet, maybe put this on the left side of the page -->
<div ex:role="facet"
ex:collection="recipes-collection"
ex:label="family"
ex:projection=".author.familyName"></div>
<!-- create another facet, maybe put it on the right side of the page -->
<div ex:role="facet"
ex:collection="recipes-collection"
ex:label="decade"
ex:projection="dateRound(.date, 'decade')"
ex:facetStyle="timeline"></div>
<!-- maybe we create another collection -->
<div ex:role="collection"
ex:query="select ?x from ?x type Chef"
id="chefs-collection"></div>
The ex:collection attributes bind views and facets to collections and
make sure everything updates itself in sync with the other parts. There
is a lot of freedom to arrange bits and pieces of the UI to suit your
need: sprinkle some facets on the left, some on the right, put 2 views
in the middle--a timeline and a tabular view, add a fixed collection at
the top that never gets filtered (e.g., "My 5 latest papers"), ...
Thoughts?
David
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
