How It Works
With no relationship between the calendar and the events table, how exactly does this work?
This means most of the complexity of the calendar is also tucked away in the webviewer, though you can still change the look and feel of the calendar by editing its CSS.
The calendar reads your event data by performing finds and then gathering the results of it's find request up as text (the find script is "Event Find" but if you want to filter which events come into the calendar, you can edit its filters directly without diving into that find script.
FileMaker is great at many things, but very complicated layouts (like grids and calendars) can be tough to build and even more difficult to maintain. By putting the layout difficulties off on to HTML, we hand the display difficulties off to a framework better equipped to handle grids and large numbers of objects. This also means the calendar renders much more quickly in the webviewer than it does in a native FileMaker layout.
And, since we're using FileMaker as a backend, we still get to take advantage of all the great stuff that FileMaker gives us for free: calculated fields, record locking, and access privileges all work here just as you'd expect them to.
This also means that DayBack will eventually be able to work with other backends in addition to FileMaker (think about showing your Google Calendars or iCal calendars alongside your FileMaker events). It also means that we should be able to deploy the calendar outside of FileMaker layouts: running DayBack in a browser and still connecting to your FileMaker tables via FielMaker Server.
We're very excited about the possibilities: stay tuned.