Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

CalendarDev

From TYPO3Wiki
Jump to: navigation, search

Introduction

The initial goal of the team working on this new calendar extension is to create flexible, robust base for a calendar that other extensions can build on. This base calendar will provide the framework necessary for extensible input and output in the calendar. On the input side, calendar data can come from extensions that use TYPO3's database, from static files such as iCal, or from any other data source that PHP can connect to. On the output side, calendar views will be equally extensible with HTML, iCal, and RSS output all well within the realm of possibility.

The underlying design pattern that provides this extensiblity is the Model-View-Controller (MVC) Pattern. In the MVC pattern, the model provides an object-based representation of our calendar data, but has nothing to do with the display of that data. It is here that the various input sources can hook in and populate our model. At the opposite end is the view, which is responsible for outputting data to the user. This view has no notion of the underlying storage mechanism (database, file system, etc); it only knows how to draw events and has no logic built into it. Sitting in between the two and controlling the traffic between each, is the controller. The controller serves as the main entry point from TYPO3 into the calendar base, and based on paramters passed to its functions, retrieves certain events from the model and passes those events along to the view. The model and the view never interact directly; the controller sits in the middle to direct traffic between the two.

The ultimate goal for the base calendar is a clean archicture that other extensions can plug into to display calendar data. Currently, the extension repository has many different extension for displaying calendar events, online event registration, conferences, etc with a great deal of duplicated functionality and no real way of showing combined data from the extensions. Through the design and development of a base calendar architecture, our goal is to provide future extension developers an easy mechanism to get data on one global calendar.

Currently we're looking at possible designs for this calendar base and welcome any input. Feel free to join the discussions here on the wiki or in the typo3.projects.calendar newsgroup on news://news.typo3.org.

Current developers

Here's a list of current developers of Calendar:

  • Mario Matzulla <mario dot melanie at arcor dot de>
  • Stefan Kreisberg <stefan at linkfactory dot dk>
  • Jeff Segars <jeff at webempoweredchurch dot org>
  • Stig Nørgaard Færch <stig at 8620 dot dk>
  • Carlos Chiari <ccho at dimension-e dot net>
  • Alexander Langer <alex at big dot endian dot de> (calendar)
  • Herbert Roider <herbert dot roider at utanet dot at> (calendar_ext)
  • Robert Markula <robert dot markula at gmx dot net>
  • Christopher Torgalson <bedlamhotel at gmail dot com>
  • Troels Kjaer Rasmussen <troelsr at msn dot com>

Developer TODO list

  • Defining project goals
  • Roadmap
    • Create a common calendar-API
    • Select development base
    • Implement missing functions

Design Ideas

Design #1 (Robert Markula)

 ==========================
| 1. USER INTERFACE LAYER  |
 ==========================
    (UI Layer Interface)
 ==========================
| 2. CALENDAR "CORE"       |      ========
| - Core Module 1          | --- | 4. API |
| - Core Module 2          |      ========
| - ...                    |
 ==========================
  (Data storage interface)
 ==========================
| 3. DATA STORAGE LAYER    |
|  |     |      |     |    |
| DBAL  ICAL   CSV   ...   |
 ==========================

There are three different Layers that are fully independent of each other:

  1. (a) The User Interface for the frontend (template-based)
    (b) The User Interface for the backend modules
  2. The core consists of the core itself (which provides only the abolutely necessary functions) and various modules which are fully independent from each other. One module would take care of event creation, another one would be responsible for event registration etc. Additional modules could be easily hooked into the core.
  3. All storage/import/export interactions happen via the data storage layer. The core doesn't know about DBAL, ICAL, PDF etc. but only knows the calls to the data storage layer. This layer is the one who cares for the correct translation of data to the database (DBAL), to ical, csv, xml, pdf and whatever.
  4. The API is the interface to other extensions.

All Layers interact with each other exclusively via interfaces. So they only have to know the calls to their interface; and the interface is responsible for the correct translation to the other layers. The benefit is this: Let's assume, all data is stored in the database by default. Now someone wants to store this data in an xml-file instead. All he would have to do is modify the data storage layer and flip the right switch via TS. All other layers (Core and UI) wouldn't need to know anything about this, as their interface calls are still the same.

Design #2 (Jeff Segars)

 ====================   ===========
| 1. Standard Views  | | 7. Custom |
|    Day, Week, etc  | |    Views  |
 ====================   ===========

 ===============    ================
| 2. Controller |--| Simple API     |
|               |  |                |
 ===============    ================

 ==========================================
| 3.  Abstract Model / API                 |
 ==========================================
       |                |             |
 =============   ==============   =========
| 4. Base     | | 5. Event     | | 6. iCal |
|    Calendar | | Registration | |    etc  |
 =============   ==============   =========
       |                |             |
 ==============================   =========
|     Datababase               | |  File   |
|                              | |  System |
 ==============================   =========  
  1. The standard views will come from the base calendar extension and provide the basic views for day, week, month, etc. They'll get a predefined set of data from the controller and display that data in the same way regardless of what external extension it comes from.
  2. The controller is the main entry point into the extension from the rest of TYPO3 (the equivalent of the current pi1->main function). It will read data in a standard model format and pass it along to whatever view has been chosen.
    As Robert suggested in his example, this would also be a good point for an API to fit in. If we're hooking in an API here, my preference would be for it to be a very simple API to display a single point of time on a calendar. This could be used by extension that aren't really calendar related but might want to display calendar information (ie. a monthly archive of tt_news postings).
  3. The abstract model is where I view a more full blown API living. Rather than implementing it as functions, my thought is that we could implement it as an abstract object: basically skeletons for methods that a calendar object should provide as well as actual, fleshed-out methods for functions that are duplicated among all calendars.
  4. From this abstract object model, we can then create a set of base calendar functionality that is roughly equivalent to existing calendars today.
  5. In addition to a model for a base calendar, we can also use the Visitor pattern or mimic the TYPO3 concept of services to allow other extensions (event registration, etc) to implement our abstract model.
  6. Our model would not have to be limited to TYPO3 database-based extension either. An extension could be written that implemented our abstract model, but instead of reading from a database, it could pull an external iCal file into our calendar model.
  7. I'm a little out of order now, but I'll jump back up into the view. Since we have the possiblity for models that provide very different information, we also need a method for these models to be displayed differently. For the typical day and week views, a default for all extensions is probably fine but a single event view should definitely have the possiblity of being specific to what model the data is coming from.
  8. I'm still a little unsure on the best way to accomplish this. We can either have extensions implement a very simple, abstract view in addition to the abstract model, or we can simply link to a separate single view of the extensions output from the standard views (day, week, etc.) I lean toward implementing both: use links in conjunction with the simple API for existing extension and use a custom view object for extensions with custom models.