DayBackForFileMaker

How It Works

DayBackForFileMaker.HowItWorks History

Hide minor edits - Show changes to output

May 19, 2023, at 04:33 PM by 192.88.134.15 -
November 13, 2017, at 08:38 PM by 192.88.134.15 -
Changed line 29 from:
This also means that DayBack will eventually be able to work with other backends in addition 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.
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.
April 11, 2017, at 06:33 PM by 192.88.134.15 -
Added lines 22-23:

%newwin% [[https://youtu.be/Kh-lilixLQA]]
Changed lines 7-12 from:
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 [[CSS | editing it's 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 it's [[filters]] directly without diving into that find script.

Finally, any edits you make are passed back into FileMaker as regular FileMaker script calls. So you can edit the way DayBack behaves by editing the FileMaker scripts instead of the JavaScript. In fact, if you have FileMaker Advanced, you can use the calendar with the script debuger on and see which scripts are being called, just as if it was a "regular" FileMaker layout.
to:
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 [[CSS | 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.

Finally, any edits you make are passed back into FileMaker as regular FileMaker script calls. So you can edit the way DayBack behaves by editing the FileMaker scripts instead of the JavaScript. In fact, if you have FileMaker Advanced, you can use the calendar with the Script Debugger on and see which scripts are being called, just as if it were a "regular" FileMaker layout.
Changed line 15 from:
FileMaker is great at many things, but very complicated layouts (like grids and calendars) can be tough to build and even ore difficult to maintain. By putting the layout difficulties off on to html, we more the display difficulties off to a framework more forgiving of 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.
to:
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.
Added lines 20-25:

For more on why we chose JavaScript and why we think this is good news for developers modifying our calendar, check this out:

(:youtube Kh-lilixLQA width=500:)

!! The Future
Changed line 25 from:
%center% Learn more about FileMaker and JavaScript \\ on our blog: %newwin% [[https://www.seedcode.com/tag/javascript/ | seedcode.com/javascript]]
to:
%center% Learn more about FileMaker and JavaScript on our blog: %newwin% [[https://www.seedcode.com/tag/javascript/ | seedcode.com/javascript]]
Changed line 25 from:
%center% Learn more about FileMaker and JavaScript \\on our blog: %newwin% [[https://www.seedcode.com/tag/javascript/ | seedcode.com/javascript]]
to:
%center% Learn more about FileMaker and JavaScript \\ on our blog: %newwin% [[https://www.seedcode.com/tag/javascript/ | seedcode.com/javascript]]
Changed line 25 from:
%center% Learn more about FileMaker and JavaScript on our blog: %newwin% [[https://www.seedcode.com/tag/javascript/ | seedcode.com/javascript]]
to:
%center% Learn more about FileMaker and JavaScript \\on our blog: %newwin% [[https://www.seedcode.com/tag/javascript/ | seedcode.com/javascript]]
Changed lines 23-25 from:
We're very excited about the possibilities: [[https://www.seedcode.com/newsletter-signup/ | stay tuned]].
to:
We're very excited about the possibilities: [[https://www.seedcode.com/newsletter-signup/ | stay tuned]].

%center% Learn more about FileMaker and JavaScript on our blog: %newwin% [[https://www.seedcode.com/tag/javascript/ | seedcode.com/javascript]]
Changed lines 7-8 from:
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 off the calendar by [[CSS | editing it's CSS]].
to:
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 [[CSS | editing it's CSS]].
Added lines 12-23:

!! Why JavaScript?

FileMaker is great at many things, but very complicated layouts (like grids and calendars) can be tough to build and even ore difficult to maintain. By putting the layout difficulties off on to html, we more the display difficulties off to a framework more forgiving of 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.

With JavaScript we also get to include behaviors that we've only been able to approximate in our native FileMaker layouts: things like sliding drawers and drag-and-drop finally feel completely native... because they ''are'' native in JavaScript.

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 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: [[https://www.seedcode.com/newsletter-signup/ | stay tuned]].
Changed lines 9-11 from:
The
to:
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 it's [[filters]] directly without diving into that find script.

Finally, any edits you make are passed back into FileMaker as regular FileMaker script calls. So you can edit the way DayBack behaves by editing the FileMaker scripts instead of the JavaScript. In fact, if you have FileMaker Advanced, you can use the calendar with the script debuger on and see which scripts are being called, just as if it was a "regular" FileMaker layout.
Changed line 5 from:
%center% %width=200% [[https://angularjs.org/ | https://angularjs.org/img/AngularJS-large.png]]
to:
%center% %width=300% [[https://angularjs.org/ | https://angularjs.org/img/AngularJS-large.png]]
Changed line 5 from:
%center% %width=400% [[https://angularjs.org/ | https://angularjs.org/img/AngularJS-large.png]]
to:
%center% %width=200% [[https://angularjs.org/ | https://angularjs.org/img/AngularJS-large.png]]
Changed line 5 from:
%center% %width=400px% [[https://angularjs.org/ | https://angularjs.org/img/AngularJS-large.png]]
to:
%center% %width=400% [[https://angularjs.org/ | https://angularjs.org/img/AngularJS-large.png]]
Changed line 5 from:
https://angularjs.org/img/AngularJS-large.png
to:
%center% %width=400px% [[https://angularjs.org/ | https://angularjs.org/img/AngularJS-large.png]]
Changed lines 1-13 from:
!! So with no relationship between the calendar and the events table, how exactly does this work?

Check out the following chart...

%center% %width=500px% https://www.seedcode.com/rootimages/stikipad/nextcal/howitworks.png

-> '''1.''' SQL queries find
the relevant day/week/month records and write them to a global variable. Additional scripts then look at this variable and make a couple more variables out of it so it is easier for other scripts read: variables like $$sc_ArrayContent.

-> '''2.''' The calendar layout then shows portal rows from
the CalendarRows table to draw the day/week/month grid.

-> '''3.''' Finally, calcs in
the CalendarRows table look at our global variables for any events on that day and display the relevant content.

The idea here is that no matter how many "cells" we have to draw, the calendar only fetches data from FileMaker Server once, making this '''much''' faster than calendars based on multiple portals.
to:
!! With no relationship between the calendar and the events table, how exactly does this work?

The calendar interface is drawn in a webviewer, so all the things that would normally make up the layout (the buttons, columns, and portals) are rendered in HTML, CSS, and JavaScript. (The particular flavor of JavaScript being used is [[https://angularjs.org/ | AngularJS]].)

https
://angularjs.org/img/AngularJS-large.png

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 off the calendar by [[CSS | editing it's CSS]].

The
April 21, 2012, at 10:39 AM by 93.95.107.10 -
Changed line 13 from:
The idea here is that no matter how many "cells" we have to draw, the calendar only fetches data from FileMaker Server twice, making this '''much''' faster than calendars based on multiple portals.
to:
The idea here is that no matter how many "cells" we have to draw, the calendar only fetches data from FileMaker Server once, making this '''much''' faster than calendars based on multiple portals.
April 21, 2012, at 10:38 AM by 93.95.107.10 -
Changed lines 7-8 from:
-> '''1.''' Scripts find the relevant day/week/month records and loop through those, writing them to a global variable. While this sounds slow, it is crazy fast. More scripts then look at this variable and make a couple more variables out of it so it is easier for other scripts read: variables like $$sc_ArrayContent.
to:
-> '''1.''' SQL queries find the relevant day/week/month records and write them to a global variable. Additional scripts then look at this variable and make a couple more variables out of it so it is easier for other scripts read: variables like $$sc_ArrayContent.
Changed line 13 from:
The idea here is that no matter how many "cells" we have to draw, the calendar only fetches data from FileMaker Server once, making this '''much''' faster than calendars based on multiple portals.
to:
The idea here is that no matter how many "cells" we have to draw, the calendar only fetches data from FileMaker Server twice, making this '''much''' faster than calendars based on multiple portals.
February 25, 2010, at 03:54 PM by 76.22.123.157 -
Changed lines 7-10 from:
-> '''1.''' Scripts find the relevant day/week/month records and loop through those, writing them to a global variable. While this sounds slow, this is crazy fast. More scripts then look at this variable and make a couple more variables out of it so it is easier to read, variables like $$sc_ArrayContent.

-> '''2.''' The calendar layout shows portal rows from the CalendarRows table to draw the day/week/month grid.
to:
-> '''1.''' Scripts find the relevant day/week/month records and loop through those, writing them to a global variable. While this sounds slow, it is crazy fast. More scripts then look at this variable and make a couple more variables out of it so it is easier for other scripts read: variables like $$sc_ArrayContent.

-> '''2.''' The calendar layout then shows portal rows from the CalendarRows table to draw the day/week/month grid.
February 25, 2010, at 03:51 PM by 76.22.123.157 -
Changed line 13 from:
The idea here is that no matter how many "cells" we have to draw, the calendar only fetches data from FileMaker Server once.
to:
The idea here is that no matter how many "cells" we have to draw, the calendar only fetches data from FileMaker Server once, making this '''much''' faster than calendars based on multiple portals.
February 21, 2010, at 02:27 AM by 76.22.123.157 -
Changed lines 7-12 from:
'''1.''' Scripts find the relevant day/week/month records and loop through those, writing them to a global variable. While this sounds slow, this is crazy fast. More scripts then look at this variable and make a couple more variables out of it so it is easier to read, variables like $$sc_ArrayContent.

'''2.''' The calendar layout shows portal rows from the CalendarRows table to draw the day/week/month grid.

'''3.''' Finally, calcs in the CalendarRows table look at our global variables for any events on that day and display the relevant content.
to:
-> '''1.''' Scripts find the relevant day/week/month records and loop through those, writing them to a global variable. While this sounds slow, this is crazy fast. More scripts then look at this variable and make a couple more variables out of it so it is easier to read, variables like $$sc_ArrayContent.

-> '''2.''' The calendar layout shows portal rows from the CalendarRows table to draw the day/week/month grid.

-> '''3.''' Finally, calcs in the CalendarRows table look at our global variables for any events on that day and display the relevant content.
(855) SEEDCODE
[email protected]
Follow us: