Johan Sundström wrote:
> I have been toying a bit with loadDataFromTable and layouting some
> (past and forthcoming) events views at
>
> http://ecmanaut.googlepages.com/choir-events.html
>
> and run into something slightly ugly. In the timeline (third tab;
> pardon the Swedish - the exhibit shows public appearances of my local
> choir), the border around the element extends far outside of its
> content and into the realm of the facets I've float:right-ed to go
> next to it.
>
> The .exhibit-timelineView-timelineContainer element has the border,
> but playing in Firebug, it looks like this should work if it was
> instead put on the div classed "exhibit-timelineView-timeline
> timeline-container" instead. Should I file that as a feature request
> ticket instead of mentioning it here?
>
You can just include your own CSS rules *after* you include
exhibit-api.js to override Exhibit's styles. That's the "right" way :-)
Floats are generally nasty, especially while trying for a consistent
look across browsers...
> Anyway, the page could be interesting for other reasons, too. It
> doesn't seem to work too well with all browsers (I've only really
> tried it out well in firefox, so far), but being done as an HTML
> table, it degrades rather gracefully for Google and other visitors by
> means of loadDataFromTable.
>
Very nice! I turned off Javascript and still saw the content--that's great!
> All that functionality probably hasn't completely stabilized yet, but
> some of it could use more eyes and discussion already.
Do you want to stabilize this before locking down Exhibit 1.0 to start
on 2.0? (Yeah, I know, 2.0...)
> In its current
> form, you lay out your data like this (thead and tbody tags not
> strictly necessary):
>
> <table id="any-reference-will-do" ex:type="Something"
> ex:pluralLabel="Somethings">
> <thead><tr>
> <th ex:valueType="number">Property1</th>
> <th ex:pluralLabel="Sightings">Property2</th>
> <th>label</th>
> <th>Property4</th>
> </tr></thead>
> <tbody>
> <tr><td>1</td><td>2</td><td>Thingy</td><td>Stratford-Upon-Avon</td></tr>
> <tr><td>17</td><td>4711</td><td>Thingamajig</td><td>Gloucester</td></tr>
> </tbody>
> </table>
>
It's quite a trade-off, though. Each record, e.g.,
<tr><td>1</td><td>2</td><td>Thingy</td><td>Stratford-Upon-Avon</td></tr>
is less self-describing than its equivalent in JSON:
{ Property1: 1,
Property2: 2,
label: "Thingy",
Property4: "Stratford-Upon-Avon"
}
Adding/inserting a new property will be troublesome. But I suppose that
if the table were written in a WYSIWYG HTML editor, it'll be just like
editing a Google spreadsheet.
> and typically render the exhibit with something like
>
> var exhibit = Exhibit.create('any-reference-will-do', 'Something');
>
> My example tries to overcome having to name one of the columns "label"
> (a word which doesn't have a meaning in Swedish) using an ex:name
> property which might be a hack, but which works for the time being,
> anyway. I'm not sure that's a very pretty solution, though; other
> ideas welcome.
>
> (I havent tied in the map functionality yet, since I didn't remember
> how to do it at the time, so the final tab puts the Exhibit into an
> eternal busy state, for the time being.)
>
In the location array, replace "name" with "id". Then in the map view,
remove ex:start and ex:end and add ex:latlng="latlong". Hope that works!
David
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
