Forum OpenACS Q&A: Calendar API, using any sort of data

Collapse
Posted by Jade Rubick on
Dirk asked me to post this idea on a calendar API:

For many applications, you'd like to be able to map things onto the calendar. For example, with project manager, I'd like to show a user's tasks on the calendar. For room-reservations, you'd like to show when things are available and when they're not, etc..

This is my wish list idea for calendar:

I'd like to be able to pass calendar a list of items to print out, and get back a calendar with those entries in it.

For example, maybe something like this:

In .tcl:

set calendar_definition {
  {month 6}
  {year 2003}
  {entries
    {3 "My HTML to go on day 3"}
    {5 "<input type="checkbox" name="whatever" value="avalue">My HTML to go on day 5</input>"}
    {25 "My HTML to go on day 25"}
  }
}

set calendar_html "<form action="somefile">[calendar_html -definition $calendar_definition -bgcolor "ffffff" -fgcolor "000000"]</form>"

Then in the .adp file:

@calendar_html@

Something like this would be a lot closer to the holy grail with calendar of being able to display arbitrary types of data. Then the application developer could build the definition however they want, using data from whatever tables, etc.. They could even mix up several types of data, and refer people to different mounted packages, etc..

Notice you'd also be able to do en masse sort of operations.

The problem is that a lot of the display information is done in Tcl, which is very reminiscent of ACS 3 days. I'm not sure what the best way around that is. I also haven't used the OpenACS calendar, so I don't know anything about it's data model or code.

Another problem is that the idea as currently stated does not handle going to the next calendar page, etc.. You wouldn't want to pass all the data to a calendar function, I imagine..

Thoughts?

It seems like we might be able to improve on this idea, and implement it pretty easily. This would (in my book) be the single most useful improvement I could imagine for calendar. It then becomes really really useful!

Collapse
Posted by Don Baccus on
It would be easy to fix the datamodel so that arbitrary objects can be mapped to a calendar, I've discussed this in the past.  The datamodel as it was originally written by aD and as it still exists today is, pure and simple, broken because it doesn't allow such mappings (what's the point of having a calendar object in a general object-oriented system if I can't map arbitrary objects to it?)

That covers all cases above except adding arbitrary HTML to the calendar.  I'd have to think about that.

Object mapping for the cases this covers would be a lot easier to work with than what you propose IMO (remember that content items are objects and that the content repository supports arbitrary mapping of templates to objects for display so we can get whatever HTML we want for objects into the calendar without kludging calendar to hell and back)

Whether or not we were to adopt a scheme such as you propose, the data model needs to be fixed and we need to support the mapping of arbitrary objects to calendars.  We need this for 5.1 IMO.

Collapse
Posted by Jade Rubick on
How easy to fix would it be?

I like the idea of doing less kludging around -- frankly, my above proposal seems messy to me. Dirk, perhaps you can pick Don's brain a little and find out what changes would be necessary to get the calendar to map arbitrary data.

In this posting, you recommended a service contract:

https://openacs.org/forums/message-view?message_id=68163

Is that what you're talking about?

I have tickets mapped to a calendar on ACS 3.4.10, and since I'm upgrading our installation to OpenACS 5, people are going to scream about this functionality disappearing. I won't be able to work on this until project-manager gets a little further along, however, which means I couldn't help out until January or February 2004.

Collapse
Posted by Dirk Gomez on
I thought the acs_events table was there to store all things that denote
temporal data? Then there's the timespans and the time_intervals tables whose
sense I still haven't grasped...

To me a decent service-contract on the database level is to define a table
that holds the minimum amount of fields to be shown. Packages would insert
into this "central" table via a triggr (-> that's the service-contract).

Unfortunately I'm not (yet!) familiar with the acs-service-contract package -
how can it be of use in "temporal-data"?

Don, you seem to have a rough idea what has to be done? Can you post your
thoughts?

Collapse
Posted by Dave Bauer on
Dirk,

To relate objects to calendar items we just need a mapping table, or a related_object_id column in acs_events. If you want more than one object per calendar item, then you need a mapping table obviosuly. One option is to define a new relationship type and use acs_rels. Using acs_rels, to store user-mapped objects could allow a consisten interface in some future openacs based system such as knowledge management. A mapping table is easier to code.

Jade,

The service contract was to allow other pakcages besides calendar to provide the same calendar interface. This way you could actually store all your calendar items in a calendar server, but the packages that use calendar would not know the difference. To make this work, a tcl api would need to be defined to calendar, and every package that accessed calendar would use the tcl-api instead of accessing the database directly. Then if the calendar objects were stored outside the openacs database, the use would be transparent to the packages. This is not necessary to map objects to calendar items.

Collapse
Posted by Jon Griffin on
Dirk, timespans and intervals are there for extreme flexibility. This is a service package and not really meant to be called by end users.

Also, a big distinction is between and event and an activity. An event is an activity with a temporal value attached. IOW, Ride Mountain Bikes is an activity. Ride Mountain Bikes at 12 AM Mondays is an event (actually recurring).

This allows for repeating events of non-regular intervals (i.e Jan 4, Feb 13, May 9 and Dec 12) as well as regular intervals (i.e. every Friday), Allows for unknown start or ends (i.e. Starts at 3 PM, or ends Jan 13 2004). As well as many other options. acs-events is an extremely useful if underutilized service, and the problem with calendar is the data model for calendar not being written with the flexibility of acs-events (it was written originally in the LA AD office at the time the Java craze was beginning and about the time I left, so it was never really code reviewed or anything else, it was off to java land).

I hope that helps some with understanding acs-events, also Scott Meeks wrote the actual acs-events code so he may have some insights into the compromises he made to our original spec.