Forum OpenACS Development: Calendar Plans

Collapse
1: Calendar Plans
Posted by Dirk Gomez on 10/31/03 11:53 AM

Here's my plans for calendar, ordered roughly by time:

  • Clean up the code. Document it, document the datamodel, mark unused procs as deprecated or remove them. Remove duplicate queries, unify very similar queries.
  • Clean up the templates.
  • Make the templates parameters more sensible. E.g. currently the calling templates passes ina url_template which determines whether an action on a particular item can be executed. I'll move this to being proper and unstandable parameters like create_p or edit_o.
  • A couple of new parameters:
    • Default view
    • Collaborative Calendar, a parameter that allows every user of a community to add, edit, and delete events if set to true.
    • In DotLrn: parametrize whether to show calendar lists for a whole term.
    • (Please post more parametrization ideas here or to bugtracker.)
  • Start using the various calendar preferences tables floating around.
  • Add a toggle: "Show all my events/Only this package's or community's events"

My idea is to leverage as much functionality as possible within the current datamodel. Currently I'd rather want to do only small changes to it and while working on above functionality, discuss how a new and improved data model would look like. So that would be the 5.2 goal.

The calendar adp files should then ideally be "abstracted" away from the idea that they show calendar items, but then they will show events, "things" with a time notion. Their API for 5.1 will be understandable without knowing the internal workings of calendar. (Currently not the case)

Above things are probably rather easily agreed upon. There's one thing I'd like to do away with because I find it intricate and illogical: a calendar instance can have a couple of calendars. I'd much rather have one calendar per instance and then above mentioned toggle.

Where does this make sense? Is not creating a calendar upon mounting a calendar package and then being able to create oodles of calendars per package an eeriet dotlrn-ism?

Maybe it does make sense and we just need to make the UI clearer?

Once this is clear, I also want to revise the calendar permissions model and calendar permissioning at large. Currently calendar isn't really protected against "URL hacking" - improved in 5.0 though.

The other big chunk of work I will start is libical integration into AOLserver. It's quite clear that a web calendar is more a secondary tools besides a PDA or some desktop application, so ideally the OpenACS calendar is able to talk to all these applications.