• EventCalendarPlugin

This is a new MoinMoin macro for event calendar (similar to MonthCalendar macro). The development is based on the MoinMoin MonthCalendar macro but it is a litte bit different from MonthCalendar. It is targeted to the one of PIM. It includes a parser which shows the event information in a well parsed format.

Features

• EventCalendar macro

  • Monthly, List, Simple view of events
  • Handles daily and timely events (no daily view yet)
  • Uses wiki pages for storing event data
  • Customized display: background-color, icon

• EventCalendar parser

  • Shows the event information in a parsed format.
  • Validates the date, time format.

Platform Support

• Tested on/with:

  • MoinMoin 1.3.5

  • Windows XP, Windows 2000
  • Python 2.4 (note: list view does not work on 2.3.x)
    • Could you show the detailed errors on that?
  • IE 6.0, Firefox 1.5b2, Mozilla 1.7a, Opera 8.5

Installation Guide

• EventCalendar macro

  • Download the latest EventCalendar.py macro and place it either in your global macro directory (MoinMoin/macro) or preferably in your local macro directory (yourwiki/data/plugins/macro).

  • Do not forget to rename the downloaded .py file. For example, you should change the file name 'EventCalendar-080.py' to 'EventCalendar.py'.

• EventCalendar parser

  • Download the latest eventcal.py parser and place it either in your global parser directory (MoinMoin/parser) or preferably in your local parser directory (yourwiki/data/plugins/parser).
  • Do not forget to rename the downloaded .py file. For example, you should change the file name eventcal-080.py' to 'eventcal.py'.

• EventCalendar stylesheet

  • Download the latest eventcalendar stylesheet file and insert the entries into the common.css of the appropriate theme (e.g., MoinWiki/share/moin/htdocs/modern/css/screen.css).

Download

• v0.90 (Sorry for late update. I forgot to update this page )

  • Macro: EventCalendar-090.py

  • Parser: eventcal-090.py

  • Stylesheet: eventcal-090.css

• v0.80

  • Macro: EventCalendar-080.py

  • Parser: eventcal-080.py

  • Stylesheet: eventcal-080.css

Change Log

• Nov. 15, 2005 - Version 0.90

  • No file I/O needed: just with wiki pages
  • custom display for parsed view: none, footnote, erroronly, table
  • custom display for monthly view: bgcolor, icon
  • simple view is added
  • a few parameters are added

• Oct. 31, 2005 - Version 0.80

  • The initial version is released.

Usage

Macro Usage

• To list the events in a page, just insert [[EventCalendar]]

Parameters

• pagename: the page which the events will be resolved from. default: the page itself which the macro locates

  • [[EventCalendar(pagename=MyEvents)]]

• pagedepth: how much depth from the pagename to read event data. default: 0 (the pagename itself)

  • [[EventCalendar(pagedepth=2)]]

• message: shows messages or not (1: show, 0: no message). default: 1

  • [[EventCalendar(message=0)]]

• menubar: shows menubar or not (1: show, 0: no menubar). default: 1

  • [[EventCalendar(menubar=0)]]

• monthlywidth: calendar width in pixel or percent (monthly view). default: '600' (pixel)

  • [[EventCalendar(monthlywidth=80%)]]

• simplewidth: calendar width in pixel or percent (simpleview). default: '150' (pixel)

  • [[EventCalendar(simplewidth=200)]]

• firstview: initial calendar view: monthly, list, simple. default: 'monthly'

  • [[EventCalendar(firstview=simple)]]

• curdate: initial calendar date (in YYYYMM format). default: current month

  • [[EventCalendar(curdate=200510)]]

Parser Usage

• Use 'eventcal.py' parser to get a parsed format of the event which will be shown at the EventCalendar macro.

eventcal Block & Event Format

• To insert events, enclose the information about the events with 'eventcal' in the page or its subpages.
  • e.g.,

    { { {#!eventcal
    = [Title] =
    [Start Date] ... [End Date]
    [Start Time] ... [End Time]
    } } } 

  • [Title] should be enclosed with heading marker ('='), double quatation mark ("), wiki italic or bold ('', ''')

  • Title can be omitted and it will be titled as 'No Title'

    • e.g., == Title ==, === Title ===, "Title", ''Title'', '''Title'''

  • [Start|End Date] should be in YYYY/MM/DD or YYYY-MM-DD. End date can be omitted.
    • e.g, 2005/10/20, 2005-10-20

  • [Start|End Time] should be in HH:MM in 24-hour format. Both of start|end Time can be omitted but not either of them.

    • e.g., 08:00, 12:00, 18:00
  • In the parsing block of eventcal, it pops out first two date formatted text (startdate and enddate), two time formatted text (starttime, endtime), and quoted or heading titie.
  • It ignores further occurrence of the targeted string.
  • The order of each fields (date, time, title) does not matter .
  • The start date|time should precede the end date|time in the occurrence respectively.
  • See sample for more usage examples.

Separating Multiple Events

• If you want to include two or more events in the single eventcal block, separate them with ##eventcal in a line.

  • e.g.,

    { { {#!eventcal
    = 1st Event =
    StartDate1 ~ EndDate1
    
    ##eventcal
    = 2nd Event =
    StartDate2 ~ EndDate2
    
    ##eventcal
    ...
    } } } 

Use format PI

• (experimental)

• To insert events, you can enclose the information about the events in the page which has #format eventcal processing instruction in the header. All the page content will be parsed into the events. It also needs ##eventcal separator to insert multiple events.

  • e.g.,

    #FORMAT eventcal
    ...
    
    = 1st Event =
    StartDate1 ~ EndDate1
    
    ##eventcal
    = 2nd Event =
    StartDate2 ~ EndDate2
    
    ##eventcal
    ...

• DO NOT insert the #!eventcal block into the page which already contains #format eventcal PI.

• DO NOT specify view=footnote or ##view footnote parameters in the PI page. It won't work.

Parameters

• view: To customize the view of the parsed format, use view parameter.

  • none: no display event parsing even if it raises parsing error.
  • footnote: display as a footnote.
  • table: display in the table on the right side of the text
  • erroronly: display parsing error only in the table on the right side of the text
  • e.g.,

    • #FORMAT eventcal view=footnote
      
      = 1st Event =
      StartDate1 ~ EndDate1

• bgcolor: display the events in the specified background color for monthly view.

  • e.g.,

    • { { {#!eventcal bgcolor=#c0c0c0
      = 3rd Event =
      StartDate3 ~ EndDate3
      } } } 

• icon: display the events with the specified smiley icon (experimental)

  • e.g.,

    • { { {#!eventcal icon=(!) view=none
      '''Test Event''' StartDate ~ EndDate
      } } } 

Custom Properties for Events

• You can override the parser parameters (icon, view, bgcolor) for each event record.
  • e.g.,

    • { { {#!eventcal
      ##icon (!)
      ##bgcolor #c0c0c0
      ##view footnote
      
      ''3rd Event'' StartDate3 ~ EndDate3
      } } } 

Sample & Screenshot

• my wiki: http://angel.icu.ac.kr/~silee/CalendarTest

• Monthly view

  

• List view

  

• Event parser

  

Known Problem

• the events across a year are not rendered properly. (bug)

To do list

• Clean the ugly codes!!! (need help)
  • raw html codes
• Daily view of events
• Weekly view of events (is it useful?)
• Date/time Format customization (e.g., 2005/10, Oct. 2005, 18:00, 06:00pm)
• Custom background color per event (done)
• Custom icon per event (experimental)
• Upcoming event list
• More input parameters (done)
• Parsing description field (dropped)
• Using page cache
• Update page log at add/edit/remove event in the text data file (dropped)
• Sort events by various options in list view
• Load partial events only in the specified date range (done)

Notes

• MonthCalendar developed by ThomasWaldmann has inspired this macro.

• Much buggy.. :please report bugs and suggest your ideas.

• If you missed to add css for EventCalendar, monthly view may not readable.

  • Insert the eventcalendar css classes into the common.css of appropriate theme.

Discussion / Support / Request / Contribution

(moved from ExtensionProposals/EventCalendar)

• Its hard to edit tab separated file, maybe use some other separator, or use some markup.
  • At inserting the data, it replaces tab to other characters. I've tried to use xml for this but its file size grows much.

Of course XML suck for data entry. But you may use wiki markup, for example:

== Event Name ==
Event description...
 start:: 2005-10-25 14:00
 end:: 2005-10-28 20:00
 foo:: bar

This markup is automatically rendered in a meaningful way:

Event Name

Event description...

start

2005-10-25 14:00

end

2005-10-28 20:00

foo

bar

You can parse this data using a special event formatter, that ignore everything but heading level 1, paragraph, text and definition list. When you format you page with such formatter, it can produce a list of events objects, each with name, start, end, foo and description. Check how MoinMoin/formatter/pagelinks.py works. I think this will be the easiest way to parse your data into format you can use. Then pickle your event data in the page cache directory. Next time you need to read the page data, use the cache. Check how Page use this system to create a pagelinks cache - Page.getPageLinks, Page.parsePageLinks.

• It's a good suggestion, I think. But I'm trying to avoid to use dedicated wiki pages for event data only, because it generates orphan pages. My target is: we just create and maintain normal wiki pages, and insert a marker for an event record when we need event calendar for neat scheduling. I use the parsing block with eventcal as the marker. For example, http://angel.icu.ac.kr/~silee/CalendarTest2 shows how the MoinMoin 1.5 release schedules in http://moinmoin.wikiwikiweb.de/MoinMoinTodo/Release_1.5 can use this method.

-- SeungikLee 2005-10-29 18:26:31

• What is wrong with orphaned pages?

  • not wrong but it is fully dependent to the calendar so that the wiki pages for storing event data need to be removed when the calendar for these is not needed any more. My suggestion is that the event information is our normal wikis and you could insert a marker per event record - without or with small changes in its text - when you've got to aggretate all the related events in user-friendly format, e.g., monthly view of the events.

• If you can put events in any page, how do you collect events in the event viewer? Lets say you have a good solution to collect events from all the wiki - how do you find the event source when you want to remove or edit events?
  • Not all the wiki but child pages of some page where macro inserted or specified. Of course that it may be very tough job to search the events from all the pages if we specify the root page as the target. In the event calendar, each event entry has the reference page which the event information is collected from. To make it easier to find the event entry in the reference page, a bookmark to this could be generated automatically.
  It depends on how many events you have, and how many events you want to display in the same time, and how many event you need in memory in the same time. For example, if the event calender show only one month, you can keep the one data file for each month. If you want to show a year view, maybe its better to have one file for year. I don't think there will be any performance problem. How about saving events on wiki pages using special event parser? then one can add and remove events easily, and you get versioning for free.
  • Could you give me a hint for that? I'll take it into my consideration.

    -- SeungikLee 2005-10-27 03:47:38

    • Seems that you don't need that hint any more

Use page content, not a file.

• I've inserted the functionalities you mentioned. It uses wiki page content as well as text data files, and a parser shows the event item in the page content. Please visit the sample site (http://angel.icu.ac.kr/~silee/CalendarTest). It's very buggy but give your comment please. Thanks. -- SeungikLee 2005-10-28 16:26:48

Why use both data file and a wiki page?

• Frankly speaking, using text data file was the first version of event calendar. With your suggestions, I've added features to use wiki pages. I didn't want to remove the text file features from it and kept groaning to find any reasons to leave it. And I was struck by an idea and I can answer: The data file is used - remains - for administrative events, e.g., holidays. For example, you add several holidays into the text file, and just copy the text files to other calendars of yours or make it public to be used by others. Hurray!

I tried your event test page. It is not clear how you should work with it. I learned by trial and error that each #!eventcal is an event, and I guess you use the date~date as start and end date.

I suggest you write a specification that describe what kind of activities you want to support, and how people should do common tasks. For example, how one should add an event, change event data like start date, end date etc. It is hard to test the implementation when you don't know what the system should do

• Oops. Sorry for inconvenience. Please refer to http://angel.icu.ac.kr/~silee/CalendarTest/EventTest. Thanks.

Looks fine and useful, some wishes

• it seems to me that each entry needs a seperate parser call I would prefer one parser call, an entry goes from one level heading to the end or to the next heading. If you don't separate calls you don't get different indicators at the moment.
  • What do you think if insert a separating special character like '#nextevent'? For example,

    { { {#!eventcal
    ''first event'' 2005/10/20
    #nextevent
    == second event ==
    2005/10/25 ~ 2005/10/27
    #nextevent
    On 2005/11/02, we have a "3rd event".
    } } } 

  • or any other better way?

• I would like preferable to have a New Event button which is used to write the entries for the parser. Hmm I don't like to have on default it writing an additional file. I read your points on this but a wiki page is much more secure (revision history). Probably a Calendar page list could be used which is searched and called. Similiar to the Group pages for acl. Later on with PackageInstaller it would be easy to move it from wiki to wiki too.

  • OK. I got it and better to remove the use of text file. BTW, what's better?: New Event goes to a wiki page editor or customized input form (as in current) to insert the content into wiki page by macro?

    Preferable is a form which writes the user input to a page. Advanced wiki user could choose what they use (is the same with the GUI here)

• Can I have different colors for the events please. A next color thing would be fine or on demand.
  • What I can get now is inserting a parameter like '#eventcolor' for bgcolor, icons as mentioned above. For example,

    { { {#!eventcal
    #bgcolor #ccffff
    ''first event'' 2005/10/20
    
    #nextevent
    #bgcolor #cccccc
    #eventicon (!)
    == second event ==
    2005/10/25 ~ 2005/10/27
    
    #nextevent
    #bgcolor #cccccc
    #eventicon {*}
    On 2005/11/02, we have a "3rd event".
    } } } 

I thought more on using the existing wiki markup for example. The nummeration is done automaticly.

{ { {
= first event =
 Event description...
 start:: 2005-10-25 14:00
 end:: 2005-10-28 20:00
 foo:: bar
 color:: <#FF0000>
 bgcolor:: <#CCCCCC>

= second event =
 Event description...
 start:: 2005-10-30 14:00
 end:: 2005-11-08 20:00
 foo:: bar

= third event =
 Event description...
 start:: 2005-11-25 14:00
 end:: 2005-11-25 14:00
 foo:: bar

----
CategorySystemCalendar
} } }

While this page is set to the category CategorySystemCalendar it's entries are shown in the SystemCalendar. Similiar to include pages a user could add on an own page private entries secured by acls for only reading from him. Then if he looks at the calendar own entries are shown too but if one else looks his entries are invisible.

If it would be possible to have dependencies the second and following heading levels could be used -- ReimarBauer 2005-11-05 08:44:26

It's an easy format to use IMHO. I'll take it into consideration to the next update. -- SeungikLee 2005-11-29 01:47:58

• I think it will replace my Gantt parser by adding some more list views.
  • Please give me a hint for that.

    • ParserMarket/Gantt

  -- ReimarBauer 2005-11-01 17:06:10

* the layout of the calendar will be corrupted while switching the theme other than default.

What if I prefer using RestructuredText to display my Information? Did I get this right, that everything inside { { {#!eventcal ... } } } is parsed by eventcal and then given to the wiki-Parser? Can I tell eventcal to use ReST? (Nesting parsers doesnt seems to work -- which makes sense to me) -- HenningHasemann 2005-11-29 11:08:10

• I'm afraid that the macro won't work with RST though the eventcal parser may work because the macro reads to parse the raw body of the pages. Sorry for inconvenience. -- SeungikLee 2005-11-29 13:22:49

Okay, I think I can live without RST for the few lines / words that define dates, so that isn't too bad, but another thing I would consider useful is some kind of patterns. For example having things happening every Monday or so. Maybe the good old "calendar" program for UNIX/linux would also be a nice example for a syntax where one could easily describe repeating events. From the man page: (\t is the <TAB>-Character, calendar uses this to split dates and information) {{{ Thursday\tEvery Thursday.

• June\tEvery June 1st. 15 *\t15th of every month. May Sun+2\tsecond Sunday in May (Muttertag) 04/SunLast\tlast Sunday in April, \tsummer time in Europe Easter\tEaster Ostern-2\tGood Friday (2 days before Easter) Paskha\tOrthodox Easter

}}} -- HenningHasemann

* I think it is a good idea to have a event calendar with multiple references. User can maintain their own schedules individually, while showing group schedule in a common event calendar. How do you think ? --MoinBenz

* Great ideas. I'll take these into the consideration on the next version. I hope you could help me then. Thanks. -- SeungikLee 2005-12-16 06:46:36