Just wanted to stick in a clarification, that "more flexibility" here primarily more _display_ flexibility. That kind of flexibility is what david huynh is demonstrating in the examples below. When it comes to computation, one of the main benefits of exhibit is its computational _inflexibililty_. Exhibit is a language for expressing how data should _look_, not what it should _be_. There will always be the temptation to add more computation to the exhibit framework to make it easier to build powerful exhibits, but that way lies javscript in tags. That kind of "computed exhibit" will be inferior to the current sort, both because it will be much harder for a novice to emulate the exhibit presentation, and because it will be harder for anyone at all to access and reuse the underlying data (which may only be materialized computationally). As we explore the evolution of exhibit we should always be asking whether a given functionality is really necessary for presentation, or whether it makes more sense to enrich the underlying data in some way that makes the added compute-at-display-time functionality unnecessary.
-David David Huynh wrote: > 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> > fun ... > </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 > > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
