This is the changelog for the MightyCal Cocoon frontend. $Log: CHANGELOG,v $ Revision 1.6 2003/02/16 08:58:26 enorvelle * Fixed problems with the Month.java and MonthCalendar.java classes, which were producing DTMDOMExceptions and NullPointerExceptions, as a result of the fact that the Apache project "secretly" changed the underlying DOM representation from a standard W3C DOM to a DTM DOM (see http://xml.apache.org/xalan-j/dtm.html for more info). The new DTM representation of DOMs does not allow any modification of the underlying DOM, including no creation of new Nodes or Elements, or importing of DTM-based Nodes into standard DOM documents. In order to get things to work, I had to re-implement the addChild() method to perform a manual (recursive) addition of a DTM based child node into a standard DOM document. Clumsy, but it works. Revision 1.5 2003/02/13 01:33:44 enorvelle * Added method for letting the user change Calendar attributes: the MTL language now provides tag attributes for the tags that indicate which Calendar attributes should be changed... e.g. would create an output link that would let the user change to the List View template * Created UpdateCalendarAttributeAction.java to listen for request parameters indicating that the user wishes to change Calendar attributes. It updates any changed attributes in both the Sitemap parameters and the Session. * Added the new UpdateCalendarAttributeAction as an Action named "update-calendar-attributes" in the Sitemap, and created an Action Set that includes the "load-calendar-attributes" Action and "update-calendar-attributes". This action set is called "calendar", and replaces "load-calendar-attributes" in the Calendar matcher. Revision 1.4 2003/02/10 09:14:48 enorvelle * Fixed mtl-to-html (and sitemap also) to allow for proper referencing and fetching of image and CSS files. Revision 1.3 2003/02/04 07:25:03 enorvelle * GenerateCalendarAttributeAction is a single Action replacement for the entire "calendar" ActionSet. Its main purpose is to avoid the problem of relying upon Session attributes for all Calendar generation... Session attributes are not available until the user agent's second request; therefore this new Action provides *both* Session attributes and Sitemap parameters. The Session parameters are just used to persist user choices between page views, but the Calendar can still be generated even if the browser does not provide cookies. * Removed section and the section; Session attributes are set automatically by the GenerateCalendarAttributesAction, and the XMLRPC commands are set as constants in the Java source files themselves. * New sitemap configuration disposes with nearly all custom Actions and all custom Generators and Transformers, instead relying on builtin Cocoon generators/transformers, along with Sitemap parameters to configure them. Revision 1.2 2003/01/29 06:41:16 enorvelle * Added new MtlTransformer, which pulls MTL templates from the backend and turns it into standard XSLT, which then can be used to transform the Event sets in order to produce Calendars. * Also modified the Calendar matcher in order to draw its transform from a cocoon:/ internal pipeline, which in turn uses the new MtlTransformer to generate the XSLT for producing the Calendar. Revision 1.1.1.1 2003/01/23 20:23:50 enorvelle New revision of Frontend Revision 1.21 2002/12/20 13:08:06 enorvelle * Got submit-event.html.xsp to the point where it can request a DataEntryTransaction, request the field IDs for that transaction, and generate an event edit form out of the widgets that the DataEntryTransaction provides. Event submission is not working as of this point. - A point to be made about getting the widget generation to work... I needed to use the tag in order to tell Cocoon that the content being inserted was valid XML, (in this case, HTML 4.0) which should be included in the output as tags, not as text. This is an undocumented tag... the syntax I used for getting it to work was found on the Cocoon-users mailing list. Revision 1.20 2002/12/20 03:54:42 enorvelle * Modified sitemap to use basic authentication (i.e. including username/password in the URLs) for fetching data from the backend * Added XmlRpcProxy Java class in order to remove XMLRPC functionality from the submit-event.html.xsp server page, and encapsulate it instead in an object-oriented interface that hides repetition and complexity from the XSP code. * intermediate-to-html.xsl now imports the eventId HTTP parameter (if present) as the $event-id variable. This is needed in order to generate buttons that send the user to the event-editing interface (i.e. submit-event.html.xsp), which needs the event id. * In field-handlers.stage1.xsl, added event type, event id, and MightyCal instance values as hidden form variables, to , and changed its rendering to include a
whose submit button directs the user to submit-event.html.xsp * Restructured submit-event.html.xsp around the new DataEntryTransaction model of entering and editing events. Now the first thing that this XSP page does is attempt to discern whether we currently have a valid DataEntryTransaction in progress. - If there is not, it creates one (either a blank one, if we have no Event ID, or a transaction whose values are from an existing Event). Then, it will display the various widgets and create a submit form allowing the user to modify the Events values. The Form action redirects the user back to the submit-event.html.xsp page, but this time all the input fields will have values. See next step. - If there is a DataEntryTransaction in progress, it will try to submit the Transaction using the field values it has gotten from the HTTP POST (i.e. in this case, the DataEntryTransaction is in progress because we are returning to submit-event.html.xsl as the result of a prior form submit). If the submit command succeeds, the user is informed of success, and given the opportunity to return to the Calendar display. Otherwise, the Event edit form is re-displayed with invalid fields highlighted. The process repeats again. Revision 1.19 2002/10/14 13:57:21 enorvelle * Updated all intermediate-to-*.xsl stylesheets to handle the new tag. Each format now gets a calendar header section that is appropriate for its limitations. The HTML presentation allows for a calendar logo, a calendar title, and navigation widgets (at this time limited to links to other formats/templates). The PDF presentation just prints the calendar title. The Avantgo presentation prints the calendar title and links to other templates, but no links to other formats. Revision 1.18 2002/10/12 14:26:22 enorvelle * Modified submit-event.html.xsp to properly recognize the status codes and error messages gotten back from its XMLRPC call. * Added handlers for and Intermediate tags Revision 1.17 2002/10/10 21:13:14 enorvelle * Added submit-event.html.xsp, which is an XSP page that collects the user input from an event edit/submission page and sends it to the Zope backend using XMLRPC; depending on the results, it either prints a success message and OK button, or prints the errors that were received from the Zope backend, and a "Back" button that allows the user to edit problematic fields * Updated handler for in field-handlers.stage1.xsl, so that the form, when submitted, sends its info to submit-event.html.xsp * Added a handler for Intermediate tag. * Updated the sitemap to locate XSP pages, specifically submit-event.html.xsp Revision 1.16 2002/10/05 14:07:13 enorvelle * Created a Stage 2 handler for tags, so that the widget that gets requested from the backend can be specified to be filled with the value from a specified event. Event IDs aren't known until stage 2, so the handler had to be moved from Stage 1 to Stage 2. * Added navtrack.js, which deals with remembering the navigation trail of a user, so that navigation buttons and widgets can send him back where he came from in an intelligent manner (i.e. the third stage of a navigation trail should send a user back to stage 2, not to stage 1). Revision 1.15 2002/10/03 18:44:47 enorvelle * Added handler for Intermediate tag, which contains a matrix containing tags. The matcher for wraps the matrix in an HTML tag, with an "action" attribute that will allow for submission of the event to the proper location. * Added handler for tag, which talks to the Zope backend in order to fetch an appropriate edit widget for the given field type. * Added handler for tag, which generates an HTML button that redirects the browser to a page that allows for editing an event. Revision 1.14 2002/10/02 21:28:31 enorvelle * Modified MonthCalendar.java to handle the fact that event date values are now contained within a subnode of nodes. * Moved the various intermediate-to-{output format}.xsl stylesheets into their own eponymous directories, so that it will be easier to cluster related included stylesheets in one location. * Broke out a number of chunks of the intermediate-to-*.xsl stylesheets into included stylesheets, to simplify the master stylesheet. Labeled each included stylesheet as to whether it gets included at stage 1 or stage 2 of Cocoon generation pipeline. Revision 1.13 2002/10/01 22:56:49 enorvelle * Added support for the Intermediate-language tag and the , and elements that it generates as abstract layout elements. Revision 1.12 2002/09/26 13:18:17 enorvelle * Completed sitemap modifications for requesting a single event. Instead of trying to request a Template directly from an EventType, we instead look for the Template from the Calendar instead. This is because there were too many differences in the way that EventTypes put out their Templates (namely, without sections, which the intermediate-to-xsl stylesheets rely on). Revision 1.11 2002/09/26 10:21:39 enorvelle * Modified intermediate-to-html.xsl to properly generate a hyperlink to an event when the Intermediate template contains a tag. This functionality isn't needed in intermediate-to-pdf.xsl, since we don't support hyperlinking from PDF docs. * Added several matchers to the sitemap to deal with requests for individual Events. Revision 1.10 2002/09/25 11:53:27 enorvelle * Fixed problems in Month.java which resulted in incorrect calculations for the day that a month begins, and which caused the days to be numbered incorrectly. * Month.java now generates the first tag of a month with elements, rather than elements. * Modified both the HTML and PDF generating style to handle the new tags, which are output using a different set of CSS/FO properties from tags, and which also don't include any tag, since no elements can be children of a * The intermediate-to-pdf.xsl stylesheet now generates the section using dynamic style attributes, so that the administrator will be able to specify page dimension and margin properties, as well as other global properties, such as header/footer properties. Revision 1.9 2002/09/24 01:14:10 enorvelle * Finally got the intermediate-to-pdf.xsl stylesheet to handle the tag properly. Revision 1.8 2002/09/18 12:38:10 enorvelle * Completed implementation of edu.arizona.MonthCalendar.java, which functions as a Xalan extension class. Given a set of events, MonthCalendar will create a set of elements, each of which has the appropriate number of nodes. The nodes contain nodes, with a "day-number" attribute. If there are any events for a particular day, then that element will have nodes as children. This set of elements can be iterated over, and its and can be formatted in a manner appropriate for the output method that is being targeted (e.g.
s for HTML, and for PDF, etc). * Added a new stylesheet called intermediate-to-avantgo.xsl, and put and entry for it into the sitemap. A separate stylesheet seems necessary, since Avantgo can only read HTML 3.2, and thus we have to use actual HTML tags for formatting, rather than

tags with associated CSS styles. It may be possible at some point to merge this new stylesheet with intermediate-to-html.xsl, but for right now, I am keeping it separate so as not to muck up the latter stylesheet. Revision 1.7 2002/09/14 04:36:08 enorvelle * Added edu.arizona.MonthCalendar class to handle date calculations for displaying the month-view calendar format Revision 1.6 2002/09/10 23:57:04 enorvelle * Modified both the HTML and PDF generation routines so that the resulting documents take their styling from the Zope backend. - In the case of HTML files, this simply required the insertion of a tag in the section which requests a CSS stylesheet. The HTML user agent will ask Cocoon for this stylesheet, and Cocoon will get it from the Zope backend. - In the case of PDF files (and by extension, any generated file that uses XSL-FO) a number of XML-formatted "attribute-sets" have to be embedded in the stylesheet produced by intermediate-to-pdf.xsl. When the final PDF file is generated, the various pieces of the document get told to take their attributes from one or another of these attribute sets. In this case, the embedded attribute sets are also fetched from the Zope backend, which can produce a stylesheet either in CSS format, or in the XSL attribute-set format. Revision 1.5 2002/09/05 07:20:22 enorvelle * Reworked the sitemap to take a slightly modified URL for retrieval of a calendar: http://[computername:8080]/mightycal/[MightyCal backend instance]/[Calendar name]/[View format].[Stylesheet].[Document type] - The new URL format includes a Stylesheet segment, the contents of which are passed on to the intermediate-to-html/pdf.xsl stylesheet, which then uses that information to reference the stylesheet content in the backend. In the case of HTML documents, the generated document has a element in it that fetches and embeds the CSS-formatted stylesheet. In the case of PDF documents, the stylesheet parameter is used to find the XML document in the backend that specifies formatting information for the elements in the XSLT document. * Pruned a bunch of old directories and purged them using "cvs ci -P" Revision 1.4 2002/09/03 00:02:07 enorvelle * Deleted some files from the docs subdirectory that were left over from MultiPub, the application I copied this Cocoon application from. * Replaced the xercesImpl-2.0.0.jar files with xerces-2.0.0.jar, which is the same file under a different name. I told CVS to delete the old file, which it kept corrupting every time I did a CVS commit. * Minor changes were made to the sitemap to make sure that it gets its Intermediate Templates from the correct place, i.e. from the Template object in the Calendar's TemplateCollection. Revision 1.3 2002/08/08 15:05:40 enorvelle * Uploaded new version of Xerces library to fix corruption issue * Added an intermediate-to-pdf.xsl stylesheet to generate list-formatted PDF * Added entry in sitemap to allow client browser to request CSS via Cocoon frontend Revision 1.2 2002/08/07 10:53:38 enorvelle * Created the intermediate-to-html.xsl stylesheet, which generates an XSLT stylesheet that can be applied to an EventCollection dataset in order to produce an HTML-formatted page. * Set up the sitemap so that requesting a calendar results in Cocoon calling itself to generate a dynamic XSLT stylesheet based on the current Intermediate template supplied by the Zope backend. This means that administrator changes to the templates in the Zope backend get immediately reflected in new XSLT templates used by Cocoon. Revision 1.1 2002/08/02 04:22:52 enorvelle * Fixed a runtime bug caused by a corrupt xercesImpl-2.0.0.jar file. * Fixed settings in web.xml that incorrectly set logging targets, resulting in no logging being done for the servlet. * Changed the sitemap.xmap file to include two pipelines that draw from the Zope backend: an HTML producer and a PDF producer. The pipelines operate when the user requests a URL in the following form: http://[Cocoon-host]:8080/mightycal/[MightyCal Zope instance]/[Calendar Name].html (or .pdf)