cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Lianoglou <j...@arachnedesign.net>
Subject Re: Calendar Generator
Date Mon, 22 Mar 2004 05:25:02 GMT
> That is my instinct as well.  Unfortunately, everything seems to use 
> iCal
> (mozilla, outlook, apple iCal) and from what I can find xcal seems to 
> be stuck
> between draft 2 (from 2002?) and draft 3 which may change things up
> significantly if it is ever finished.

Well, I feel like the xcal draft 2 features will be more than 
sufficient for use in cocoon. Thought if there were a draft 3 actually 
in active development, I'd naturally agree it's definitely worth 
planning for.  :)


> So, we are probably looking at
> 1) a generator to transform ical to some intermediate format (probably 
> xcal?) as you note below.  If someone happens to have native xcal 
> lying around, they could then just feed it right into the next steps.  
> By the same token, if someone has a custom non-ical format (i.e., 
> database, exchange server, etc.) they can stick some other generator 
> in here.
> 2) a transformer to take this format and decorate it with calendar 
> data (transforming to yet another intermediate) and
> 3) possibly a utility stylesheet for transforming this to a pretty 
> html format.  The last one would be generally application-specific, 
> but a well designed root stylesheet could go a long way toward 
> simplifying that process.

I would also suggest a serializer capable of producing iCalendar text 
files from an xCalendar SAX stream.


>> This will allow Cocoon to make extensive use of published iCalendar 
>> files from, well, obviously wherever! :)
>
> That'd be great.  In fact, a sample providing a webav location for 
> ical publishing and a few pipelines to view that data would probably 
> be a big hit.

heh... sorta gives me goose bumps... er, hang on, what's that i missed 
on today's shopping list ... "A Life" ... ehem, i see ...  ;)


> One problem I see with the ical/xcal standard is that it's not 
> designed to be a database - for example when selecting one week out of 
> a calendar covering a year you may need to parse (and generate sax 
> for) the whole thing though it would be otherwise unnessary.

well, i had already done some thinking on this one... but first it's 
worth mentioning that any really huge files you feed into any 
particular generator will logically cause a performance penalty of some 
sort... so there's a degree of responsibility of the individual 
managing the content to streamline this info.

that said...

perhaps the generator could filter out the important stuff using 
attributes in the generator tag... i'm picturing something like:

Load whole ical into SAX stream:
<map:generator type="calendar" src="blah.ics" />

Load date range:
<map:generator type="calendar" src="blah.ics" from="2004-03-22" 
to="2004-04-01" />

Load all information from a certain date, on:
<map:generator type="calendar" src="blah.ics" from="2004-03-22" />

Load all information upto a certain date:
<map:generator type="calendar" src="blah.ics" to="2004-04-01" />

Then you can implement special values for use in the from and to 
attributes, like:

today
today +/- 14

month
month +/- 6

year
year +/- 2

where "today," "month," and "year" are always based on the current 
date; and offsets can be specified by using + or - followed by an 
integer.

but maybe that's a can of worms ... ;-)



jL

John Lianoglou | Vice President | ARACHNEdesign
http://www.arachnedesign.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message