Enhanced Event Specification Language

[GoogleCodeExporter]

Please see 
http://www.theolympicbuzz.info/index.php/OlympicBuzzInfo:Calendar_Syntax_Ex
amples for a proposed syntax for the specification of recurring events. I 
believe this syntax covers the primary iCal standard parameters, however I 
am still confirming that.

My request is to allow this or similar syntax within the content of 
<calendar> elements.

Original issue reported on code.google.com by jmccl...@theolympicbuzz.info on 25 Feb 2009 at 7:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Moved to 
http://www.theolympicbuzz.info/index.php/OlympicBuzzInfo:Calendar_Event_Syntax

Please note that Google is breaking URLs...

Original comment by jmccl...@theolympicbuzz.info on 25 Feb 2009 at 7:21

[GoogleCodeExporter]

I've added some simple preliminary changes to the trunk branch. Its not much, 
but 
its testable. The new function is "Calendar::buildTagEvents($paramstring)".

The call into CalendarArticles::buildEvent(...) will parse according to the 
existing 
rules in most forms. I may have to choose different delimiters so the 'split' 
on the 
single colon doesnt effect "event based" triggers... anyhow... its a small 
start for 
inline events

<calendar>
2-25-2009:EVENT!!:some data
2-25-2009:EVENT2!!:some more data
2-26-2009:EVENT2!!:some more data
</calendar>

Original comment by kenyu73 on 26 Feb 2009 at 1:45

• Changed state: Review

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

No, nothing is removed. I'm just building it as additional flexibility. I don't 
see
the /template modal going away mainly because I use it to hold 60+ rotating 
events
every month and others like the ability to use a sub-page for organization.

Original comment by kenyu73 on 26 Feb 2009 at 6:17

[GoogleCodeExporter]

ok - help me to understand the difference between the /template & the content 
of the 
<calendar> element?

Original comment by jmccl...@theolympicbuzz.info on 26 Feb 2009 at 6:21

[GoogleCodeExporter]

<calendar> element content can be any date really; templates are month/year 
based

Templates are stored long term for reference; element content I see as 
personalized
and short-term; except maybe repeat events. In my case, I wouldn't want to 
erase the
<calendar> element content every month, then add the next 60+ events nor would 
I want
to have 120, 180, etc future events built up for future months...nor do I want 
to
delete previous months...see where I'm going? At the same time, I dont what to 
have
365 "pages" per year of simple "BEEPER: Eric" type events...thats the concept of
/templates. Here an examaple of my monthly events for Feb:
1# BEEPER: SB
2-5# BEEPER: DS
6-8# BEEPER: KL
9-12# BEEPER: KL
13-15# BEEPER: JC
16-19# BEEPER: JC
20-22# BEEPER: EF
23-26# BEEPER: SB
27-28# BEEPER: JC

1# Inbox:
2# Inbox:JC
3# Inbox:KL
4# Inbox:DAB
5# Inbox:EF
6# Inbox:CB
7# Inbox:
8# Inbox:
9# Inbox:KL
10# Inbox:DAB
11# Inbox:EF
12# Inbox:CB
13# Inbox:JC
14# Inbox:
15# Inbox:
16# Inbox:DAB
17# Inbox:EF
18# Inbox:CB
19# Inbox:JC
20# Inbox:KL
21# Inbox:
22# Inbox:
23# Inbox:EF
24# Inbox:CB
25# Inbox:JC
26# Inbox:KL
27# Inbox:DAB
28# Inbox:

These rotation will always be there unless I manually erase them or "bot-erase" 
them
as older pages....

Does that make sense?

Original comment by kenyu73 on 26 Feb 2009 at 6:39

[GoogleCodeExporter]

A shot at answering my own q:
1. The \template has a different date syntax than the <calendar>content
2. A \template is created one for each month; accordingly all events apply to 
the 
same month/year. <calendar>content events can specify any date in any month in 
any 
year

Original comment by jmccl...@theolympicbuzz.info on 26 Feb 2009 at 6:47

[GoogleCodeExporter]

Correct.

However, the <calendar> content syntax is still up in the air. I see a simple 
date
like I have, but complex options like you have in the link you sent me.

The syntax is open for design, but the existing internals that create the event 
need
to be improved, but also remain backwards compatible.

The "CalendarArticles::buildEvent(...)" function is the central function that 
begins
the existing syntax parsing

Original comment by kenyu73 on 26 Feb 2009 at 7:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

With transclusions, I suspect that your concerns can be addressed:
<calendar>{{Feb 2009}}</calendar>
The wiki automatically retrieves the page "Feb 2009" and inserts its content 
into 
the element before the extension sees it. The following month, you'd change to 
<calendar>{{March 2009}}</calendar>

More likely, set up something like
<calendar>
  {{Feb 2009 Recurring and Non-recurring Events}}
  {{2009 Recurring and Non-recurring Events}}
</calendar>

One could go further, and have the name of the page that is transcluded to be 
calculated based on parsing __CURRENTMONTH__ (whatever), so that there's no 
need to 
change from {{Feb 2009}} to {{Mar 2009}}. Even further, one could have 
cascading 
transclusions, where one transcluded file transcludes others.

