Amos Latteier wrote:
The calender is very cool! However, I would advise against using a DTML tag. I think that using a real Product would be much more flexible and useful.
I don't see how, any more than a Tree product would be more flexible or useful than the tree tag.
If you are concerned about the display of your object, and think that using a DTML tag will buy you more flexibility, think again ;-) IMO the best way to flexibly display an object is to allow the creation of different DTML methods to display it. One slick way to do this is to make your Product as
The DTML calendar tag isn't an object. It doesn't contain anything, any more than the tree tag is an object that contains stuff. It's just a widget that can be used to display objects in a certain format.
Another argument in favor of using a Product rather than a tag is that a Product exposes its methods to other Python objects. I would love to be able to write an external method that did something like import my desktop calender data and updated my Calender object. By creating a reasonable
There's nothing to import or export, because the calendar tag doesn't contain anything. Again, think of it like the tree tag.
interface to your Product, you allow people to extend it and use it in ways which you do not explicitly expect. This is good and easy--just write methods, add doc strings, and permissions--bingo you've got an extensible, documented, customizable, object!
Now, a folderish product for containing date-marked data is another matter, and could be built on top of the calendar tag. A folderish product was the first thing Kent and I talked about, but we decided that a display tag would be more generic and flexible and could then be used to implement a CalendarFolder type thing later.