Est. Reading Time: 3 minutes
On a recent project, one of our clients requested we port over a calendar and event script built in PHP as part of their new CascadeServer site under development. The diagram below describes the flow of input (shown in yellow) and output (shown in blue) necessary for making the integration possible.
Porting the Calendar and Event application included making the input manageable from within the CMS. Using XSL formats, we were able to enforce the old XML structure used by the original PHP script. This format would transform the output of the XML generated by the data definitions used on Event pages to match the XML format the PHP script required. Users can then log into Cascade and directly add calendar events in the same way they would a standard content page. The WYSIWIG we provided is shown below. Each event is visible on the calling page in both calendar (grid) and event (list) views. When selected from either view, event information populates the page without a need to navigate from the calling page due to the the mechanics of the script. The events’ HTML configuration type is not actually used, but are still present for internal use.
On top of porting the script into Cascade, we configured the script to work with multiple websites and allow users to filter events and data by “audiences”, meaning events only relevant to that site shared from a single location. Event data was also made to include: Event title, start and end dates and times (represented also on the Calendar/grid view), locations, and descriptions. We ran into an issue of where the calendar view was taking up to a minute to load on the page. Originally, the script would loop on the days of the month to build the grid, and for each day it would check each event’s XML file to determine whether or not to output the event on that day. This was the source of the slow running time. With only 10 events across a 31 day month, the loop would need to cycle 310 times. This was sped up by doing the following: