Re: [Wpigdc-cms-development] Events classes checked in

[Dan P. <dp...@WP...>]

A couple of things which'll need to be pointed out...

1) Every CMS source class MUST start with a JavaDoc comment, which MUST
include the following tags:

/**
 * @author $Author$
 * @version $Revision$
 */

This allows auto-tagging of the data via CVS.

2) Please inform me before commiting ANYTHING to CVS that relates to the
DB component - I had to merge your changes back with mine and am likely
going to be changing portions based on new code.  (Also, do NOT print
stack traces in the DB engine - it's now possible to embed Throwable's
into a DatabaseException, so do that instead.  Plus DBIterator is probably
going to be extended to offer error catching services.)

3) Do NOT catch SAXExceptions in your DataSource - there's absolutely NO
need.  If a SAXException is thrown, then it's likely that the entire
response is screwed ANYWAY, and Cocoon should be allowed to handle it
normally.

On Sat, 11 Aug 2001, Liam Morley wrote:

> I removed EventSource from the
> repository, but you can still see it there in the "Attic".

You're supposed to - the file were in the repository and can be retrieved
- just like any version of any file.  I hope to be tagging the repository
as Alpha 1 soon, but the events will probably delay that a week.

> by the way: as far as events go. Dates haven't really been worked out.
> Currently two sets of dates are sent through SAX:
> start-date-long/end-date-long and start-date-short/end-date-short (the
> long versions will give you "March 13th, 2001" whereas the short versions
> will give you "03/13/2001"- the methods I wrote to do this might become
> handy utility methods, in which case eventually we may write a lil utils
> package and throw stuff like this there).

Have you ever checked java.text.SimpleDateFormat?  I think you were
wasting time...  (Speaking of which, it should be simple to change to
allow the source XML to specify the SimpleDateFormat format...)

> I made a few small changes to the schema I set up, largely adding a unique
> string field for URL detection. Here's how that works. Everything in
> either "events", "events/", or "events/*.html" is sent to "events.xml".
> Then, the datasource figures out what the url is. if it's
> past.html, it serves up all past events (to be changed when user
> preferences is firmed up and users can select how many past events
> they want displayed); if the URL is future.html, it serves up
> future events; if the URL ends with events, events/, or events/index.html,
> it serves up a past and future (just like on the index page as it's
> currently implemented). Anything else goes to the event described in the
> URL. for example:
>
> /events/gen_assembly_033101.html
>
> EventSource will look in the database for an event with a "cms_short_name"
> of 'gen_assembly_033101'. If it finds it, it serves the information
> associated with it; if it doesn't, it handles it as a 404. Currently 404
> stuff is handled directly within the EventSource itself (the 404 is caused
> by an exception in the result set, I can probably throw whatever I want
> though in the future when we want to handle stuff like this universally;
> as we're not ready yet, it's going in EventSource). Keep in mind this is a
> virtual 404; it's not actually searching for a gen_assembly_033101.html.
> Such is the miracle of Cocoon... COMPLETELY transparent to the user.

I'm not sure how 404 processing will work... we'll see...  (otherwise this
sounds like a good solution, but I'm not sure I like the "short event
name" idea... whatever.