This is the changelog for the MightyCal project backend. In order to understand the terminology, you will need to have a good background in Python programming for Zope. To get started, I recommend the "Zope Book", by Michel Pelletier and Amos Latteier. $Log: CHANGELOG,v $ Revision 1.85 2003/03/04 14:33:28 enorvelle * Minor bug fixes to variety of modules Revision 1.84 2003/02/10 09:12:58 enorvelle * Added top-level getObjectContent() method (in MightyCal object) to allow Frontend to fetch file contents without having to know Backend internal structure. Revision 1.83 2003/02/08 04:05:40 enorvelle * Added new user type to User.CalendarUser... the TelnetAuthenticatedUser, which performs authentication by calling a telnet server and testing out the password/username combo given by the user. * Updated the UserRegistry to handle adding and editing users of different types. * The XML.XmlRpcHandler module now passes authentication requests on to the UserRegistry, instead of automatically returning "successful" as its result. Revision 1.82 2003/01/28 08:46:51 enorvelle * Created new XML subpackage to handle all XML serialization and XMLRPC command processing. * Added two new entry points in the MightyCal module: xmlSerialize and xmlRpcHandler, which pass the command requests they receive off to the handleCommand() methods of the XmlSerializer or XmlRpcHandler modules respectively. Revision 1.81 2003/01/24 17:02:56 enorvelle * Created new XML subpackage, which will contain all modules relating to XML manipulating, including XMLRPC interactions * Added getCalendarDefaults() to MightyCal.py, and also to CalendarRegistry.py and Calendar.py. These methods gather and return information on the default Calendar, Template and Stylesheet that a web user should see, if no other values are specified. This information is consumed by the Cocoon frontend * Restructured FieldSpec class to be built out of Zope objects; ContentTypes, DataTypes, and DataRangeProviders are now SFolder derivatives, and DefaultValueProviders are SItem derivatives. This makes it possible for these objects to index themselves with the new ObjectCatalog, so that they can be called directly when necessary. * Added a new ZCatalog object to the MightyCal class; this new catalog is called the "ObjectCatalog", and is used for cataloguing internal objects that should never been seen from the Web interface or frontend. In addition, added a getObject() method to MightyCal which searched the ObjectCatalog for a given id, and returns a reference to that object. * Added a getCalendarDefaults() method to the MightyCal class, which is accessible via XMLRPC from the Cocoon frontend only, and which queries the CalendarRegistry to find the current default Calendar and various defaults. Also returns the current default Web user ID. * It's now possible to edit SearchWidgets and change their subtypes. Revision 1.80 2003/01/08 15:50:18 enorvelle * Fixed problems with ImageCollection not receiving proper security policy application. * Added tag to the MightyCal Template Language; this tag is valid within the context of the tag, and adds the specified SearchWidget to the Calendar display. * Consolidated getEventAsXML(), getCalendarEventsAsXML(), getTemplateAsXML() and getSearchWidgetAsXML() methods into XMLSerializer.py. Eventually the intention is that Cocoon should need to know only about a very limited set of access points within the Zope backend; in this case, all Backend routines that generate XML for consumption by Cocoon should be located in the XMLSerializer.py module. * Fixed major problem with SItem class, which did not properly handle Implied Acquisition. This was mainly a problem for DTML files, which rely heavily on implicit acquisition to look up tag values. Lack of implied acquisition also caused Events to be unable to index or reindex themselves in the EventCatalog, since both index_object() and reindex_object() rely on using implicit acquisition to locate the ZCatalog they are supposed to index themselves in. The fix for this was simple... put "Implicit" before "Explicit" in the definition of the SItem class. The SItem then becomes an ImpliedAcquirerWrapper object, rather than an ExplicitAcquirerWrapper; Explicit acquisition still works, but Implicit is available by default. Revision 1.79 2003/01/04 17:02:10 enorvelle * Added management_javascript.js.dtml, a set of Javascript routines that are common useful in drawing dialog boxes and performing other management interface tasks. This Javascript is made available as the management_javascript() DTML method of the main MightyCal object. * Updates the failure_dialog and finish_dialog DTML methods of the MightyCal object to ensure that when they close themselves, they update the window that is responsible for opening them. * Added ability to edit NamedCriterion objects in the ZMI, as well as to add additional NamedCriterion objects to a SearchWidget whose internal implementation is a SpecifiedCriterionSearchWidgetImpl Revision 1.78 2003/01/03 14:47:19 enorvelle * Added the method addCommonEventType() to the EventTypeRegistry, which handles making sure that there is an EventType with the id of "Common" in the registry; this EventType is not to be used for creating Event objects, but rather is a template that provides information about the default structure of EventTypes, even when there are no EventTypes defined by administrators. This introspective capacity is needed in order to build SearchWidgets for new Calendars, since SearchWidgets are linked intimately to particular fields, and need to be able to inquire for information from those FieldSpecs * Filled out functionality for the SimpleNamedCriterion, in particular the DTML method for editing the Criterion object. * Added a getObject() method to EventCatalog, to allow for retrieving a catalogued object, given its "id" attribute. This is especially helpful in looking up FieldSpecs when their parent EventTypes are not known. * The SearchWidgetCollection object now adds a number of default SearchWidgets to itself upon construction, including a DateRange search widget * Updated the SearchWidget module, in particular adding the ability to edit the various SearchWidget types, and to allow the admin to change the internal implementation of a particular widget, if several options are available (e.g. a text field can allow either a KeywordWidgetImpl or SpecifiedCriteriaWidgetImpl as its implementation subobject) Revision 1.77 2003/01/02 10:24:13 enorvelle * Added new SearchWidget implementation subtypes: KeywordWidgetImpl and SpecifiedCriteriaImpl, along with DTML methods for rendering the particular info related to each widget subtype * Added "Sample of Widget" preview to the SearchWidget manage_main method so that admins can see what the search widget will look like in HTML user agents. Revision 1.76 2002/12/31 15:37:41 enorvelle * Replaced "Criteria" in top admin frame for Calendars with "Search Widgets"; admins will now create and manipulate SearchWidgets directly, and only indirectly (and hopefully in a transparent way) interact with NamedCriterion and CriteriaSet objects * Added createWidget() method to SearchWidgetCollection, which in collboration with the addSearchWidget DTML method allows an admin to add a new search widget based upon an existing FieldSpec in his Calendar. * add_searchWidget.dtml file (implemented as the addSearchWidget method of a SearchWidgetCollection object) now creates a table of available FieldSpecs that the search widget can be based upon, allowing the user to specify the widget's label and FieldSpec linkage at creation time. * manage_main_searchWidget.dtml (implemented as the manage_main DTML method of a SearchWidget object) now prints the widget's label, type and fieldSpec linkage. It also embeds a panel which describes the purpose of the widget, and draws a sample of how the widget will look like when a user sees it. Revision 1.75 2002/12/30 10:02:33 enorvelle * Added new Search subpackage. Contains CriteriaSet and NamedCriterion modules, in addition to two new modules: - SearchWidget: Implements SearchWidget class, which allows the administrator to define "widgets" (i.e. either drop-down select boxes or text search boxes) that will perform a filtering of the Events that are shown in the Calendar view. Every Calendar will have a small set of predefined SearchWidgets (e.g. DateSearchWidget), but the Calendar admin can add new ones or modify existing ones as needed by his particular Calendar - SearchWidgetCollection: The container object that each Calendar has for holding the SearchWidgets defined for that particular calendar. Also handles the creation of new Widgets via the ZMI * Calendar class now adds a WidgetCollection to itself upon creation, and populates it with a few common widgets * Added getSearchWidgetInfo() method to the FieldSpec composite and its components; this method retrieves information about suggested SearchWidget types for a particular field, as well as the list of values the widget can display. Called during construction of a SearchWidget, as well as when a Calendar view has been requested, and the valid widget values are needed. Revision 1.74 2002/12/23 11:19:23 enorvelle * Added SItem.py module, containing the SItem class, which is now the base class for all MightyCal objects which are not containers. The SItem class accomplishes two purposes: - It overrides the _subobject_permissions() method normally obtained via acquisition from the master Zope Application object. It does this so as to circumvent the need for acquisition to be operative when an SItem-derived object is being added to a container. SFolder classes (which are the basic MightyCal container object, derived from Folder) add subobjects, they automatically apply security settings to them, based on their security_policy attribute. The permission-setting process of Zope objects make a call to _subobject_permissions(), and during the process of adding an object, we have to avoid acquisition, since the object isn't yet truly in the ZODB. Therefore, our new _subobject_permissions() method simply returns a null tuple, avoiding acquisition, and thus allowing permissions to be applied during the process of adding the subobject. - SItem also defines a standard set of mixin classes that all MightyCal objects need. * Rewrote all non-container classes to be based on SItem Revision 1.73 2002/12/23 09:33:19 enorvelle * Major security rewrite. The main goal has been to make sure that appropriate security permissions get applied as soon as new objects are added, including setting correct permissions for the entire MightyCal object tree as soon as a new instance of the product is added. - Created a new class SFolder, which is a superclass of the basic Folder type, but which overrides the _setObject method of the standard Folder class. The new implementation makes sure to assign every object that gets added a "serial id" that is a unique identifier, unrelated to the Zope ID. This serial ID is used during the traversing of the MightyCal object tree in order to make sure that an infinite loop is avoided, since in some places in the tree there are upwards references that cause recursion during traversal. Also, the new _setObject implementation calls the applyPermissions() method of the SecurityPolicy module to set appropriate security policy on the new child object(s). - Rewrote all classes that base themselves on Folder to be based on SFolder instead. - Added "security_policy" attribute to all classes, in order to make sure that MightyCal classes can specify the policy set that should be applied to them when new instances are created. This new attribute is used as the lookup value in the SECURITY_POLICY dictionary itself. - Removed the PermissionsPropagation class, and eliminated it as a mixin from all MightyCal containers, since its functionality is now handled by the SFolder class itself. Revision 1.72 2002/12/20 12:58:21 enorvelle * Modified the CocoonHTMLWidgetMaker so that it generates an entire row for each requested widget, including the field's label. Also, non-public fields are generated as empty rows. * Added some extra permissions for the CalendarAdmin role; in particular, this role needs to be able to view images and add events. Revision 1.71 2002/12/20 02:51:40 enorvelle * During the __init__ routine of object whose IDs may be duplicated in the ZODB, a "serial" attribute is also generated, which provides a unique identifier to the object, above and beyond its ZOPE id. * Modified SecurityPolicy.py to look for the 'serial' attribute on the objects that it applies permissions to, and to use that as its identifier in the permissionsMemory dictionary when present. * Added getEventAsXML() to XMLSerializer.py (moving it from EventCatalog). I am trying to minimize as much as possible the number of backend objects that the Cocoon frontend needs to know about in order to get all the data it needs. Also made sure to restrict access to this new function with the permXMLRPCAccess permission. * The initial cocoon user account now gets set up properly (in particular the password is correct, and we give the user a domain limitation to localhost, to prevent the account's abuse, since its password is knownn to anyone who reads the source code) * The view_events method of the Calendar class now utilizes EventCatalog functionality... instead of trying to provide its own DTML method for viewing Events, it simply redirects the Calendar Admin to the Event listing of EventCatalog, where the Session variable 'Current Calendar' will be read and the visible Events filtered appropriately. * The ContentType class now participates in generating the MTL template for the parent FieldSpec... this is required, since the actual data for a Field may come in several parts, depending on the ContentType, and so the ContentType is the only class with the knowledge of which DataTypes (and therefore Event fields) are needed in order to display the total data for the FieldSpec. * Added permChangeFilesAndImages permission, to allow the admin to modify Image objects (in particular, in order to upload the actual image content once an Image object has been created) Revision 1.70 2002/12/16 22:36:15 enorvelle * Added meta_type attributes to all class definitions that lack them, so that applyPermissions() in the SecurityPolicy module would have a consistent way of looking up an object's type in order to find the policy that should be applied. * Moved a number of object type constants in the the top-level Const.py file, from prior locations in subpackage Const.py files. I decided object type names should be global, since they are often referred to in several different subpackages besides the one where their base class is defined. In addition, the SecurityPolicy module needs to be able to see object name constants, and it is a lot easier to import all the needed names from a single Const.py file, than specify all the myriad subpackages individually. Revision 1.69 2002/12/13 17:51:02 enorvelle * Added new Security subpackage, and moved Permissions and SecurityPolicy modules into it. Also created new PermissionsPropagation module in this new subpackage; this new module implements a simple mixin class that adds a propagatePermissions() method to any class it is made part of. The applyPermissions() method of the SecurityPolicy module checks for this propagatePermissions() method, and if it is present, calls it. In this way, the act of applying security policy to top level objects also causes those policies to be propagated down in the Zope object hierarchy. * Added new CSS class tags to standard_html.css for editing widgets, as well as new tags for "error-styled" widgets, i.e. widgets that are colored or otherwise modified to indicate an error in validation for that field. * Added the PermissionsPropagator mixin class as a base class for all MightyCal objects that serve as collections (typically those classes based on Folder), in order to make sure that security policy propagates nicely down the tree of Zope objects. * Fixed import of Permissions module to refer to new location of Products.MightyCal.Security.Permissions in all modules that use permissions declarations. Revision 1.68 2002/12/12 10:43:37 enorvelle * Renamed testDataEntryHandler. from test.py, and added getFieldIds() and getWidgets() tests * In event_entry method of DataEntryHandler, the call to getDataEntryTransaction() needed to have eventType, eventId and dtId parameters explicitly specified. Also, methods of EventCatalog that allowed event editing and creation via the ZMI had to be modified to pass all of these parameters to the event_entry method, which is the one event editing/creation DTML method of the ZMI. * Changed EventSnapshot's method of getting string values of Event fields... rather than storing a method reference to a DataType's asString() method, the populateDataEntryTransaction() method of DataType classes was changed to automatically populate the EventSnapshot with an Event's field value if an Event ID was specified (i.e. when the EventSnapshot was going to be of an existing Event, rather than of a brand new empty Event). At the same time, the DataType's asString method is called and the string value is stored at that point. Since only methods for serializing an Event use the string value of a field, the fact that a field's native Python value and string value may diverge via the activity of the DataEntryTransaction superclass is not a problem, since no activity of the latter superclass depend on string values. * Fixed weird error in xmlRPCEntryPoint, where the entire routine would complete satisfactorily, but after the return() instruction was hit, a Zope pickling exception would be thrown, complaining about not being able to pickle Python Method objects. This was a result of the fact that when a DataEntryTransaction was generated in response to an XMLRPC call, the ZODB would try to perform a database commit() operation on the new transaction object (stored in our TempFolder). Since DataEntryTransaction objects are based on EventSnapshot, which in turn stored a reference to the asString() method of an Event's DataType, the ZODB was trying to store a method reference. This was the cause of the refactoring of the EventSnapshot and the methods for populating a snapshot object, so that the need for storing a method reference could be eliminated, while preserving the ability to fetch a String value for a field. * Also added the "get-field-ids" command to xmlRPCEntryPoint's list of commands that it will handle. This returns a simple List of field Ids contained in a DataEntryTransaction. Revision 1.67 2002/12/11 14:30:46 enorvelle * Added EventTypeCollection class and associated DTML methods. The EventTypeCollection is instantiated as a child object of a Calendar, and provides a view into the EventTypeRegistry that shows only the EventTypes owned by a particular Calendar. The EventTypeCollection is what is exposed to the Calendar Admin via the administration Consoles, thereby preventing Admins from mucking with EventTypes they don't have rights to. * Added code to the Console interfaces for setting variables controlling what the current Calendar is, so that the EventTypeRegistry can limit its display of EventTypes to those owned by a particular Calendar when being accessed via the Admin Consoles rather than the ZMI. Revision 1.66 2002/12/10 08:01:58 enorvelle * Moved constants for a number of object types from subpackages into the top-level Const.py files; these include contsnts for StyleCollection, TemplateCollection, CriteriaSet, and ImageCollection * Changed permission required on CalendarStatusConsole and CalendarPanels from permViewMgmtScreen to permAdministerCalendar * Added the ability for CalendarRegistry, Calendar, EventTypeRegistry and EventType to use SecurityPolicy's applyPermissions function to apply security policy to new objects (or subobjects, in the case of Calendars) upon object creation. * Changed all occurrences of "Delete Objects" permission declaration with properly-spelled "Delete objects" Zope permission (or a reference to permDelObjs, which now refers to the properly spelled permission). This had been the cause of missing "Delete" buttons in a number of ZMI management screens, since Zope permissions are *very* case sensitive. * Added a slew of new permission definitions to Permissions.py, and updated the security policy settings in SecurityPolicy.py accordingly. In particular, it turns out that the ability to access transient objects is crucial for the ability to access the various Consoles, since they rely on Session data, which is implemented as a Transient superclass. Therefore, the ability to access and manage transient objects had to be granted to Manager roles and CalendarAdmin roles, at least for the Console classes. Also added a whole bunch of additional permissions to the default permissions for the Manager user, so that a Manager can access the ZMI without going through the Console interfaces (i.e. granting things like the ability to manage permissions, view objects, manage security settings and ZCatalogs, etc) Revision 1.65 2002/12/09 10:07:39 enorvelle * Added addCocoonUser() to UserRegistry, which simply adds the Cocoon user with XMLRPC access permissions * Added xmlRpcTests directory to DataEntry subpackage, in order to test that all aspects of the xmlRPCEntryPoint() method works, in particular that getting an DataEntryTransaction, submitting a transaction, and getting Widgets works. * Added permAddDocsAndImages, permAddFieldSpec, permManageAccessRules and permChangePermissions to Permissions.py in order to provide finer grained access control. In particular, permAddDocsAndImages, permManageAccessRules and permChangePermissions are needed by the Manager role so that the MightyCal instance and its subobjects can be managed by the ZMI * Added xmlRPCAccessPoint() method to DataEntryHandler, which provides a single routine that the Cocoon frontend can access via XMLRPC. The frontend passes the requested command in the parameter list, and the xmlRPCAccessPoint() method then calls the appropriate routine to complete the requested command, returning a status code and any results (or errors) generated by the proxied command. * Added SecurityPolicy.py, a module dedicated to collecting the security policy information for the MightyCal policy in a single place, and also containing routines for applying that policy to the various subobjects of the MightyCal. The SECURITY_POLICY dictionary contains the permissions that are to be granted to the various Zope Roles that the MightyCal product defines; the applyPermissions() routines ensures that the permissions in this dictionary (and only those permissions) are granted to the Roles that are specified; all other permissions are denied by default. The idea is an "Eyes Only" policy that grants the minimum possible access that we can get away with. Generally speaking, the entire ZMI for the MightyCal product is denied to any user that does not have either a Manager or CalendarAdmin Role. The CalendarAdmin has only a very restricted set of permissions, i.e. adding EventTypes and Templates, and is disallowed from viewing any ZMI objects except through the admin_interface methods defined via the various Consoles (i.e. the MightyCal Admin Console and the Calendar Consoles) * The MightyCal now has a method called setSecurityPolicy(), which sets up the defined Roles for the MightyCal object, and calls applyPermissions() on each MightyCal subobject. Revision 1.64 2002/12/06 06:51:31 enorvelle * Changed EventType and related classes to have method named populateEventSnapshot() rather than populateDataEntryTransaction() * Created EventSnapshot.py module, containing EventSnapshot class and TransactionField class. EventSnapshot isolates the information-collection functionality of DataEntryTransaction, and also serves as the new base class for DataEntryTransaction. EventSnapshot is also now used for collecting information during the process of serializing Events for sending to Cocoon (in XMLSerializer.py). Added this new class to the EventCatalog subpackage, since it relates to Events most closely. * Changed the XMLSerializer class to use the new EventSnapshot class in order to collection information about Events during the process of serializing them. * Eliminated the EventToXMLTranslator.py module, since its intended functionality now is contained in the XMLSerializer.py module. * Refactored DataEntryTransaction class into EventSnapshot and DataEntryTransaction. The latter only only contains functionality related to Event verification and widget production; all other Event information gathering functionality is contained in the new EventSnapshot base class. * Re-added getEventsAsXML() method to Calendar; as before, the Cocoon frontend needs to know which calendar it is requesting Events from. This is the easiest way of making sure that the proper CalendarId is put into the QueryObject which fetches the Event objects from the EventCatalog. Revision 1.63 2002/12/05 09:43:43 enorvelle * Added ability to list a CriteriaSet via its manage_main DTML method. Put a link into the Calendar's admin_top_frame to link to this CriteriaSet management view. This new view includes a widget for adding new NamedCriterion objects, as well as links for editing each NamedCriterion. Revision 1.62 2002/12/05 07:24:42 enorvelle * Added CalendarSummariesPanel to the main MightyCal Console, for showing summaries of all of the currently registered Calendars. * Added getSummary() routine to Calendar class, which provides a dictionary giving a set of summary information about the Calendar's current status; this is used by the CalendarSummariesPanel when it draws the summary blocks. * Added button to CalendarSummaryPanel in CalendarPanels.py, which will bring up a dialog box for editing the Calendar's properties. Also changed the Calendar's manage_main method and updateCalendar() method to recognize when they are being called within a dialog box, and respond appropriately. Revision 1.61 2002/12/04 06:41:22 enorvelle * Added new CriteriaSet and NamedCriterion modules. The purpose of these modules is to implement a new EventCatalog search methodology that will drastically simplify how queries are made, especially from the Cocoon frontend to the Zope backend. The concept is that in order to retrieve a set of Events, the querying class/entity need only specify the names of some (pre-existing) criteria sets, and all of the work of compiling a ZCatalog query will be done invisibly by the backend. Therefore, if a Cocoon page wishes to limit its results to all events in the next thirty days, it need only specify the "ThisMonth" criteria ID. Also, the query widgets generated by the Cocoon frontend will be based on these named criteria... in the Intermediate language, a tag can be specified, with a "criteria" attribute containing a comma-delimited list of the possible searches the user can perform by means of the generated widget. - The NamedCriterion class is the most basic component of this infrastructure... it simply holds a Index-name and criterion pair, which is given a web-valid ID as well as an English title. Searches can use this criteria just by referring to it by its ID - The CriteriaSet class is a Folderish class that holds instances of NamedCriterion objects. It has a ZMI interface that allows new NamedCriterion objects to be created, or existing ones to be edited. * CalendarCriteriaSet is a superclass of CriteriaSet that gets attached as a child of a Calendar object. When instantiated, it automatically creates a number of common NamedCriterion objects as its children, such as criteria for 'This Week', 'Unapproved Events', and the like. * Modified Calendar.py to use a CalendarCriteriaSet in place of the older EventCollection object. * Changed UnapprovedEventsPanel and UpcomingEventsPanel to use the new queryEvents() method of EventCatalog in order to get their list of Events. * Added queryEvents() method to EventCatalog. This method takes a ZCatalog QueryObject as its input, and returns a list of Events. QueryObjects can be gotten by calling the getQueryObject() method of a CriteriaSet, which handles compiling a custom query object based on the list of NamedCriterion objects given to it. * Added new 'Administer Calendar' permission to Permissions.py. This permission will be granted to CalendarAdmins who are owners (or permitted administrators) of particular Calendars, and will be denied to all other Roles except Owner (and of course the admin user). Revision 1.60 2002/12/03 10:51:09 enorvelle * Added new DTML methods to MightyCal instance: - failureDialog and finishDialog are used to give the user response to actions, without having the OK button redirect him to the management screen that would normally appear. These are used to let the MightyCal admin perform a number of duties via dialog boxes accessible from the main administration screen, rather than from the standard ZMI. - Added a refresh DTML method to MightyCal, which is essentially a debugging method used for deleting and re-adding the MightyCal Admin Console, so that changes to the latter can be applied without having to recreate the MightyCal instance. * Added a new Panel to the MightyCalConsole, which has buttons for performing several common operations, such as adding new Calendars and adding new Users. * Removed the EventCollection module/class from the EventCatalog subpackage. Its functionality will be replaced by NamedCriteriaSets and CriteriaCollections. * Added ability to UserRegistry for the addUser routine to be called via a dialog box, in addition to the ZMI * Added ability to CalendarRegistry for the addCalendar routine to be called via a dialog box, in addition to the ZMI * MightyCal now adds additional Zope security Roles (XMLRPC Role, Web User Role, Submitter Role), and also sets up permission associations with these roles * Moved Zope Security Roles names to Permissions (from User/Const.py) Revision 1.59 2002/12/01 03:20:53 enorvelle * Created new XMLSerialize subpackage, which contains functionality for sending serialized MightyCal objects and sets of objects to the Cocoon frontend. Eventually, its XMLSerializer class will become the single communication point from which Cocoon receives EventType descriptors, and Event listings. * Moved XML serialization tags from Template.Const to XMLSerialize.Const * Added panel to MightCalPanels for providing a summary of the main MightyCal instance * Moved XML serialization functionality from classes in the EventCatalog and EventType subpackages into the XMLSerialize subpackage. * Added registration of the new XMLSerialize and MightyCalConsole classes so that they will show up in the ZMI MightyCal object listing with nice icons. * Removed a number of permissions for objects that can't be added via the ZMI (or by any other means except via Python code), and replaced them with a single 'MightyCal Subobject Permission', which will be denied to all users except the MightyCal instance administrator. * During MightyCal creation, a MightyCalConsole object and an XMLSerializer object are both added as subobjects. Also, fixed the ZMI-accessible constructor methods to send the proper number of parameters to MightyCal's __init__ method. Revision 1.58 2002/11/30 02:18:28 enorvelle * Fixed issues relating to approving events - Mail notifications are now properly sent out; also formatting of the notifications is properly left-aligned - A requested calendar can now be properly moved to the Approved Calendars field via the ZMI, so that admins can mark the event as 'approved', and the event submitter will be notified. Revision 1.57 2002/11/28 04:06:22 enorvelle * Added logging of exceptions along with stacktraces to standard exception handling routines. * Added a logException routine to Utils, which logs all details of an exception, including the module and method where it occurred, which exception occurred, and a stacktrace. * Moved manage_page_header and style_main.css to be defined as DTMLFile inline methods, rather than being added via the older addMethod routine. This means that these files will no longer appear as objects in the ZMI MightyCal instance listing, and it also means that alterations to these two DTML files on the filesystem will be immediately reflected in the methods themselves. * Moved approveEvents and rejectEvent back to CalendarPanels.py from Calendar.py, once I figured out how to make sure that the Panel methods get called when the user interacts with Panel widgets (i.e. this was a matter of making sure that the proper URLs got built for FORM ACTION parameters) * The reject_event dialog now knows how to call the rejectEvent() method on the UnapprovedEventsPanel; the event rejection routine works properly now. * UnapprovedEventsPanel now provides the ability to approve and reject events directly from the Panel's Event listing. * UpcomingEventsPanel properly displays only approved events. Also, if there are no events, it displays a message indicating that no events are upcoming. * In DataRangeProviders, fixed AbstractDataRangeProvider.validate(), and in DataTypes, fixed CalendarDataType._fromString() in order to properly handle input widgets that allow for selection of multiple values, e.g. the various Calendar selection widgets; prior, there was a confusion as to whether Calendar Properties in Events stored their values as Strings (comma-delimited) or as actual lists. Now all routines are in agreement about storing/processing Calendar selection data as lists * Filled in rejectEvent() routine in EventCatalog; it now properly removed the specified "rejected" calendar from the list of requested Calendars in the Event object. * Implemented notifyRejection() successfully; it now emails the user whose event was rejected with the administrator's rejection message. * The ZMI no longer hides "non-public" fields. The idea is that since only administrators will be using the ZMI, all Event fields should be visible to them. Revision 1.56 2002/11/27 07:02:07 enorvelle * Moved CalendarStatusConsole and related files (CalendarPanels, icons dir and dtml dir) to new location as subpackage of Calendar * Added DTML-callable routines for approving and rejecting Events to the Calendar. These routines are activated from the CalendarStatusConsole interface, but rely on EventCatalog to do the actual approval or rejection of Events. * Added a MailHost object as a child of the MightyCal, so that users and admins can be sent emails using SMTP. For instance, when an event is accepted or rejected, its submitter is notified. * Added a master administrative console to the MightyCal, which will give MightyCal admins a single-screen way of performing many admin tasks, and seeing the status of the MightyCal instance they oversee * Created a new Console subpackage as a child of the main MightyCal package; this subpackage contains MightyCalConsole and related modules, which constitute the admin console for the MightyCal. * Added routines for approving and rejecting events to EventCatalog * Added methods to UserRegistry for sending Event approval and rejection notifications to the submitters of the Events Revision 1.55 2002/11/26 01:56:42 enorvelle * In Calendar.py, replaced getUnapprovedEvents() with a more generalized routine, getEventsByCriteria(), which takes a dictionary of criteria usable by the ZCatalog searchResults() query interface. See www.zope.org/Documentation/ZopeBook/SearchingZCatalog.html for the Zope Book's take on this process, and also see the section on searchResults() at www.zope.org/Members/michel/Projects/Interfaces/ZCatalog.html, which is a Wiki interface about the ZCatalog's supported methods. * Moved the defaultFormat attribute values for DataTypes into constants defined in Const.py * Fixed an error in which the REQUEST object was not properly being passed to the EventCatalog's reindexing procedure, which needs the REQUEST object for some reason. * EventCollection's getEventIds() method can now be passed a catalog parameter (a reference to the main EventCatalog), so that it doesn't need to get this reference by acquisition. This means that EventCollections can be generated and queried on the fly, without having to be stored in the ZODB. * Added a new panel to the available Calendar admin panels: Upcoming Events Panel. This panel shows the nearest upcoming events (up to the quantity choosable by the administrator), and gives links for editing them * Changed the UnapprovedEventsPanel to allow for in-place approval of the listed Events, and also gives the mailto: URL for emailing the administrator about problems with the Event Revision 1.54 2002/11/25 16:02:27 enorvelle * The WidgetMakers now normally respect the "recommended widget type" specified by the DataType (or sometimes the DataRangeProvider). Also reworked the process of creating widgets to separate the type of widget (e.g. a text box) from the DataType that the widget is for, since several data types can share the same kind of widget, with minor differences in formatting. * Removed a bunch of unneeded logging calls and other debugging code from the DataEntry subpackage * Removed setNewIndexesAndProperties() from EventCatalog. Replaced restructureEvents() with restructureEventProperties(). Moved the intelligence for maintaining indexes and requesting structural changes to existing events back into the FieldSpec composite classes, where it was initially. Since the FieldSpec knows when it has changed, and (in particular) the DataType knows what kind of changes have been made to the information that will be stored in an Event, it makes sense to allow these classes to guide the EventCatalog in index maintenance and Event restructuring (following the GRASP patterns from "Applying UML and Patterns") * Made sure that changes to FieldSpecs (and their component ContentTypes, DataTypes and DataRangeProviders) resulted in the appropriate changes to the EventCatalog's indexes, and restructuring any Events that use the modified FieldSpec. Generally, this means using the EventCatalog's deleteIndex(), setIndex(), and restructureEventProperties() at appropriate times. * Changed DataType's populateDataEntryTransaction() to add a value to the transaction for the recommended widget type. Generally the DataType (or sometimes, as in the case of SimpleListDataRangeProvider, the data range provider) knows what the appropriate widget should be for entering data for that DataType. The WidgetMaker doesn't have to respect this recommendation, but normally will. Also, in line with this change, added a "recommendedWidget" attribute to each DataType class, and added overrideWidgetType() to DataRangeProvider classes, allowing them to specify a different widget if necessary * Added CSS style code to style_main.css.dtml for highlighting erroneous data fields in the ZMI Revision 1.53 2002/11/23 00:24:53 enorvelle * Moved DTML methods from the top-level dtml directory into dtml directories of the subpackages that they relate to. * Worked on making sure that modifications to EventTypes (i.e. adding/deleting/modifying FieldSpecs, or deleting EventTypes themselves) get reflected by modifying EventCatalog indexes, and by restructuring Events of that EventType to reflect the new structure. Revision 1.52 2002/11/19 23:57:54 enorvelle * Created new subpackages: Calendar, Style, and User, and moved related modules into the corresponding new subpackage. Also moved Tags and TagRegistry into the Template subpackage * Fixed remaining problems with mixed-case constants from the Tags module Revision 1.51 2002/11/19 14:42:15 enorvelle * Added import statements to each subpackage's __init__.py file to satisfy need for the subpackage to be considered to have its Const module as an attribute. * Created more extensive submodule documentation. Revision 1.50 2002/11/19 13:34:13 enorvelle * Event entry and updating via DataEntryHandler and DataEntryTransactions is finally working (at least through the ZMI) - Updated Event Entry DTML method to provide error messages and error styling for invalid transactions - Updated ZopeWidgetMaker.getWidget to provide error messages and error styling for invalid transactions - Fixed problem with DataEntryTransactions being reset to default values during Event updates, which was caused by using get_transaction() in EventCatalog.submitDataEntryTransaction() to manually start a ZODB transaction (which rolled back the not-yet-committed changes to the DataEntryTransaction) - Added getEditURL() to Event class, which generates a URL for editing the event in the ZMI - EventCatalog's manage_main DTML method updated to hyperlink Event listings to the proper Event editing functionality in DataEntryHandler - Added validation-error-header style to the style_main.css master ZMI stylesheet file - Added functionality in EventType subpackage to allow the EventType to specify DataRangeProvider and DefaultValueProvider for a field when adding mandatory fields to an EventType. This involved adding setDefaultValueProvider() and setDataRangeProvider() to ContentTypes, DataTypes and DataRangeProviders Revision 1.49 2002/11/18 14:45:51 enorvelle * Fixed issues with naming of the various form fields for the FieldSpec's dynamically-generated manage_main DTML method, in particular by changing the REQUEST record names to the names of the module each is associated with (originally the records were named based on the ID of the object whose parameters were being adjusted) * Changed the EventType's manage_main interface to disallow editing of FieldSpecs marked Immutable * The populateDataEntryTransaction chain of methods now also adds the set of valid data points to the DataEntryTransaction object, so that valid values can be accessed at the time of Widget creation. This promotes encapsulation, since the DataEntryTransaction no longer needs to try to speak directly with the DataType object or anything else in the EventType hierarchy when the Widget is being created. * The DataEntryHandler's event_entry DTML method now correctly generates an Event Entry/Update screen with the appropriate Widgets. * The DataEntryTransaction object has been restructured to further promote encapsulation, by providing a range of getter/setter methods for accessing the object's values. * A TransactionField class has been added to the DataEntryTransaction module; this class is used as an "inner" class for storing information about each distinct field that the DataEntryTransaction tracks. This class replaces the use of Python dictionaries for storing field data. Revision 1.48 2002/11/17 13:35:48 enorvelle * Changed WidgetMaker object so that they get their information from a DataEntryTransaction rather than from a DataType object as previously. DataEntryTransactions are responsible for generating widgets, since Transaction objects are what know about the current validation state of each field, and thus can specify special styling for fields with validation problems. * Added new DTML methods for editing an Event via the ZMI; these methods attach to the DataEntryHandler and rely on the new DataEntryTransaction infrastructure for performing Event creation/update. Also filled in the methods of the DataEntryHandler responsible for performing event creation or update. * The EventCatalog is now responsible for restructuring Events when EventTypes change (i.e. FieldSpecs get added, deleted or modified). Previously this functionality was passed off to the EventType and its component objects, especially the DataType object, which would directly add and delete Zope Properties from the Event. In order to provide better encapsulation of functionality, the EventCatalog is now the only object that knows how to manipulate Events directly like this. In addition, the EventCatalog can keep its indexes up to date at the same time that it is restructuring Events. * Restructured the EventType and its sub-objects to remove the necessity for EventTypes and DataTypes needing to directly manipulate Event objects... this functionality is now delegated to the EventCatalog. * Removed the Factory methods from FieldSpec, ContentTypes and DataTypes. These were initially designed to allow for reconstructing of EventType objects from XML specifications; since we are now going to rely on Zope's native pickling functionality for importing & exporting EventTypes, we don't need routines to handle this any longer. Now, FieldSpecs, ContentTypes and DataTypes are all created using their own constructors. * Simplified the intialize() method of the EventType class by creating a private method to contain duplicated code. Revision 1.47 2002/11/15 11:55:05 enorvelle * Added validateDataEntryTransaction to EventTypeRegistry and its children. When this method is called, the EventTypeRegistry will hand off the transaction to its EventType object, which will in turn ask each of its component FieldSpecs to validate the DataEntryTransaction. If an invalid field is found (ultimately by the DataType subcomponent), the setFieldInvalid() method of the DataEntryTransaction will be called. The validation error will be stored in the transaction object, for later reporting to the user. * The EventCatalog has a new method, submitDataEntryTransaction(), which checks to see if the DataEntryTransaction is trying to update a current Event, or create a new one. If the former, the populateEvent() method of the transaction is called, and the Event's Zope Properties are updated with new values, and the Event object is reindexed. If a new Event object is to be created, EventCatalog creates the new event, then hands the Event to the transaction's setupNewEvent() method, which creates new Zope Properties in the hitherto empty Event object. The Event object's index_object() is called, to make sure the Event is properly indexed by the ZODB * The old data entry methods and DTML screens have been removed from EventCatalog and the Event object, since all of their functionality is now handled by DataEntryHandler. Revision 1.46 2002/11/14 13:16:17 enorvelle * Added unit tests for DataEntry subpackage * Fixed constant problems in __init__.py Revision 1.45 2002/11/11 16:57:58 enorvelle * Moved many modules to new subpackages, and created a local Const.py and __init__.py for each subpackage. Each new subpackage groups modules that are related strongly enough that they share a lot of knowledge of each other's innards, including methods, structure and constant values. - EventType: Contains DataRangeProviders.py, DefaultValueProviders.py, EventType.py, FieldSpec.py ContentTypes.py, DataTypes.py, Enumerators.py and EventTypeRegistry.py. - EventCatalog: Contains EventCatalog.py, EventCollection.py and Event.py - DataEntry: Contains DataEntryHandler.py, DataEntryTransaction.py, WidgetMakerRegistry.py and WidgetMakers.py - Template: TemplateCollection.py and Template.py - XMLRPC: Nothing yet except Const.py and __init__.py, but will include all XMLRPC related functionality. * Moved most constants out of top-level Const.py into the subpackages' Const.py modules. Changed import statements when necessary to reflect the new locations of constants. Also changed method of importing so that constants from other packages are explicitly imported via from X import Y. * Changed constants to all upper-case from mixed case, except for module-local constants, which are left with mixed case to distinguish them from global or package-level constants. * Began implementation of new DataEntry methodology. This new method uses a DataEntryHandler as a single entry point for all Event update and creation functionality. Event updates and creation are handled via DataEntryTransaction objects, which allow for multi-stage editing of an event, with updates to the actual event (i.e. the transaction being committed) only after all validation errors are corrected. DataEntryTransaction handles the work of creating widgets that are pre-filled with either default or current Event field values, as well as styling the widgets properly to indicate when a validation error has occurred (e.g. coloring them red, etc), as well as annotating the widgets to indicate to the user what kind of error has occurred. Revision 1.44 2002/11/10 02:59:48 enorvelle * More constant fixing Revision 1.43 2002/10/29 10:35:47 enorvelle * Debugging of new implementation of MultiValueDataType. Revision 1.42 2002/10/28 10:03:00 enorvelle * Updated default Intermediate Language Templates in Calendar.py, EventType.py and FieldSpec.py to reflect latest available Tags. * Updated the default CSS files (standard_html.css and standard_xsl-fo.css) to reflect addition of StyleElements for new Tags * Changed default setup of StatusConsole for Calendar object; two columns are set up, with the SummaryPanel in the first Column, and the UnapprovedEventsPanel in the second Column * Added a MemoDataType to the DataTypes module. This is a field that holds an indefinitely long string, and which normally renders itself with a TEXTAREA input element. Added handlers to WidgetMakers for the new DataType. * Set all methods in ContentTypes, DataTypes, DefaultValueProviders and DataRangeProviders to be "private" from the point of view of Zope (i.e. used the security.declarePrivate() assertion) to guard against accidentally making available a way for hackers to modify backend data. * Implemented new administrative attributes for FieldSpecs: Indexed, Mandatory and Public. The Indexed attribute controls whether the field values for this FieldSpec will appear in the ZCatalog, and hence be searchable. Mandatory controls whether null values are acceptable for the field. Public indicates whether the field should be visible to nonadministrative users. * Added new MultiValueDataType, which holds a list of distinct values, and which generally will get rendered using SELECT controls (but could also be rendered using checkbox groups) Revision 1.41 2002/10/23 07:31:54 enorvelle * Added UnapprovedEventsPanel to CalendarPanels.py, along with its corresponding DTML file; Currently Event objects do not have an Approved property... once this property is added, the Panel will be upgraded to allow approving Events just by marking them within the Panel itself. Right now, the Panel just shows the Events currently within the Calendar. * Added __getitem__ to the Event class, so that DTML files can treat Events as mapping objects. Revision 1.40 2002/10/22 21:53:28 enorvelle * Moved CalendarStatusConsole.py and CalendarPanels.py to a new subpackage called Consoles, in order to start reducing clutter in the overall MightyCal package folder. Revision 1.39 2002/10/21 10:36:07 enorvelle * Moved status-console functionality out of Calendar.py, and instead added an instance of CalendarStatusConsole to each Calendar instance. * Created CalendarStatusConsole, which is a descendant of StatusConsole, customized to have panels appropriate to a Calendar object. * Created CalendarPanels, a module containing all of the ConsolePanel objects that will be available for display within a CalendarStatusConsole Revision 1.38 2002/10/17 10:43:38 enorvelle * Added Status Console functionality. Eventually this will become a full-fledged "portal" system providing the ability for the administrator to add/subtract "panels" from his Console; each panel will give info on a particular part of the Calendar, e.g. how many unapproved events there are, what traffic has been like, and so forth. Right now the functionality is very simplistic. Revision 1.37 2002/10/16 22:05:19 enorvelle * Began implementation of new administration interface, which utilizes the basic capabilities of the ZMI while hiding confusing or insecure features from Calendar admins. The new interface will eventually provide simplified administration for both MightyCal instance administrators (i.e. those with the rights to add new Calendars and associated objects) and Calendar Admins (i.e. those whose admin rights are restricted to the Calendars they own/manage) - Added admin_interface.dtml, admin_top_frame.dtml, and admin_calendar_top_frame.dtml to provide new frameset for this administration interface. - The new top frame gives access to all the object collections associated with a Calendar via hyperlinks. - A new "calendar_home" interface will be created, which will give a summary of the Calendar's current state, and will have plugins for monitoring various aspects of the calendar, e.g. unapproved events, traffic, etc. - Copied the ZMI's manage_tabs.dtml to local manage_tabs_header.dtml, and added features for hiding the management tabs when our custom management interface is being used. This means that the old ZMI can still be used to manage objects within a MightyCal instance, so long as the browser is not using our custom interface. Changed all of our DTML files to refer to the "manage_tabs_header" object instead of "manage_tabs" * Added an ImageCollection to the Calendar object, which contains Zope Image objects that hold the graphics associated with that Calendar. * Added a management screen for EventTypes to the Calendar object, which allows the Calendar admin to add event types, and edit those already created. Revision 1.36 2002/10/14 14:01:40 enorvelle * Added to Tags.py. This tag is used by the Cocoon frontend to generate an appropriate header for the calendar, depending on the output format called for. Various attributes and child tags are available for . Right now, the "logo" attribute and "showtitle" attributes are available, indicating the name of the logo graphic, and whether to show the textual title in the header area, respectively. child tags are also allowed, and give the ability to generate simple widgets to provide redirection to other Templates or output formats. * Changed Template.py so that the XML template output has "object-title" added to its tag. This allows Cocoon to always have access to the title of the object being displayed, so that it can use the title for things like the section of an HTML document, even if the "showtitle" attribute of <calendar-header> is "no" Revision 1.35 2002/10/12 14:39:10 enorvelle * Completed the logic for EventCatalog.submitEvent(). This involved a number of modifications to other modules: - Added createFieldDictFromRawInput() to EventType.py. This method builds a table of reconstructed field values for each of the FieldSpecs in the current event type, based on the raw form input that it is given. - Added recomposeFields() to ContentTypes.py, which handles reconstructing field values out of raw input for all of the Event properties that are managed by that ContentTypes. Since complex ContentTypes such as Actions or DateTimes can require multiple storage fields in an Event, the ContentType is thus responsible for recomposing all the information it knows about and manages. - Added recomposeFields() to FieldSpec.py, which is a facade method for the method added to ContentTypes.py. - Added _procesForXXXDataType() methods to CocoonHTMLWidgetMaker class. These methods rebuild a single field value out of (possibly) many pieces of input, since input widgets on different user agents may have many parts. * Added <button-set> and <back-button> tags to Tags.py Revision 1.34 2002/10/10 21:21:06 enorvelle * Finished porting widget creation code from DataTypes.py into WidgetMakers.py. Added a CocoonHTMLWidgetMaker class that generates appropriate widgets for sending to the Cocoon frontend. DataTypes.py has now been vacuumed of all code relating to widget creation. * Added <submit-button> to Tags.py, which Cocoon responds to by generating a form submit button. * MightyCal.py has been updated to add a WidgetMakerRepository whenever a MightyCal instance is created. * Added submitEvent() to EventCatalog; this is a routine intended to be used via XMLRPC to submit new or updated event info into the Catalog. Revision 1.33 2002/10/08 23:30:05 enorvelle * Added WidgetMakers.py, a module containing classes which implement an object-oriented way to create and process data from field-editing widgets. Previously, widget-creation code was contained in DataType objects. Now that logic has been moved into an appropriate WidgetMaker class. There is one WidgetMaker class for each class of user agent that we support. Currently, there is support for the plain-jane widgets used by the Zope administrative backend, as well as HTML 4.0 widgets created for the Cocoon frontend. * Also added WidgetMakerRegistry, which has the purpose of holding instances of WidgetMaker in the ZODB. WidgetMakers need to be instantiated within the ZODB so that they can utilize Acquisition. Upon creation of a MightyCal object, a WidgetMakerRegistry is added as one of its subobjects. * Changed ContentTypes.py to merge getZopeValueEditor and getCocoonValueEditor into a single routine. * Added a routine for creating <select> elements to Utils.py Revision 1.32 2002/10/05 14:11:16 enorvelle * FieldSpec's getCocoonValueEditor now accepts an Event ID, which it passes off to the embedded ContentType. The ContentType is responsible for retrieving the event property(ies) and creating a complete widget that is filled in with the value of the field. If no EventID is provided, then the returned widget will be returned with default values filled in. * Began writing a better DateTimeDataType._getInputWidget() routine, which creates a widget composed of <select> boxes for each component of the Date. Revision 1.31 2002/10/03 18:55:06 enorvelle * Added getCocoonFieldEditor() to FieldSpec. This routine sends back an XML document containing an HTML editor widget appropriate for the field's ContentType. To handle the fact that Cocoon doesn't want the <table> wrapping tags that the old getFieldEditor() routine provides, I rewrote AbstractDataType to to have two routines for providing field editors: getZopeFieldEditor() and getCocoonFieldEditor(). These two routines both then draw upon _getInputWidget(), which has been rewritten to markup the HTML widgts with "class" attributes, so that Cocoon-generated editor documents can be styled using the Zope backend stylesheet editor functionality. * Added <event-edit> tag, which is exactly like <event-detail>, except that it outputs a layout matrix containing <field-editor> tag, rather than just <field-value> tags. Cocoon turns <field-editor> tags into editing widgets, thus allowing a read-write event template. <event-edit> also outputs a <event-entry-form> tag as a wrapper for the event layout matrix, which Cocoon then turns into a <form action="..."> tag to allow submission of event updates back to the backend. Revision 1.30 2002/10/01 22:55:24 enorvelle * Added <event-detail> tag to Intermediate language, which creates an abstract table layout containing the field names and values in row/column format. The Cocoon frontend turns the abstract table into a table layout using the native coding of the destination format, and styles the resulting table using CSS style elements whose name begins with "event-detail," e.g. "event-detail-table" and so forth. Revision 1.29 2002/09/26 13:25:04 enorvelle * Fixed broken "Add Template" DTML page & accompanying Python code for adding a new Template to a TemplateCollection. * Moved <single-event> up to Calendar level, rather than EventType level. Revision 1.28 2002/09/26 10:18:54 enorvelle * Added the ability for certain Tag objects to specify that their attributes should be replicated into the final Intermediate-language document during Template parsing. In particular, the <event-hyperlink> Tag object needs to be able to pass on the "event-template" parameter, so that Cocoon will know which Template to call to display the event when a user selects the hyperlink. Revision 1.27 2002/09/25 11:48:05 enorvelle * Added ability for the administrator to add StyleElements to a stylesheet, and to delete them. * Began work on an interface in EventType that will allow Cocoon to request a single event from the backend, as well as to request a particular Template for displaying that event. * Updated the CSS templates (standard_html.css and standard_xsl-fo.css) to generate better-looking output in the Month-View display. Revision 1.26 2002/09/18 12:40:52 enorvelle * Added new style classes to css/standard_html.css, to enable style of the Monthly Calendar display format. * Added BTag class to Tags.py Revision 1.25 2002/09/14 04:29:10 enorvelle * Began the integration of applying formatting strings to event fields. The eventual idea is that admins should be able to specify a format string in a Template's <field-value> tag, using a "format" attribute. In order to accomplish this, I added two features: - DataType objects now have an asString method, which will apply a format string to a value of that DataType. DataTypes also now have a default formatString attribute, which defines the format that will be used if no format is specified when calling asString. In addition, the getFieldSpecAsXML method in the FieldSpec object calls upon this asString routine to cause the XML output to be returned in the DataType's default format. - Added xmlFormattedString() method to FieldSpec, which allows a Cocoon XSL stylesheet to make a call to the Zope backend and request that a particular value be reformatted according to a format string. This is how Cocoon will handle applying the format strings in the <field-value> tags... whenever it sees a "format" attribute, it will make a call to the zope backend to retrieve an XML mini-document containing a string value consisting of the field's value formatted according to the formatting string. Revision 1.24 2002/09/11 00:03:11 enorvelle * The Stylesheet class can now export itself in XSL "attribute-set" format, which gets used by the Cocoon frontend to embed style information into stylesheets that use XSL-FO to generate their outputs, such as PDF generation. The StyleElement class exports an individual StyleElement as a single <xsl:attribute-set> tree fragment, and the Stylesheet exports all of these fragments within a <style-attribute-set> tag. * Added a <footer> tag to contain and style text that should appear at the bottom of the Calendar display. * Created new, more complete default stylesheets for both HTML and XSL-FO documents. These stylesheets produce a plain but readable output. Revision 1.23 2002/09/08 06:35:20 enorvelle * Fixed bizarre problem with template rendering caused by a bug in xml.dom.NodeList. Oddly enough, when a NodeList is returned from the expand() method on a Tag object, all nodes except text nodes are dropped. So, I changed expand() to return a simple List object filled with nodes, which fixed things. Revision 1.22 2002/09/06 07:24:39 enorvelle * Fixed problems with Template treeview, where implied child templates of Calendar-level templates were not appearing as children in the tree, even though the child templates were appearing when the Templates were parsed and rendered to XML. * Made it possible to restore stylesheets to their default settings. Added a button for doing this to the StylesheetCollection management interface Revision 1.21 2002/09/05 07:27:19 enorvelle * Fixed StyleElement so that it prefixes a period to the element name when rendering to CSS, rather than prefixing to the property names, which was an error. * Stylesheet now wraps the CSS that it returns in <style>...</style> tags, which Cocoon apparently considers necessary before it will pass the CSS through to the browser. Cocoon has to pass the CSS through itself this way, because in an HTML document, the CSS stylesheet is given a URL which is relative to the main document, which itself has been requested via Cocoon. Thus, when the browser looks to get the CSS stylesheet, it goes back to the Cocoon frontend to do so. Revision 1.20 2002/09/05 00:37:06 enorvelle * The Stylesheet editing interface now works properly, with a tree menu providing access to the various stylesheets and their elements. The property editing interface for the StyleElement objects now allows for modification, addition and deletion of the property/value pairs of each StyleElement object. Finally, the Stylesheet object can now provide a properly-formatted CSS text file built from the StyleElement objects it contains. Revision 1.19 2002/09/04 08:50:04 enorvelle * Changed the names of the default CSS files to standard_html.css and standard_pdf.css * Added a routine to Utils.py to read all files in a particular directory into a Dictionary, whose keys are the filenames and the values are the contents of the files. Used by StyleCollection to pull in all the default CSS files and create Stylesheet objects out of them. * Created a management screen for StyleElement, based off of the Property Management screen of a standard Zope SimpleItem (found in $ZOPE_HOME/lib/python/OFS/dtml/property.dtml) * Added documentation to __init__.py about the new Stylesheet-related objects, and also added Stylesheet and StyleElement as registered classes, so that their icons will display properly. Revision 1.18 2002/09/03 21:06:32 enorvelle * Began process of adding a management interface and object hierarchy for handling stylesheets. - StyleCollection holds and manages a set of Stylesheet objects - Stylesheet holds and manages a collection of StyleElement objects, and can render the collection into a standard CSS text stylesheet, or an XML file that can be used by Cocoon to style XSL-FO documents - StyleElement holds a set of property/value pairs (i.e. the pairs that normally go between the braces in a CSS stylesheet) - Added a bunch of DTML files to support management of these objects Revision 1.17 2002/09/03 00:51:04 enorvelle * Restructured the way that Intermediate Templates format themselves. In particular, the <event-descriptor> tags now include a "type" attribute that refers to their EventType object. Also, there is no longer a <field-spec> tag surrounding each field in an <event-descriptor> section; they simply gave the Cocoon stylesheets something else they had to ignore. Revision 1.16 2002/08/30 17:00:36 enorvelle * During the process of rendering a Template, implied child templates of Calendar-level tags (such as <event-listing>) are included directly under the implying tag, rather than replacing it. This leaves Cocoon able to figure out what kind of layout the child templates are to be embedded in (e.g. a monthly versus list layout) * The Calendar-level <property> tag now gets replaced during rendering by the stringified value of the corresponding Zope Property of the Calendar object. * In Tags.py, expandChildTemplates() has been renamed expand(), since Property tags also need expansion, but don't have any child templates. * In the template-editing subframe, the "Get Parsed Template" button now shows the template embedded in an HTML <PRE> tag, with '<' characters replaced by '<' so that browsers won't interpret the template tags as markup. Revision 1.15 2002/08/29 22:28:58 enorvelle * Completed template rendering functionality... child templates are now parsed and embedded into the master template output when getAsXML() is called on a template. Revision 1.14 2002/08/28 06:34:05 enorvelle * Completed drill-down capability in the unified Template editing interface... admins can now explore all of the child templates implied by a higher-level template using a tree view. Previously the templates associated with FieldSpecs were unavailable to the editing interface. This required creating a separate getEmbeddedTemplates() method for the Field Tag class, which knows how to find the templates owned by FieldSpecs, given an EventType. * Began work on getting Templates to render properly into XML text. This has been implemented by an in-order traversal of the top-level Template's DOM, replacing any tags that imply child templates with the rendered XML of the child templates. In order to perform the replacement, the Tag class has a new expandChildTemplates() method. Currently only partially functional. Revision 1.13 2002/08/25 00:11:50 enorvelle * Completed functionality for displaying a tree view of Template objects. This involved several steps: - Getting EventTypes and FieldSpecs to list themselves properly in the ZCatalog, so that they could be found during the process of looking for implied child templates - Fixing the Tag getEmbeddedTemplate class to return Template objects, rather than TemplateCollections - Inside the <dtml-tree> tag in template_menu.dtml, using <dtml-var absolute_url> to generate the hyperlinks to child templates. - Added a __call__ method to FieldSpec, because when indexing EventTypes, the "FieldTitle" FieldSpec child is looked up and treated as an attribute (since there is a FieldTitle ZCatalog Index). Therefore I had to make FieldSpec objects "callable" and generate a dummy return value. - Renamed the manage_menu method of a Template object to manage_template_menu, so that the root manage_menu method of the Zope instance didn't get called (shouldn't happen, but it was) Revision 1.12 2002/08/23 16:47:46 enorvelle * Removed TemplateHandlers.py. Its functionality has been moved to the Template class itself. Revision 1.11 2002/08/23 16:44:12 enorvelle * Added TagRegistry, which contains instances of each Tag class in the Tags.py module. This makes it easy to get access to Tag functionality without constantly creating new class instances. The TagRegistry also has a manage_main method which provides a read-only view of the tags, as well as the ability to refresh the tags if Tags.py gets updated * Changed manage_main_template to use a Frameset. I stole DTML code from the main ZMI to accomplish this. The frame on the left provides a tree menu showing all available Templates and their children, and the frame on the right has the actual Template editing interface. * Set up the parsing routine of the Template object to translate the Admin's Template code directly into a DOM tree and store it in that format. The Template text is no longer directly stored. During parsing, the Template is checked for legality of all tags in that context. Right now, the ability to find and display implied Child templates is nonfunctional. Revision 1.10 2002/08/22 19:31:21 enorvelle * Added the Tags module, which contains "intelligent" objects that can assist in parsing Intermediate templates that contain those tags. In particular, Tag objects can report whether their usage is legal in a particular context, and can also locate child Templates that are implied by the usage of a particular tag in a template (e.g. the <event-listing> tag and its brethren) * Changed Template handling code in EventType and FieldSpec, so that each one now instantiates a TemplateCollection object to deal with its templates, thus handing off all that complexity to a specialized class. In addition, EventType and FieldSpec objects now list themselves with the ZCatalog, so that the Templates they contain can be found by higher-level templates that need them. * The MightyCal master object now adds a TagRegistry folder to itself, which will be filled with instances of all of the Tag objects, for easy finding and use via acquisition. * EventTypes are now forced to be owned by a particular Calendar. Other Calendars will still be allowed to display EventTypes they don't own, but this change means that a single administrator is now in charge of what an EventType will be structured like, and other Calendar admins will have to realize that their display of EventTypes they don't own means that they have to put up with any Template changes and structural changes those other EventTypes undergo. * The Add Calendar screen now displays a TextArea for entering a Calendar Description, instead of just a single line. Revision 1.9 2002/08/19 06:35:05 enorvelle * Added a bunch of documentation to __init__.py * Removed IDGenerator, AddImages and AddMethods, and moved their functionality to Utils.py * Got basic functionality of TemplateCollection and Template management screens working. Revision 1.8 2002/08/14 17:36:37 enorvelle * Added two new classes: Template and TemplateCollection. These classes will offload all intelligence for dealing with Templates, so that Calendars, EventTypes and FieldSpecs will no longer have to contain any intelligence for dealing with Templates. Also, this will allow for unifying the administration interface for templates, allowing the administrator to easily find and edit all the templates (and sub- templates) that relate to a particular calendar. Revision 1.7 2002/08/07 10:52:20 enorvelle * The Calendar class now has a getParsedTemplate() method, which creates a master Intermediate template based on the Calendar template and the templates for the various EventTypes that can be included in a particular Calendar. This Intermediate template is usable by Cocoon to produce the various end-result formats. * Calendars, EventTypes and FieldSpecs all now have admin-editable display templates, which gives the admin control over how each element of a calendar will be displayed. Right now, template support is very simple, with only a single template (i.e. a single display template) really supported. Eventually, various display templates will be supported (i.e. templates to display events in full vs. summaries or one-liners, etc), and Event editing and entry will be templatified. * Added the TemplateHandlers module, which contains a very simple template building algorithm. It works on the basis of recursive substitution... beginning with the Calendar template, it substitutes specified values for various tags (which may imply that the specified value is itself generated by calling TemplateHandler methods), until a final template is produced. Revision 1.6 2002/08/02 04:16:51 enorvelle * Added the ability for each Calendar to host a set of custom XSLT files that Cocoon will use to generate views of that particular Calendar. * Added a directory called 'xslt'; any files in this folder will be added as DTML documents to any new Calendar that gets added by an admin. These serve as generic frontend templates... the admin may then edit these templates to produce a custom look-and-feel * In EventType.py, getEventTypeDescriptorAsXML() and getEventAsXML() now add the eventType as an XML attribute to the element nodes they generate. Revision 1.5 2002/07/31 18:49:23 enorvelle * Upon creation, EventTypes now add two additional FieldSpecs to themselves: EventTime and Submitter. * Added new DataType: UserDataType, along with with UserDataRangeProvider, and LoggedInUserDefaultValueProvider, which allows the Submitter field to be automatically filled in with the Username of the person who submits an event * Changed the Add Calendar routine to request a user-entered ID, rather than generating a random one. This ID is checked for URL compatibility. This change was made so that admins can give out easy-to-type URLs for users to access their particular calendars. * Fixed problem with Add Calendar not using the username chosen for Existing User as calendar admin. * In EventType, changed getTitleField() to a more generalized getFieldValue() Revision 1.4 2002/07/30 12:45:29 enorvelle * Created CalendarDataType to hold the mandatory Calendar field in an Event, along with CalendarDataRangeProvider and CalendarDefaultValueProvider to go with it. * Added EventCollection object to Calendar. The Events in a Calendar can now be viewed via the ZMI, or can be fetched in XML format by calling the events.xml method on the EventCollection. * The XML output of an EventCollection includes an <event-type-descriptors> section, which provides the XML consumer with all of the information it needs to interpret the Event items themselves. Revision 1.3 2002/07/29 11:02:35 enorvelle * Completed/debugged CalendarRegistry, Calendar, UserRegistry and CalendarUser classes. * It's now possible to add & edit calendar users * When creating a Calendar, you can optionally create a new CalendarAdmin user to own it at the same time. Revision 1.2 2002/07/27 22:19:39 enorvelle * Added ability to export Events in XML format readable by Cocoon * Added Calendar class, plus a folderish-object to hold them (CalendarRegistry) * Added a custom UserFolder called UserRegistry, and defined custom User object to go with it. * Added DTML files for each of the above Revision 1.1.1.1 2002/07/23 10:14:20 enorvelle Upload to Sourceforge CVS Revision 1.1 2002/07/22 01:41:39 zope Inital Commit