Hi John, Sounds good to me. Think of Timeline as a reporting mechanism. So first you have a standard CRUD dbms system, then add on an output method that produces the xml or json file (a report) that your Timeline or Timeplot page will consume.
You should also look into Exhibit which enables much more filtering and display options out of the box. Projects have also been completed which use Google docs spreadsheets to hold the data. That way you can use Google as your crud system. You could also use a db crud builder such as Dabble or FormAssembly to gather your data. Or SurveyMonkey. Or lots of other choices. Then build a much smaller piece of sw to handle the data extraction and reformatting into a form that can be consumed by Timeline, Timeplot or Exhibit. I suggest JSON since you are writing the extract sw. It's much more compact than xml, so uses less time for sending down the wire. It's also much faster to parse. If you want, you can also include Javascript date object declarations (see the Timeline wiki) instead of date strings that then have to be parsed by the browser. At that point your data format is no longer valid JSON, but that may not be a concern compared with the speed advantage. I haven't tried Timeplot lately so I don't know as much about it. Regards, Larry On Oct 30, 12:56 pm, callahan <[EMAIL PROTECTED]> wrote: > I starting a couple of projects where I hope to use TimeLine and > TimePlot. Our goal is to have users contribute to the database > through an online interface. One thought was to create a webform that > allows users to enter data into a database (MySQL) then write a script > (probably PHP or Python) that queries the database and returns XML or > JSON data (not sure which is best) to the eventsource of the time* > object. > > For single events, this should be easy since all you need to capture > is date/range, title, and description. For time series data, it would > take more work since a dataset (csv, xls, tab files) would need to > uploaded and parsed before going into the database. In any case, > we'd need to work with authentication, editing submitted data, quality > assurance, and similar issues. > > Has anyone done this before? Are there any obvious pitfalls (database > schema, performance lag) that are known? Does this approach make > sense? Thanks for any help you can provide. > > - John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
