Forum OpenACS Development: Re: Making calendar work with any acs_object

Collapse
Posted by Don Baccus on
We've discussed this before, though not quite in as much detail.

For starters, calendars should just map arbitrary objects to themselves, rather than require mapped objects to be a private calendar object (or child object) type.

Make this change in the datamodel, and part of your scheme just goes away.  It would require significant upgrade scripts but I believe it is definitely the way to go.  OF would've taken this work on for .LRN if they'd had time, but they didn't.

Secondly ... we want general objects to have the same capabilities as CR objects "before long" in regard to being able to map a template to an object, and to autogenerate forms for user input used to build objects.

For the moment the path of least resistance would be to restructure the calendar package to map CR items to the calendar (rather than calendar items), and to make use of the existing CR type template features and form input features to display and input such calendar items.  In this way the calendar package would not need to "know" how to call a proc (or include a template) but would use the general facility that already exists to pick the template to include when displaying a particular item.

Eventually we'd pick this up for arbitrary objects when that capability is extended to them.

Now if we need more display options than the mapped template facility gives now we could add to it (i.e. verbose etc).  I'd rather see this extended in a general model so other packages than calendar could just as easily display arbitrary objects ... provide a set of display templates mapped to an object type which can be used in various circumstances.

All the data regarding the date etc properly belongs in the calendar package itself ... having each packages Tcl API responsible for returning julian date information makes me cringe a bit ... make a mechanism which allows packages to easily map an object to the calendar and keep the date information in the calendar's mapping tables.

The above doesn't address the filter options issues at all, there's currently no mechanism such as this in the toolkit, so you're free to invent one :)

Collapse
Posted by Jade Rubick on
For starters, calendars should just map arbitrary objects to themselves, rather than require mapped objects to be a private calendar object (or child object) type.

Make this change in the datamodel, and part of your scheme just goes away.  It would require significant upgrade scripts but I believe it is definitely the way to go. 

I'm not totally sure what you mean here. My scheme does not require any sort of data structure really. It just requires the existence of procs with the right name, that get data from any object source. It doesn't actually even have to rely on the content repository, or any sort of mapping tables.
...we want general objects to have the same capabilities as CR objects "before long" in regard to being able to map a template to an object, and to autogenerate forms for user input used to build objects.
I'm not exactly sure how this works. I've never used this facility of the CR, and there's no documentation of it. I understand where you talk about moving CR features into general objects (I've followed those discussions), but if you could explain this a little more, I'd appreciate it.
For the moment the path of least resistance would be to restructure the calendar package to map CR items to the calendar (rather than calendar items), and to make use of the existing CR type template features and form input features to display and input such calendar items.  In this way the calendar package would not need to "know" how to call a proc (or include a template) but would use the general facility that already exists to pick the template to include when displaying a particular item.
So you're suggesting adding a field to cr_items or cr_revisions that is a date field? And then depending on the content_type, to display a different CR tempate in the calendar for that information?
All the data regarding the date etc properly belongs in the calendar package itself ... having each packages Tcl API responsible for returning julian date information makes me cringe a bit ... make a mechanism which allows packages to easily map an object to the calendar and keep the date information in the calendar's mapping tables.
I can understand why it makes you cringe. It just seems more flexible to me. But I don't understand the alternative well enough, so I'd love to hear more about what that entails.