ical formatting filter

I've got some slightly crufty code in a site of mine that
handles
generation of ical files - using TT.

One of the things that was tricky about that was getting the
very basic
file format and line wrapping stuff right, and I ended up
producing a TT
filter plugin to do this - specifically to:-
  - Ensures lines are no longer than 72 chars
  - Continuation lines start with a single space
  - Blank lines are removed

I'm about to be revisiting this stuff, and if there is any
interest I
could clean it up a little and put it up as (I guess)
Template::Plugin::IcalWrap

So, is there any interest?

    Nigel.

_______________________________________________
templates mailing list
templatestemplate-toolkit.org
http://lists.template-toolkit.org/mailman/listinfo/t
emplates

On Mon, May 29, 2006 at 06:02:49PM +0100, Nigel Metheringham
said:
> I've got some slightly crufty code in a site of mine
that handles
> generation of ical files - using TT.

Just as an aside (in case you haven't already seen it), you
might also 
want to look at Data::ICal.



_______________________________________________
templates mailing list
templatestemplate-toolkit.org
http://lists.template-toolkit.org/mailman/listinfo/t
emplates

On Thu, 2006-06-01 at 10:33 +0100, Simon Wistow wrote:
> On Mon, May 29, 2006 at 06:02:49PM +0100, Nigel
Metheringham said:
> > I've got some slightly crufty code in a site of
mine that handles
> > generation of ical files - using TT.
> 
> Just as an aside (in case you haven't already seen
it), you might also 
> want to look at Data::ICal.

I know I looked at this (probably at least 9 months back)
and decided
against it for some reason which of course I really can't
remember now.

I may look at using this with my reimplementation I'm about
to do - the
db has changed, so a load of stuff needs to change anyhow. 
The biggest
problem appears to be creating an ical file (other than
really really
basic - ie no repeating events etc) which more than one
client can read
and get the same set of times out of.

It looks to me as though the rules of thumb are:-
      * No timezones - do everything as UTC (Z timespecs)
      * Ideally no repeats.  If you have them then the end
date should
        be set to 23:59:59 on the last date (no idea what
happens if you
        are in a timezone where that pushes you into the
wrong day)
      * Really really try to avoid repeat exceptions. 
Nothing does them
        the same way.

I'll actually codify these properly when I dive back into
this :-/

	Nigel.
-- 
[ Nigel Metheringham           Nigel.MetheringhamInTechnology.co.uk ]
[ - Comments in this message are my own and not ITO
opinion/policy - ]


_______________________________________________
templates mailing list
templatestemplate-toolkit.org
http://lists.template-toolkit.org/mailman/listinfo/t
emplates

On Thu, Jun 01, 2006 at 11:32:51AM +0100, Nigel Metheringham
said:
> It looks to me as though the rules of thumb are:-
>       * No timezones - do everything as UTC (Z
timespecs)
>       * Ideally no repeats.  If you have them then the
end date should
>         be set to 23:59:59 on the last date (no idea
what happens if you
>         are in a timezone where that pushes you into
the wrong day)
>       * Really really try to avoid repeat exceptions. 
Nothing does them
>         the same way.

I've done an extension to Data::ICal called Data::ICal:ateTime
that 
provides convenience wrappers to do things like all-day and
floating 
events and provides methods for dealing with DateTime::Set
and ::Span 
objects as well as (AFAIK) coping with timezone
shennanigans.



_______________________________________________
templates mailing list
templatestemplate-toolkit.org
http://lists.template-toolkit.org/mailman/listinfo/t
emplates