Calendar Extension

jtelling

Just a thought... What if in a user's account settings they used label/value pairs with labels that started with "cal:" or something like that to populate a calendar with significant dates... Like I said, just a thought :)

dom

cal: 2005-07-21 // Start developing a calendar extension
cal: 2005-07-31 // Finish calendar extension

All the extension would need to do is go through the label/value pairs and pull out any prefixed with `cal:` for special processing (and also make sure they aren't processed normally). It's then a pretty simple job to build a teeny table which holds all the calendar info with events marked up on them (esp since we'll use CSS to purtify it).

Date format is a tricky thing to solve, since you Yanks and us Brits do it in different ways. It would be simpler all round if we ignored dd/mm/yy and mm/dd/yy style dates, and stuck to yy-mm-dd, or dd month yy (eg 21 july 05). It would also be good if it could accept recurring events by omitting the year, or the year and month (e.g. cal: 31st Dec // Party!, or cal: 3rd // Monthly team meeting).

That's my bit of brainstorming done, thoughts welcome

lech

I don't think this would be easy to pull off under the accounts page, looking into the DB, it appears that the extra form fields you use to put that info up are stored under one row. If you have phpmyadmin or something similiar, check out your Lum_Users table and see for yourself :)

dom

How about just using the MySQL command line?

I presume that at some point the system has to seperate out the label/value pairs, and so you should (hopefully) be able to intervene at that point, and grab the relevant bits.

lech

well, it's probably better to have it's own row or table of its own is basically what I'm saying.

Minisweeper

last i spoke to mark i believe those pairs are kept in some sort of xml format within that field in the database are they not? Which means obviously you can pick them out, but to do it you'd have to go through every user and parse it. Which is a bit silly really.

So yeah, own table is probably a better idea. Though you could use a cal: prefix and have it parse them out when its actually writing into the database - i,e. you make a label/pair which is called cal:birthday = 15/01/1988 and then instead of it xml'ing it up it just puts it into the seperate table. Shrug.

lech

yeah, I suppose any extension that isn't already playing with existing easy to grab data will likely want to create it's own table to play with. I suppose now would be a good time to create some naming convention for extensions that require it's own table like "LUM_Calendar" or "VEX_extension name".