Cascade Server Managed Calendar & Events

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:

  1. Loop through each XML file once and determine if the event is in the month and year currently on display.
  2. If the month and year were a match, push XML file data into 2 arrays—one containing the XHTML to output (such as link to the event) and the other containing the event date for later comparison as we loop through the current month displayed. This causes the script to only need to read through all the events only once.
  3. Then change the output procedure to work by popping data off the array as the script iterated through the month by comparing the current day with that of the event array’s top element. When an event is used, it is simply popped off the array until the array is empty or the end of the month reached.


  1. Posted February 3, 2011 at 12:01 pm | Permalink

    Hi, I was wondering if you could you elaborate on which PHP script you used for calendar? Was it homebrew, open source or something commercial?

    Also, I’m curious about your calendar function. From what I understand you are creating XML files that represent calendar events and then a php script parses all of the xml files to generate a list or grid type of event view…is that correct?

    Thanks for your post and thanks in advance for any further details you could provide.

  2. Posted February 8, 2011 at 10:05 am | Permalink

    The script was originally developed by the client and given to us to port into Cascade, so homebrew. You are correct about the parsing. The data is maintained by the XML configuration of each event page in Cascade (user entry). The single calling page references the script’s main include which parses each event stored in a single directory. Once each XML file is parsed and the relevant data is harvested (by month, by audience, by category, etc) the script outputs the harvested data in the specified format. The calling page uses a GET variable to determine the current view (either list or grid ) which can be switched back and forth from the same page. The use of XSLT doesn’t necessarily need to come into play if the PHP script used is made to parse around the tags that comes out of the data definition’s XML.