The SUPREME DISADVANTAGE of your general approach to calendaring (and of the 
suggestion here) is that one cannot go back to see previous months' calendars 
nor go 
forward to see future months' entries, without alot of calisthentics... many 
people 
would not like that at all, for they (like me) are slovens.

Given all that, I hear your desire to minimize the number of entries that are 
processed by the software when displaying a given month, ignoring old stuff and 
ignoring future events inapplicable to the calendar requested to be 
displayed.... I 
think that's an important goal too, and that we should try to ensure that (I 
have 
some ideas on this).

Original comment by jmccl...@theolympicbuzz.info on 26 Feb 2009 at 8:06

[GoogleCodeExporter]

I think transclusion is a great idea if uses want to use the element tag 
approach,
but it's still a manual "wiki-code" operation to perform. I have 10 members on 
my
team who enter sicktime, vacation time and adjust the template events at 
anytime in
the calendar year(s). If someone wanted to add a vacation day to November under 
your
idea they'd have to 
  1) create a new page [[Calendars:Nov 2009]]
  2) add <calendar>{{Calendars:Nov 2009}} </calendar>
  3) enter the calendar event syntax

Or if a {{Calendars:Nov 2009}} exists and is attached to the page as a link on 
the
bottom, they'd then click on that and add the calendar syntax to the already 
made page

After 1 or 2 year of operation
<calendar> 
{{Calendars:Jan 2009}} 
{{Calendars:Feb 2009}} 
{{Calendars:Mar 2009}} 
{{Calendars:Apr 2009}} 
{{Calendars:May 2009}} 
...
...
{{Calendars:Nov 2009}} 
{{Calendars:Dec 2009}} 
</calendar>

Oh wait, now "Mark" wants to see when he took vacation last year in Dec 2008, 
but the
calendar "sysop" removed the older transclusions...
  4) Mark adds {{Calendars:Dec 2008}} back in

Oh wait, now "Judy wants to see what date the summer party was last July...
  5) Judy adds {{Calendars:Jul 2008}} 

This all 'assumes' that Mark and Judy know how transclusion works AND know that 
those
months exists already... what if some users add [[Calendars:July2009]] and 
another
user for the next month uses [[Calendars:2009August]]... there isn't any 
consistency
and we'd have calendar pages all over the place.... its SUPER flexible, but also
super complicated for multiple users to utilize.

My current calendar manages all this... a user doesn't even have to know Wiki 
to use
it... that's my argument to you.... yes this is a 'wiki', but it also needs to 
remain
easy and transparent to users.

Technically, you can create a calendar without php and use wiki-templates and
drill-down transclusions.

The approach you have is completely different then the "Wiki-Application" 
approach
that the calendar is based on currently. You have awesome ideas, some that I'm
already playing with... but... having an tag/element/transclusion based event 
system
isn't what this calendar is...

What is suppose to happen once a user clicks "Add Event"? With transclusion, 
there is
almost no 100% method to determine what {{page}} is the correct page to open in 
the
element tag. If there was, a central page is good only for simple events.. if a 
user
wants something large, then they'd have to create a transclusion event or 
redirect
tag... again complicated.

"The SUPREME DISADVANTAGE of your general approach to calendaring (and of the 
suggestion here) is that one cannot go back to see previous months"

I dont understand this part...? You can go anywhere and all the events will 
always be
there.. forward or back...I can go back and add my birthday in 1973 and it will
always be there... same if I add something in 2015.. it will always be there.

I'm just afraid, like I said, that you're approach is 180 degrees from the 
current
path...

All that being said, we can add transclusion support easily to the element tag, 
but
it's an extra option, not a replacement is my thoughts.

Original comment by kenyu73 on 26 Feb 2009 at 9:10

[GoogleCodeExporter]

Gee -- I was not saying transclusion only (and incidentally, it's Mark/Judy's 
fault 
for having removed those files in the first place), I was saying the content of 
the 
<calendar> element can include transcluded-pages in addition to or in 
replacement of 
other content within the element. I was merely addressing what I took to be the 
gist 
of the concern you raised: requirements for managing calendar data. And of 
course 
Add Event wouldn't search for and update a transcluded-page. In fact, as we've 
already discussed, it should merely insert text at the current cursor position, 
while editing a page, regardless of whether it is the one that has the calendar 
element, or one that is transcluded.

I agree that your extension today builds management into the system (via one 
template per month) with the objective of avoiding re-/processing 
earlier/future 
info. But that's not the only way to achieve that very worthy goal. And what's 
so 
wrong with 30 years of calendar events?
<calendar> 
{{Calendars:Jan 1990}} 
...
{{Calendars:Dec 2020}} 
</calendar>

Hmm, I'm maybe sounding a bit annoyed here, sorry. OK, you're right, my 
approach is 
diametrically opposed to the current one -- it is focused on creating a "wiki 
application" that is scalable. I'm understanding you havent need for 
scalability; 
you have now, and will always going to have, a small user base. Really, I do 
respect 
that -- such specific requirements are what this industry is all about! 

BTW, point taken about past/future calendar entries.

Thanks for the inspirations!

Original comment by jmccl...@theolympicbuzz.info on 26 Feb 2009 at 10:09

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'l going to add some limited transclusion support, but thats really it

Original comment by kenyu73 on 18 Apr 2009 at 2:50

• Changed state: WontFix