Hello
I took the ideas from the other timelne widget, but rewrote the code nicely from scratch. So there's a mini thing to play with, but it's not really working very well as it's retrieving to much information for too many timebands. (I tied it in to our database but we need to make a few adjustments which we couldn't have made on the previous timeline):
We seem to have lots and lots of "timelines" (roughly 80). I assume we can consolidate some, right? Some of them only have a few events (2-10) on them? At the moment I'm creating one timeband per different timeline in the spreadsheet. With 80 timebands, each having a different scale/unit, that's a lot of things to render on the web page. It's also rather big vertically (imagine 80 sections of 50-100px each!)
Do we want to consolidate as one big timeline for each geographical location? Or time period? One of the benefits of having re-written the timeline widget from scratch in our own way is that we can now use different colours within a time band and can have multiple timebands (with different scales) on our one widget.
(when I say scale or unit, i mean the vertical sections/lines that break up the horizontal band so that you know how much time a section of the band is representing).
I enhanced the retrieval to only retrieve and render those bits that the user can see, including the scale, so that as you scroll it adds the new vertical sections on the timeline dynamically. This needs to be taken slightly further. For example, we don't want to put a request in to the server every time something is scrolled by one pixel. We need to be more sensible about that.
And secondly, we need to call the server only for the bit that we're scrolling, as opposed to all of the visible part of the timeline = i.e. if we've asked for events 2AD - 12AD before, we don't to be asking for events 1AD to 11AD, we want to be intelligent and ask for events 1AD to 2AD. The reason for this is because otherwise, messages between server and client can be huge, and take a long time to parse on the client side.
At the same time I've also raised a query on the GWT forum about a potential bug in the DateTimeFormat GWT object. We may need to write our own DateTimeFormatter. Without that of course, we can't display times very easily on the part of the timeband that displays the unit, nor generally in event popups and so on.
Cheers
Chris
Chris, this sounds fantastic - far more than I would have expected you could extract out of a timeline written for a rather different purpose.
Is there anything we can play with?
David IB
At 15:22 29/11/2009, Chris Burrell wrote:
Heya
For the graphics thing, we'd still need to get all the graphics done at several zoom levels. And then do all the logic from picture to picture, zoom to zoom, etc.
I've worked a bit more on the timeline stuff and have a working model. I just need to add a few things to it and tie it to the database, but it will be capable of:
- hiding bands
- hiding events
- filtering by event ids
- filtering by event description
- moving events from one band to another
- different scales for different time bands
- drawing across timebands (eventually, if we want to map the path of Israel)
- Gradual Zoom in/out
- highlights of one band on another (for example, highlighting the visible timeline A on a zoomed out timeline B)
- etc.
At the moment, it does the most complicated stuff:
- scrolling across time
- setting the scales
- adding events
- adding bands
- displaying events as point in time
- displaying events as durations
- scrolling at different speeds across different timelines (taking account of the scale of each timeband)
- showing the scale on each timeband (optional)
--
Posted By Tyndale STEP Project to Tyndale STEP - Programming on 12/02/2009 08:50:00 AM
No comments:
Post a Comment