The Beta 2 files have been uploaded to the Files page, for your downloading enjoyment. Currently all implemented features of the frontend and backend work, except for event submission from the frontend, which has broken since the last release and has yet to be fixed. New and improved instructions for installation are included.
A new unit testing framework has been implemented to test both the backend and frontend of the MightyCal software. It uses HttpUnit, which tests the ability to interact properly through a Web client.
In preparation for attracting more developers to the MightyCal project, I've added a Freshmeat project listing. Freshmeat.net is the primary listing site for Open Source projects. It's often the first place that people look when searching for software to download and use, or for projects to join and help.
The homepage at http://mightycal.sourceforge.net now has a link to a new Screenshots page. Also, updated API documentation has been created for the Backend... it's linked to via the homepage and the Sourceforge project page.
Beta 2 of MightyCal will be out shortly, with lots of new features. In particular, a full administration interface is implemented, web user authentication via the frontend is implemented, and a vastly improved frontend that uses the facilities of Cocoon to a much greater extent. The entire application is starting to look a lot more like a well-behaved MVC application, with the Cocoon frontend providing the View and Controller portions, and the Model implemented in the backend.
* The Cocoon frontend has been completely refactored as a separate subapplication that can be installed into an existing Cocoon installation. An Ant build script installs the MightyCal application into the main Cocoon installation.
* The new version of the Frontend has moved nearly all of the application logic into Cocoon components, by implementing custom Actions, Generators and Transformers in order to simplify the sitemap dramatically and make it more easily understandable.
* The Cocoon frontend now can handle user authentication and session tracking. The HTTP session mechanism is used to store information about the user's preferences, thereby eliminating the need to have lots of request parameters floating around and needing to be tracked.
* Moved all modules into subpackages to clarify organization. In particular, split out the ever-increasing number of constants into individual Const.py files in each of the subpackages.
* Added new security assertion methodology; a SecurityPolicy module contains a map of permissions, and every object in the MightyCal tree gets permissions as defined in this map.
* Combined all XML-related procedure calls into two entry points; the Cocoon frontend only needs to know about these two entry points to get all the information it needs from the backend.
Major refactoring done to the MightyCal internal structure. Constants have all been put into uppercase to distinguish them from variables. Many subpackages have been created to collect related modules together, thereby reducing confusion and increasing encapsulation. Also, an entirely new data entry methodology has been implemented: the DataEntryTransaction. The DataEntryTransaction has for its purpose the ability to provide a multi-stage event editing process, in particular the ability to return the user to editing an Event when the user's original entries/edits failed validation tests. When the user is returned to the data entry screen on a failed validation, the data entry screen will have full, informative error messages for each invalid field. This new DataEntryTransaction structure is user-agent agnostic... it will work whether the user is entering data via the Cocoon frontend, or whether the administrator is entering an event via the ZMI (Zope Management Interface). A user can also choose to "Save these values as defaults", so that future Event creation sessions for the same EventType will automatically be filled in using the values from the previous transaction.
New Portal-like Administrative interfaces for individual Calendars are functioning. Currently only a few panels are available for adding to the interface, but eventually the calendar Admin will be able to choose from a wide variety of status panels to add to the interface, in order to create a single-screen overview of the current happenings in their Calendar.
The MightyCal Beta 1 release has been made. The main changes available in Beta 1 are in the display templates available via the Cocoon frontend... MightyCal can now display calendars in HTML (List View, Month View, Event Detail and Event Edit), PDF (List View and Month View) and Avantgo/Strict HTML3.2 (List View and Month View). The Intermediate Template Language and associated Stylesheet Management interface have matured a lot, so that layout and look-and-feel are highly customizable. Event editing via the Cocoon frontend is also working. Downloads of the Frontend and Backend files are available from the "Files" area, and a basic Install document is available from "Docs".
The Monthly Calendar now displays in AvantGo format, displaying a period for each event in the day. Eventually the periods will hyperlink to an event listing of that single day.
Event hyperlinking in HTML is working; it links to an event detail page, which displays all fields of the event in a table format. Also implemented an event-editing page, which displays edit widgets instead of field values, in the same tabular format.
The month calendar format now is able to display in PDF format, as well as HTML. This was non-trivial, since it required implementing a two-stage generation of FO objects, rather than just generating output elements directly, as in HTML format.
At last, the Monthly Calendar display format is working. This display format produces a standard tabular month calendar, with just the event titles appearing the cells for the days. (In HTML and other interactive formats, the event titles will be hyperlinked to a full display of the event). This feature had to be implemented using a Java XSLT extension class, since XSLT by itself doesn't have the power to do things like figure out how many weeks are in a particular month, or which weekday the month begins on, etc.
Both HTML and PDF documents style themselves entirely using style info from the Zope backend. After much misery, I finally figured out how to apply dynamic styles to an XSL-FO document. This means that changes that administrators make to stylesheets via the new editing interface will automatically get applied to new PDF documents.
Stylesheet editing support has matured. A new administrative interface makes it easy to edit the styling that gets applied to HTML, PDF and other output formats.
I have upgraded the status of MightyCal to Alpha, in recognition of the fact that both the backend and frontend are functional. The backend performs the basic functionality needed to define Calendars, their associated EventTypes and Templates, and enter Events. The frontend can produce (very ugly) PDF and HTML versions of the simple event-list Templates. In recognition of this fact, I have made the project's first file release.
The Intermediate Template rendering functionality is more or less complete -- the template rendering engine now includes all levels of templates (Calendar, EventType and FieldSpec) into the final result template that gets sent to Cocoon. Also, the "Preview Parsed Template" function in the template editing screen now works properly.
Got initial functionality for the unified Intermediate template-editing interface. Admins can now edit all the details of how their calendars will appear, all the way down to the presentation of individual fields, by using a single Explorer-like tree view.
The Cocoon frontend now can generate both HTML and PDF calendars. Also, reworked how the Intermediate-language templates are stored in the system, and uploaded a UML diagram showing the new design. Finally, uploaded four UML Class diagrams showing how FieldSpec composites work.
Updated the master Class UML diagram, and added a Collaboration detailing how a FieldSpec restructures itself in response to a request to change its DataType. UML diagrams are available from the homepage at http://mightycal.sourceforge.net.
# The Cocoon frontend is working, and it can generate basic (i.e. very ugly) read-only calendars based entirely on dynamic XML and XSLT files that it gets from the backend. MightyCal admins now have the ability to customize XSLT templates for the calendars they set up, to produce custom looks-and-feels for each one.
I've made an initial upload of the Zope backend files. The current MightyCal product implements the administration interface and event storage features. More to come soon.