On 1/29/07, David Huynh <[EMAIL PROTECTED]> wrote:
> Rereading this email, I'm hearing "more flexibility" :-) Which is not
> surprising to me.
A keen attention to detail and overall perspective follows you
wherever you go, yes. :-)
> 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.
While I won't challenge that (it's what *I* need, or want, after all),
I want to stress the importance of a low deployment threshold. At the
moment, you can more or less get away with marking your data, adding
an onload init callback and having the three tags
<div id="exhibit-control-panel"></div>
<div id="exhibit-view-panel"></div>
<div id="exhibit-browse-panel"></div>
in your page somewhere, and slowly climb the customization ladder as
you're getting more familiar with Exhibit and find that you really
want to reorganize the place to better usability and call forth more
of Exhibit's true powers. It won't do terribly much (the
do-what-I-mean defaults are a bit behind, but rather promising), but
it's something, and visual, and it's much easier to dig deeper into
it, one small step at a time, once you have something that works. This
helps growing a user base.
Breaking Exhibit into smaller pieces doesn't necessarily break with
being able to cater the past default piecework of having three
components you drop somewhere; we could probably fairly easy retain
that functionality and adopt those three DOM nodes if they exist,
prepopulating them with whichever widgets they hold today, if a
forthcoming freer-form layouting model emerges. My gut feeling says it
might be a good idea.
Or at least allowing for a similarly small deployment threshold with
the new style deployment format.
> 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".
+1. Especially if we open an opt-out mode by query variable, similar
to ?bundle=false and friends, for environments where minimum namespace
clobbering is of the essence. (After all, getting your own is a mere
${myexhibit}.getDatabase() call away -- but I agree that its being
available as "database" fits the javascript-in-browsers model very
well.)
> 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.
Similarly, once Douglas Crockford's JSONRequest (RFC 4627,
http://rfc.roxen.com/4627) gets widely deployed / promoted to internet
standard, we will also overcome the JSONP hack. (I'd guess that will
happens sooner, but hopefully that we'd get browser native "database"
eventually too.)
> 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:
+1. I vigorously like this. :-)
> [...] "select ?x from ?x type Chef" [...]
>
> Thoughts?
I'm a bit curious about the query language. Were these random examples
of a possible look, some (subset of a) query language already with a
large user base in semantic web circles (or similar), or an ad-hoc
rehash of SQL? High-risk zone for bikeshed debates better kept at a
distance, but in case there is suggested reading, I'd like to get on
top of it to skim ideas I've missed out on for not keeping up with
research in the domain.
Ideally, answer that question in a mail of its own under a new
subject; it's the kind of subject that merits a thread of its own,
even in the case where it only gets a single post.
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
