Full RRULEs and links

[GoogleCodeExporter]

My users need full rule support, and calendar entries need to support 
links not just text or ticked-text. 

High priority to me; I'm willing to help if you wish. 
Thanks, John

Original issue reported on code.google.com by jmccl...@theolympicbuzz.info on 23 Feb 2009 at 11:01

[GoogleCodeExporter]

What do you mean full links? Like links in the summary text?

Full RRULE may not be quickly done though.... the iCal ISO standard is a large
document and the RRULE conditionals are quick complex. I'm a one man army here 
doing
this (=

I'm not sure if there is a pre-made RRULE php class out there; if not.. I can 
add
more as we go along...what would you like to see improved?

Original comment by kenyu73 on 23 Feb 2009 at 11:18

• Changed state: Review

[GoogleCodeExporter]

I am unable to enter a page-link or url on the summary textline (the first 
line) in 
an event page. Users will wnat to have a direct link to the event's page. Could 
the 
first line be a link spec, e.g., [[:SomePageName#someid|See here]] or 
[http://...html See here]? For templates, I don't know if it's possible to say 
for 
example: 5#[[:SomePageName#someid|See here]] either.

My general thoughts on calendar page structure are these. Bear in mind that I'm 
aiming to field group-calendaring on a large scale. Further, my reading of the 
code 
is that every calendar has one subpage for each event, and has **perhaps** a 
/style 
page, has up to twelve /template pages, one /recurrence page and up to 366 
/Event 0 
pages. Am I missing or overstating anything? And are 
Namespace:Page/Name/EventDate 
pages ever needed? Anyway, my thoughts:

1. <calendar> should be able to identify all its entries without any additional 
pages being created in the database. This scenario is predictable for users who 
don't want anyone to subscribe to their calendar. Unnamed calendars should be, 
by 
default, unsubscribable -- the "Public" default is not a good idea in this 
context.

2. "FullSubscribe" causes updates to a (single?) subscribed calendar, not to 
the "named" calendar; the "named" calendar has no events itself (?). So I 
wonder 
what transcluding a calendar would do? Wouldn't 
{{calendar:MyUpdateableCalendar}} 
achieve the same thing?

3. The code uses an iterative approach to locating calendar subpages -- can 
they be 
found by direct lookup of links to referring pages? I am concerned about the 
impact 
of "maxdailyevents" on the existing process: what happens if events 2,3,4 are 
deleted, but events 5,6,7 are earlier/later created? 

4. /Template page - I am concerned that 12 template pages can clog the database 
& 
lower performance. I suggest that /Template pages should allow the year and 
month to 
be entered; missing date components should be inferrable from earlier input or 
from 
the current date. (Your use of the 'dash' for dateranges causes problems with 
dates 
in the yyyy-mm-dd format and its variants -- I think the ISO standard for 
duration 
expressions should definitely be adopted.)

5. Cookies - Could you explain what these do. I am having $mode problems and 
the 
code appears to be looking in cookies for info related to the mode for a 
<calendar>. 
And unfortunately subpages don't seem to be working for me yet. My code is
<code>define("NS_CALENDAR",100);
define("NS_CALENDAR_TALK",101);
$wgExtraNamespaces[NS_CALENDAR] = "Calendar";
$wgExtraNamespaces[NS_CALENDAR_TALK] = "Calendar_talk";
$wgNamespacesWithSubpages[NS_CALENDAR] = true;
</code> 

I'll address RRULEs later.

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 1:51

[GoogleCodeExporter]

I just saw the 2 'tricks and tips' you've posted on this topic -- to use 
#REDIRECT 
and transclusion.... I don;t think these will work because of the external URL 
link 
that's needed, not to mention that some users are not too sophisticated.

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 2:13

[GoogleCodeExporter]

The 1st line of the page (\n), up to the max charlimit, is a link to the page 
itself. I'm still confused with what you want here, sorry. Once the eventlink 
is 
clicked it brings you to the page where it's standard wiki... are you 
requesting to 
beef up the text in eventlist mode to have full Wiki-Markup?

1. The calendar knows what pages to look for, but it's doesn't have a list of 
pages 
created, thats what the logic loops through iteration numbers 0-5. However, 
these 
pages are NOT created, it only checks to see if they exist. It acually stops 
the 
iteration lookup once it hits its first (page not found). No pages are created 
unless an event is created. Erased/blank events are reused in the iteration 
lookup 
to save space.

2. Yes, using {{...}} could  work though I never tried it. Using Fullsubscribe 
allows the subscriber to choose their own colors/styles and decide to display 
the 
remote calendars templates.... plus, Fullsubscribe will still display the local 
events if it was used prior to Fullscribe mode... just more flexability. 
Security 
wise, its a back door if the other calendar is in "lookdown". Its only 
face-value 
security though as you'd need to put a users calendar in a restricted namespace 
for 
full security.

3. I think I explained this in #1

4. Some good valid points here... I picked up the calendar work from the last 
user 
[[User:Simsong]] to only get it to work from my Company... I tailored it on the 
fly 
and decided to spread the wealth of my work... but alot of poor ideas in the 
beginning need to be re-worked maintaining backwords compatibily. I dont like 
alot 
of delimiters that I choose.... /= I'll be back in this area within a few weeks 
I'm 
sure

5. The cookies control the dates as the user toggles thru the months/years. It 
also 
includes the wikpage and calendarname as to not overwrite another calendar that 
may 
be visited. The modes use the same principle as the month/year toggle... when 
the 
page is refresh, the initialization looks for the "mode" and builds the 
calendar as 
needed. If your month/year toggles are working, so should the modes. If neither 
are 
working, then cookie security is blocking them from being written in some 
fashion.

I'm not sure about your defines... I use the actual numbers as described in the 
help 
and it works fine for both my Windows workstation I test with and my company 
Linux 
VM.

As for RRULEs... don't hold your breath, haha, as the ISO standard is MANY 
pages 
long and I dont expect to be full complaint anytime soon unless I find a simple 
php 
VCAL class out that is already VCAL complaint including RRULES. I hacked in the 
basic iCal tool for basic use only... holidays, birthdays, etc... I'm working 
this 
solo and for free so I'll do my best.

Thanks for the feedback, its much needed. I want nothing more then to have the 
best 
Wiki Calendar out there.. which I think I do.. but I want it to be better also!

Eric

Original comment by kenyu73 on 24 Feb 2009 at 3:05

[GoogleCodeExporter]

"Once the eventlink is clicked it brings you to the page where it's standard 
wiki... 
are you requesting to beef up the text in eventlist mode to have full 
Wiki-Markup?"

True, but the page is named -Event x, not "My Birthday Party". To get the link 
to my 
Party page requires a REDIRECT, which is not a feasible mechanism. I am 
requesting 
that text in a template be any valid inline wiki text, meaning that 
[[pagename]] is 
the link to be displayed in the calender as an event-label. And assuming 
interest in 
establishing that the content of a <calendar> can be the user's 
(unsubscribable) 
event list, then that should also be any valid wiki text.

1. Hmm, your answer applies to #3, not my #1 comments...
2. Interesting thoughts - I'll give this a try and let you knwo.
3. -Event x files seem unnecessary to me. Event-specs located in <calendar> 
content 
and in the /template can specify the strings or links to be displayed. I guess 
I 
don't understand why -Event x pages are needed in the first place ... i18n 
overkill?
4. Good - I've got some ideas on syntax for the <calendar> and /template to 
share 
with you.
5. Yes, I think there are other ways instead of cookies. Cookies can be blocked 
(for 
good reasons) and hence should not be relied upon.
6. I'd be happy to join/help the project if you want it. I'd be interested in 
doing 
the RRULES piece and being sure the ical import works well. I'm wondering about 
having an /ical to which the /template is translated when it is stored; the 
working 
database for the extension is built from /ical plus <calendar>content</>. 
The /recurrence data might be eliminated in the process.

The work you've been doing lately is great; I agree that <calendar> can be the 
best 
out there. 

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 8:14

[GoogleCodeExporter]

Even if full RRULE support is unlikely to happen in the near future, there are 
features that are certainly more important than others. For instance, simple 
weekly/
monthly repetition within a given interval would cover lots of use cases.

As for existing implementations, I wonder if this one is of any use (a result 
of 
quick googling):

http://phpicalendar.net/

Original comment by patai.gergely@gmail.com on 24 Feb 2009 at 12:35

[GoogleCodeExporter]

John

We almost need a meeting to review everything your proposing, haha. Actually, 
we need
to break this post into main focused topics. Can you review what we've 
discussed and
create new focused topics? If you want to just generally talk about anything or
brainstorm, email me please (kenyu73@gmail.com).

Recurrence events really cant be "imported" or the page eliminated. If a user 
wants a
repeating birthday, what would you do.... create 100 pages for that day to 
cover all
events in the future? However, if a different modal was created that didn't 
depend on
event x lookups then that could change. I can see how the MW API has the 
ability to
lookup events easily in its namespace, but I dont know of any logic that I can 
use
the can smartly "know" which events below to each calendar (without a SQL 
modal).
Don't forget that you can have multiple calendars per page.

Cookies are required to use MediaWiki, so says the login screen. I'd love to 
change
the calendar from cookies to something else. I did have sessions setup, but they
interfered with MediaWiki... if you look at my Changelog on the MW site, you 
can see
when I switched back to cookies.

Original comment by kenyu73 on 24 Feb 2009 at 1:44

[GoogleCodeExporter]

John

Actually, I may be able to use prefixIndex and omit the "event x" portion... 
the date
is still required as we'll need to know where the events are suppose to go.

However, having a new event wikipage called "Birthday Party" isnt possible 
unless
code is created the pops up javascript, asks for the event name... and then
concatinates that to the prefix...so it would still be ugly...
Calendars:Family/Public/My Birthday/2-22-2009.

This is assuming I'd use "Family/Public" as a prefix search in the Calendars
namespace; then split/loop though the datestamp.

Original comment by kenyu73 on 24 Feb 2009 at 2:48

[GoogleCodeExporter]

I'm currently testing prefix searching... looks promising...

public static function titleSearch( $search, $limit, $namespaces=array() )

$calendar->prefixSearch = PrefixSearch::titleSearch( 
$calendar->calendarPageName,
365, array('calendar'));

Original comment by kenyu73 on 24 Feb 2009 at 3:58

[GoogleCodeExporter]

I think a conf call could be a good thing.

"Recurrence events really cant be "imported" or the page eliminated. If a user 
wants 
a repeating birthday, what would you do.... create 100 pages for that day to 
cover 
all events in the future?" ...No - the spec for the repeating bday would state 
only 
one label for the event; the spec would be located in the <calendar>content</> 
and 
or in the /ical file. I suggest that if a user wants a different link in the 
second 
year, then they'd have to go in and change the link manually. If the user 
wanted 
both links simultaneously then a recurring event cannot be used. However I 
suspect 
users would instead have a page called "This Years Bday Party" that transcludes 
date-
specific pages to their hearts' desire, and THAT page would be the one in the 
event-
label displayed by the calendar for that date.

I am thinking of a function that takes as inputs (a) <calendar>content</>  (b) 
the 
content of named calendar's /ical page (c) <calendar>content</> of all 
subscribed 
calendars (d) the content of all subscribed calendars' /ical pages. The 
function 
outputs a table of iso-date/event-label columns.

I think mainly about the event's page being created beforehand, and then added 
to 
the calendar. Is your view that event pages are created in the context of 
creating 
the calendar? I also think about sections on a page describing a set of 
activities, 
each section being the target of a link placed into the calendar for a date -- 
a 
very common layout for my users.

With regard to contacting you directly, Eric, it'd be ok to noodle strategy 
together 
but let's keep discussion in the open for others (like patai.gergely - thanks, 
I'll 
look!) to add/embellish/forewarn/scold us about. :} -- Thanks for the feedback, 
it's 
more than I expected! John

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 5:17

[GoogleCodeExporter]

TestPage/Family/My Birthday/20090225
Calendar:TestPage/Family/My Birthday/20090225

I've done the initial testing for this and it works well... I've implemented a
JavaScript function to prompt and populate the "Event Name" (My Birthday).

Basically, the format would be "NS:Page/Name/<userdefined event>/yyyy/mm/dd"

The prefix will be "NS:Page/Name" to lookup the events, then php logic to split 
the
eventname and date...comments?

Original comment by kenyu73 on 24 Feb 2009 at 5:46

[GoogleCodeExporter]

Incidentally, I'd shy away fron session data too, storing that table I 
mentioned 
into a 'hidden' page for best performance, named eg calendarname/tempcal. 
Whenever a 
new version of the calendar is saved, the code recalculates the 
calendarname/tempcal 
page during re-display processing. Race conditions can occur for named & 
unnamed 
calendars, causing some editors to reenter their changes, so the code would 
need to 
embed the /tempcal's timestamp in the calendar displayed which is compared to 
the 
timestamp for the /tempcal page (if the latter is older, then the user needs to 
re-
enter their changes). A third column may be good, to identify the source of 
each 
event -- the page containing the base or subscribed calendar-- so that re-entry 
of 
changes to a base calendar would normally not be necessary. I'd also suggest 
that 'special' rows be added to the table for the timestamp of the base & 
subscribed 
calendars used to create the table.

So the bottom line of my suggestions is that a design that envisions fewer 
calendar 
subpages seems quite possible -- I'm seeing only two subpages right now -- 
/ical 
and /tempcal. I guess I'm on the fence about whether the /ical subpage would 
include 
the <calendar>content</> translated into ical statements, or not. If so, when 
an 
ical file is uploaded to a calendar, then its ical statements could be 
translated 
into <calendar>content</> statements (replacing or appending to existing 
statements 
in the content), which is translated to an /ical subpage, which is translated 
to 
a /tempcal page, which is used to format the view.

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 6:31

[GoogleCodeExporter]

Help me understand why the date-subpage is necessary 
("NS:Page/Name/<userdefined 
event>/yyyy/mm/dd") and why the <userdefined event> needs to be part of the 
subpage 
hierarchy. Thanks!

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 6:35

[GoogleCodeExporter]

Oh, the "style" page is useful too. But maybe specifying style=pagename on the 
<calendar> element should be enough? I'm not clear why style directives need to 
be 
on a subpage.

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

[GoogleCodeExporter]

If a date is not supplied into as a subpage title, then how would the logic 
determine
which date the event belongs to? Actually the date subpage would be "yyyymmdd". 
The
<userdefined> subpage would become the "eventname" instead of line 1 of the 
body.

If I don't use cookies, the calendar will loose its place if the user navigates 
to an
event page.... then comes back... say they want to add 5 events in Dec 2009... 
the
date would reset back to today each time.

Styles pages are not created until a user defines it... most users wont even 
define
one. Setting a style=<pagename> is very possible, but users will have to dig 
into the
Readme to figure it out the parameter... not they dont anyway to get the 
syntax. My
concept was user tools out in the open, not secretly hidden in tag parameters. 
Make
sence?

Back to your question about radio buttons instead of push buttons... It does 
clutter
the screen and that is why I got rid of the "week" button. It was easier to add 
a new
button then recreate and add radio-buttons...thats a good ToDO for sure.

We need to break this conversation down into sub-topics... I'm getting lost
already!!! hahah

Original comment by kenyu73 on 24 Feb 2009 at 7:08

[GoogleCodeExporter]

Having multiple **named** calendars on a page works for the 2-subpage model if 
their 
subpages are named pagename/calname/ical & pagename/calname/tempcal.

But I've proposed that **unnamed** calendars are not subscribable, and multiple 
**unnamed** calendars on a page suggests that the 2-subpage model I've proposed 
falls apart, because the root page for those two subpages could only be the 
name of 
the page containing the unnamed <calendar> elements. 

To handle this, I suggest that unsubscribable calendars have NO subpages. 
Rather, 
their subpages are virtually created every time the calendar is to be 
displayed. By 
this approach, the ical file uploading works great for unnamed calendars -- 
because 
the ical statements are first translated to our calendar statements -- those 
would 
be stuffed into the content of the unnamed <calendar> element on a page.

This has brought up for me the belief that if a user is merely viewing a 
calendar 
that is composed of other calendars' entries (probably a large percentage of 
cases) 
then there is no reason to create ical/tempcal subpages for that (unnamed OR 
named) 
calendar. In fact, a parameter "viewonly" can indicate exactly this. 

(And I would suggest that the week/month/simplemonth/year params be the 
possible 
values of a "view=" parameter, to emphasize that these are mutually exclusive 
choices.)

OK enough you're saying! I can split this up into separate requests, but I'd 
like to 
know your opinions about the general direction here, so that I'm not wasting 
any 
time focused on dead-ends. Thanks!

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 7:27

[GoogleCodeExporter]

No-named and same-named calendars on one page are basically clones of each 
other.
Some users combine two of the same-named calendars on one page to create a 
month view
and a 90-day eventlist next to it.

Creating a basic <calendar /> tag must remain the a fully functional basic 
'Public'
calendar.

Having the following creates a basic client/server calendar that pulls all data 
from
the remote calendar, including iCal events. 
    <calendar fullsubscribe='some page name' />

If you looking to have a central repository for most users, then we can 
approach a
tag like: <calendar repository='Calendar:Repository'/>

The code would then subpage to /ical and /itemp or whatever as needed?? 

Does this sound like what you need or am i way out in left field?

Original comment by kenyu73 on 24 Feb 2009 at 8:15

[GoogleCodeExporter]

FYI. MediaWiki Calendar (http://www.mediawiki.org/wiki/Extension:MWCalendar) 
places 
event information between its opening & closing tags (rather than in a 
/template):

<MWCalendar Display="1" Month="8" Year="1978">
1978-08-13:::Eric's Birthday!</MWCalendar> 

Supported formats for <MWCalendar> content:
YYYY-MM-DD ::: Data: For One Day
YYYY-MM-DD ::: YYYY-MM-DD ::: Data: For Range Of Days
%YYYY-MM-DD ::: Data: To omit one day of data. 
YYYY-MM-DD E xD ::: YYYY-MM-DD ::: Data: Every x days within range. 
YYYY-MM-DD E xW ::: YYYY-MM-DD ::: Data: Every x week(s) within range. 
YYYY-MM-DD E xM ::: YYYY-MM-DD ::: Data: Every x month(s) within range.

Original comment by jmccl...@theolympicbuzz.info on 24 Feb 2009 at 10:28

[GoogleCodeExporter]

I suggested above to create a table of events built from an /ical 
representation of 
<calendar>content -- a table that is stored in /tempcal, which can be used 
directly 
without recalculation if the pages' dates are alright (ie date(/ical) is 
earlier 
than date(/tempcal).  Several thoughts since then.

1. Because <calendar>content needs to be freely convertable to/from ical, there 
seems no compelling need to maintain an /ical subpage. Therefore, the /ical 
subpage 
is eliminated from the proposed design (and the proposed "/tempcal" subpage is 
renamed to "/calendar" subpage). The /calendar subpage contains individual 
calendar 
entries created from the (non-)recurring events within <calendar>content. There 
are 
no other subpages in this design proposal.

2. The function that reads the /calendar subpage needs to have 
dateBegin/dateEnd 
parameters, returning all events that occur during that period (it could have a 
datePeriod parameter, eg 2000-01-01/P1Y retrieves all events during year 2000 
as an 
alternative). The function's caller is responsible not only for identifying the 
proper date-range but also for concatenating events from subscribed calendars.

3. It's been suggested that a wholly new extension be created, considering that 
the 
changes proposed are too significant that it would upset the current base of 
users 
(and make a mash of the code), regardless of migration software to translate 
current 
calendars into the new (subpage-less) format. This may be a good & wise idea so 
I am 
open to pursuing that course if the team wishes. The downside of doing so is 
that I 
would be working alone I suppose, not getting the benefit of your good 
insights/help.

With a projected user-base of 20K, I really must reduce the use of subpages in 
order 
to use this extension, otherwise I need to build a new extension. If that's the 
most 
appropriate course under the circumstances, I guess I need to hear that sooner 
rather than later! 

Thanks much - John

Original comment by jmccl...@theolympicbuzz.info on 26 Feb 2009 at 7:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by kenyu73 on 1 Mar 2009 at 9:15

• Changed state: Review

[GoogleCodeExporter]

Issue 45 has been merged into this issue.

Original comment by kenyu73 on 1 Mar 2009 at 9:16

[GoogleCodeExporter]

iCal and RRULE events maybe be improved more as some point. I'm nost sure how 
far I 
will go though.

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

• Changed state: WontFix