TO-DO List for Calendar [-] During setup of new event, make it possible to indicate who gets email about new events; the default will be the Calendar admin, but can also be set to any other user field. [-] Add an field to the XML EventList sent to Cocoon to indicate whether a user has the right to edit an event or not. [-] Fix problem with ZMI event submission, where lists with nothing selected do not appear as REQUEST variables. [-] Make sure that Monthly calendars that cross year boundaries sort correctly, e.g. January 2003 after December 2002 [-] Implement copy-on-write semantics for Events that are shared between Calendars... i.e. if such an Event is modified by a Calendar Admin, the event should be first be duplicated so that a separate copy exists for other Calendar(s) that the Event displays in. [-] Change hard-coded variables in DTML files into dynamically-determined constant lookups. [-] Add a directory map showing (in annotated form) all of the directories and subdirectories of the Zope Product, as well as the Cocoon frontend. [-] Check that Cocoon can use the new DataEntryHandler interface for its data entry. Especially fix the backend URL that Cocoon fetches its widgets from. Also rework the CocoonHTMLWidgetMaker to use the new _makeXXXWidget() routines [*] Implement DateTimeRange, Action and Resources as multi-field FieldSpecs. [-] When the user is finished creating an Event, he will be given the ability to save the Transaction for future Event creation sessions as a provider of default values. [*] Need functionality for handling date/time ranges smoothly, e.g. turn start time + duration into a range, or a list of ranges for a repeating event, or an inverted list of used durations (for available times for a resource) [*] If a FieldSpec gets changed in the middle of editing an event, signal this to the user, force a restructure, then return the user to editing the event. [-] Implement format parameters for tags. [-] Fix spacing problems in output of Event fields in the final rendered Calendar (e.g. Periods after a Field always have a space preceding) [*] Make it possible for admins to export events as well as import them (poss. via pickling) [*] Build read-write calendars, which have event entry forms that will automatically fill in the fields necessary to make sure that these new events show up in the calendar retrievals [*] Make sure that Admins get email about new events. ================================================================================================== Done List [*] Write FieldDefinition to XML (& vice versa) converter [*] Make it possible to load fields from XML definition files [*] Make the FieldDefSpecs correspond exactly enough to the REQUESTs submitted during FieldSpecs updates so that they are interchangeable. [*] Combined EventContainer and EventCatalog into a new, mightier EventCatalog [*] Fix EventType editor so that changes to FieldSpecs are enforced upon already-existing Events. [*] When users change field values on Events, the values that get stored must be converted to the appropriate data types for that field, and not stored as Strings. [*] When Events have their field values changed, update their internal EventDefSpecs with those values [*] Build interface for turning an Event into a complete XML document, incorporating all important information, especially the information from the FieldSpecs [*] Download "extended" xmlrpclib.py from http://www.zope.org/Members/Amos/xmlrpclib.py [*] Add DefaultValueProvider class to provide default values [*] Eliminate race condition with updating event type structure when an event of that type is in the TempFolder. [*] Create a UML model representing the current state of things? [*] Turn the Field/EventDefStructs into better Memento exemplars. [*] Add XMLRPC-based test suite [*] Changed Event/EventType interaction so that Event objects do not need to know anything about EventTypes. Instead, during updates, the Event object is fed to the EventType object, which in turn performs all needed manipulations. This eliminates the need for both FieldDefStructs and EventTypeDefStructs, as well as the need for a restructure() method on the Event class itself. [*] Turn ContentType into a true Composite design pattern, which allows for multiple subfields under a single FieldSpec. [*] Build user-defineable "EventCollections", based largely on selecting field criteria and choosing "and" and "or" criteria for them. [*] Change Calendar ID so that it gets generated by Admin. Must be checked for URL-compatibility. [*] Add DurationSpec, Approved, Author and Calendars fields to autogenerated FieldSpecs [-] Generate a sequence diagram (or collaboration) for restructuring a FieldSpec. [-] Delete IDGenerator, AddImages, Schedule and TemplateHandler from CVS. [-] Templates need to index themselves in the ZCatalog so they can be easily found when looking for templates that are children of a higher-level template. [-] EventTypes need to have Calendar owners, rather than Calendars they can appear in. Also provide facility for copying EventTypes to other calendars. [*] Add a getValueEditor to FieldSpec interface, which produces an appropriate admin HTML editor widget for the field. [*] Children templates of certain Calendar-level templates aren't appearing in the treeview. [*] When there is text along with a tag in a FieldSpec's template, the is discarded and only the text is kept. [-] Events need an eventId so that they can be selected individually. [-] EventTypes need additional Templates for performing edits/views on a single event. [-] Implement an object-oriented widget-creation method, so that DataType instances can return appropriate widgets, given the type of user agent they are creating the widget for. The widget-creation intelligence will need to be removed from the DataType instances themselves and moved to other classes. [-] Implement the routines for updating the EventCatalog's indexes when an EventType has changed, as well as the routines for restructuring all of the Events that are of that EventType. [-] Perform update of index and Event-maintenance routines, so that all changes to EventTypes and FieldSpecs get reflected in the EventCatalog indexes and structure of the Events themselves. [-] Make sure that DataTypes can specify to the DataEntryTransaction what kind of widget is recommended. [-] Add a Memo datatype that will render itself as a Textarea. [-] Fix the color scheme applied to erroneous input fields. [-] Protect mandatory fieldspecs from being accessed via typed-in URLs [-] Fix ability to delete Events and FieldSpecs [-] Put back Try/Except blocks that have been commented out. [-] Add panel for viewing Upcoming Events in an Admin's calendar. [-] Set up CriteriaSets, which have names, and which can be grouped into CriteriaGroups, and associated with search widgets in the Cocoon frontend. Given the criteria sets that are selected, a ZCatalog query can be generated simply by specifying the CriteriaSets that should apply, rather than by trying to specify huge amounts of criteria data via GET/POST parameters. [-] EventCollection.getCataloguedEventsAsXML needs to accept filtering parameters to limit the events returned. [-] Create an EventMemento base type for DataEntryTransaction and EventToXMLTranslator. [-] Method for extending Panels in the StatusConsole package is clumsy -- in particular, the dialogs that get created for derived Panels have difficulty finding the objects which they are supposed to manage. Need to write further documentation on how to create custom panels, and especially how to let the dialog boxes interact with the back end. [-] Make sure that the permission sets that are applied to Calendar Admins are different from Site admins, and that the "visitor" users have all/only the permissions they need also. [*] Add Indexed, Mandatory and User-Visible attributes to FieldSpecs [*] Need a MultiValue DataType (or ContentType?) [-] Fix the CSS class applied to erroneous input fields in Cocoon. [-] Need to set up a SearchWidget, which contains a bunch of NamedCriterion objects, grouped under a single name, and which each perform one match, e.g. 'Location = Campus'; this SearchWidget should be editable without having to add each individual NamedCriterion ... it should just be edited as a plain old list, and the NamedCriterion objects would be generated for each item added to the list. [-] Add NumericRangeCriterion [-] Need to be able to edit all NamedCriterion objects. [-] The FieldLink of a NamedCriterion should be displayed via the English name of the field, not the field id [-] Change the 'ThisCalendar' NamedCriterion to be named after the Calendar itself [-] Consolidate all frontend communication into a single FrontendEntryPoint; Create an XmlRpcHelper module to handle all XMLRPC, create an XML subpackage to contain XmlSerialize and XmlRpcHelper. [-] Split out internal object indexing from the indexing of Events [-] Refactor FieldSpec so that the various subcomponents are stored in the ZODB rather than as simple subobjects, and make the various subcomponents findable via acquisition. [-] Check on adding different validation plugin schemas, e.g. LDAP/SMB/Local User lists ================================================================================================== Need Testing List ================================================================================================== Ideas/Issues List [*] What about situations where an event type has been defined and is being used by a variety of calendars. Should a change to the master event type then affect all the calendars that have been using that event type? * Resolution: Each Calendar owns a set of EventTypes, which other Calendars can share. However, the owner is the one who is permitted to change the definition of the EventTypes at will, and any other Calendars admins who use these EventTypes need to be aware of this possibility. [*] Where does the XSLT get stored? For example, there needs to be different XSLT for administrators versus anonymous users, and different XSLT for single-event views versus multiple-event views. * Resolution: XSLT is stored in the Cocoon frontend, in the form of "intermediate-to-{final format}.xsl" XSLT stylesheets. XSLT itself is too complicated to allow Calendar Admins to modify. Instead, Calendar owners can define Templates for their Calendars using the Intermediate Template Language, which is very similar to HTML, and can style the resulting documents using Stylesheet objects (which is in fact just CSS). [*] How about basic XSLT for normal views, then based on the ViewMode, different XSLT gets applied to generate additional capabilities in the final presentation (i.e. XSLT that adds "edit" buttons to the standard, plain-jane presentation that most users gets)? * Resolution: The Intermediate Template Language defines Tool tags, which allow the Admin to specify that widgets should be included in the output document. Multiple Templates are then defined, with different tags for different purposes; e.g. a List-View template for a standard read-only list view of the Calendar, versus an EventEntry Template for entering new events. [-] Cocoon frontend navigation * A session should always be available for the user... if there is currently no session, one should be set up, and the user should be set as the default web user. * The calendar should have a "login" button available for display via the MTL calendar-header tag; When this button is clicked, a login popup should display, which will be generated via an XSP page which manipulates the session table to set the logged-in user name (if authentication is successful). Similarly, a logged-in user will get a "logout" button. * Whatever user name is set as the currently logged-in user will be sent to the Zope backend by the sitemap's http://username:password@URL syntax. * There should be an action that finds all of the search widgets and concatenates their values as a single "criteria" parameter value. * Other information that the sitemap needs includes: Calendar name, Template, Stylesheet, and output format. Perhaps all of these values should be tracked in session variables; thus, upon the first visit, when Cocoon detects that a new session needs to be set up, it will fill these variables with default values, which it can pull from the Zope backend. The basic Calendar setup Action can request a number of default values from the backend, such as the name of the default web user, and based on the current web agent, a default Template, Stylesheet and Output Format can be provided by the backend. * The Calendar will probably be chosen by matching the URL * Perhaps an action-set can be set up that will do the following things in order: 1) Set up a new session if none exists, with default values for everything 2) Concatenate the SearchWidget values into the "Criteria" variable. 3) Change the Calendar, Template, Stylesheet and Format variables if anything of these are found in the HTTP request. 4) An XML Event list is created for the pipeline using a Generator; this generator is fed the Stylesheet, Calendar, Criteria and User/Password variables. 5) Using a Selector, run the appropriate Transformer for the Format type requested (HTML, PDF, etc) 6) This Transformer is itself generated by another Pipeline, which uses the Template variable to fetch a Template from the backend, which then turns this template into an appropriate Transformer via the intermediate-to-***.xsl stylesheet. By this time, this Pipeline can automatically fetch all needed parameters from the Session, since the top-level Pipeline will make sure that all necessary variables are already set.