Quote from: sottwell at Feb 03, 2006, 09:49 AM
You could have the data source specified in the snippet tags with an argument, since a given calendar will be using a given data source. That would get it off the user interface and out of the user’s mind so he doesn’t have to stop and think about it every time he wants to make an entry.
The only thing that still under development is the decision to have this different data sources to be combined together or not.
I’ll start a little explanation of what I’m trying to accomplish in here. So far every calendar system is tight on one data source and basically the whole logic of displaying calendar is being tight together with the whole logic of retrieving the calendar data. To make a different kind of calendar, so that it looks unique I come up with this architecture.
The whole calendar system is build on 2 different entity/engine.
1. Calendar viewing engine
2. Data source engine
Both of this engine being combined by the snippet calling. FOr whatever need to be displayed on the calendar viewing engine need to be formated in certain way for it to be able to view it. So for display purposes, this will be the class/entity that needs to be hacked/modified.
In terms about Data source engine, it’s all depend on the creator. IF you guys come up with a different data source backend for accessing data from access database for example, then all you need to do is change the snippet calling to connect both engine. One thing to note though, the data source engine always have to be able to return the right array format for the calendar viewing engine.
Now the concern is when administering the data source. Basically it’s being done on Calendar viewing engine, but it needs to inter connect with data source engine, which in my opinion it’s suppose to be combined on the snippet, but I’m still haven’t got any idea on how to combine this nicely, instead of setting a pre-defined format, such as having a popup editor, and using that ugly alert box to pick and choose the reight data source engine to be edited. For now, that’s what I came up with, when you create new, it will always display that box, unless if you guys willing to hack into the Calendar viewing engine and makes it looks much better.
To answer your concern of setting up calendar for different users, you can actually modified the snippet, without having to hack into the calendar class.
Setup calendars on different pages, so they all will have their own data isolated from one another. Then create a new snippet which looks the same with the provided snippet, and change the data source to use multiple database source from different documentid. You might need to pass the document id that you have for each calendar and repeat it for each document id. You can also extend the method/function on data source engine for db that is called fetchData(&$data, $month, $year, $filter=’’). Overwrite the function to fetch the whole database, eliminating filtering for pageid. Use the extended class on the snippet, instead of the original one.
Hope it’s now clear to all the coder ou there on how to extend this calendar beyond what most calendar system can do. I was hoping this flexibility can encourage all the coder out there to improve the system. I know the price of flexibility will be a complexity, like what we have right now with MODx, but it’s minimal, comparing to the amount of work that can be done.
Regards,