Initial commit
Merge branch 'master' of https://github.com/zepheira/exhibit3
removing old readme
missing local variable declaration was causing collision with global
"item" variable in IE
Merge pull request #1 from karger/2013-02-25_local_var

missing local variable decl was causing collision with global "item" var in IE
A regression lost ISO8601 date conversion in google spreadsheet converter.
Also fixed a comma that was breaking IE.
Merge pull request #2 from karger/2013-03-07_dateTime

A regression lost ISO8601 date conversion in google spreadsheet converter
global replace .attr("class") with .addClass to preserve preexisting classes
Modified viewpanel to render views inside the tags that specify them.

Previously, views were rendered in a separately created
"view container" that was not a child of the tag specifying the view.
Thus, attributes specified on the view tag (e.g. classes for styling)
would not apply to the rendered view.  Which made it more difficult
for an author to style those views.  In the new version, the view
container is placed inside the tag that specified the view.

If the selected view was defined programmatically, rather than by a
tag, then the view container is placed as an immediate child of the
view panel tag.

This new approach is still imperfect.  To render a view,
the viewpanel empties the target div, which destroys contextual
information such as lenses intended for the view.  For standalone
views this is ok, as the view is rendered only once.  However, the
viewpanel re-creates a view each time that view is selected; the
second rendering will no longer have the context.  To circumvent this
problem, a new div is created inside the view tag to hold the rendered
view.  Thus, when it is emptied for the next rendering, the remaining
content of the view tag is undisturbed.

On the downside, this means that standalone views render in a slightly
different way than views in viewpanels---those in viewpanels are
nested inside a view container that is not present in standalone
views.  However, this is still a significant improvement over the previous
approach, where the rendered view was not inside the viewtag at all.

Longer-term, it seems beneficial for every view to render its content
inside a newly-created, nested view container div.  This would
provide consistency while still shielding the rendering and the
original specification-content of the view tag from each other.
bugfixed history mechanism

eraseState was pushing an invalid empty state
and viewPanel constructor was trying to switch to historic state
index, even if no view with that index actually exists.
Merge pull request #3 from karger/2013-03-16_addClass

glob replace .attr("class") with .addClass to preserve preexisting classes
Merge pull request #5 from karger/2013-03-17_bugfix_history

bugfixed history mechanism
Bugfix: wasn't adding a slot for newly created view
Bug: getURLWithoutQueryAndHash wrong if url's ? and # in wrong order
Bad hack to fix history system on ie9 and other old browsers.
The history mechanism is currently failing in ie9.

In particular, in ie9 the "statechange" event is not being triggered
when it should be (facet selection, viewpanel changes).  I have
therefore introduced the following hack: modified exhibit's
"statelistener" to also listen for the more old-fashioned "hashchange"
event.  However, to prevent "double counting", if a statechange event
is ever fired, then the listener for the hashchange event is turned off.

I've introduced the hack because I don't understand enough about the
history library jquery is using to make a more correct fixed.

The problem appears to be rooted in jquery.history.js , a library
for history management that is included in exhibit
(http://github.com/browserstate/history.js).  This library purports to
offer a uniform approach to history management on browsers both new
(which use the html5 "statechange" event) and old (which rely on an
older mechanism that tracks state view a fragment identifier in the url,
and a "hashchange" event that is triggered when the fragment changes).

Apparently the history library provides emulation, triggering the
"statechange" event even on old browsers.  This allows applications to
uniformly rely on the statechange event, even on old browsers.  Which
is what exhibit does: it rerenders whenever a statechange event is
triggered.

Except, it doesn't seem to be working as intended with exhibit on ie9.
ie9 is an old browser, so html4 emulation is used.  In the file
history.html4.js, the pushstate function engages in some mysterious
logic as it decides whether or not to actually trigger the statechange
event.  In particular, when invoked as a result of exhibit calling
pushstate,  it tests for (newStateHash !== html4Hash &&
newStateHash !== History.getShortUrl(document.location.href)) and,
finding this test to be satisfied, returns early without triggering
the statechange event.  I have been unable to find any documentation
of jquery.history.js, so am unable to determine whether this is a bug
in jquery.history.js or expected behavior/a bug in exhibit.
Merge branch '2013-03-24_urls' of github.com:karger/exhibit
Merge pull request #7 from karger/2013-07-24_bugfix_hack_history

Hack to fix history mechanism in ie9
Merge pull request #4 from karger/2012-03-17_view-panel

Modified viewpanel to render views inside the tags that specify them.
Adding tick/tock scripts for performance measuring
Modified databases index to use constant-time instead of
worst-case-linear time statement insertion.  Added a demo in demo
directory "big" that can be used to test performance of other loaders.

The details: exhibit was using an index data structure that lets you
look up values given an subject and property "key" pair.  It was
implemented as a two level map: a hashmap matched each subject to a
hashmap on each property, so the value-set for a given subject and
property was index[subject][property].  However, the value set itself
was stored as an *array*.  As a result, inserting a new value
into the value set required scanning the entire array to make sure it
was not already there, which took linear time in the number of
values.

This was generally fine for indexing the "forward" direction of
statements, because the number of values associated with a given item
and property tended to be small.  But we also indexed the reverse
direction which is much worse.  For example, every item is given type
"Item" by default.  Which means a statement <x "type" "item"> was
indexed for every x.  Which is fine in the forward direction since
there is only a single value.  But we also index the reverse statment,
which has "type" as the subject and a value set consisting of every
single item, which had to be scanned (fruitlessly) on each new item
insert.

So by default, data loading took quadratic time.

The use of an array might conceivably offer storage/performance
benefits, but in exhibit all access to the contents is through methods
that imediately copy the array into a set (hashmap), removing those
benefits.