From: Michel Pelletier <michel@digicool.com>
Ty Sarna wrote:
<!--#var standard_html_header--> <!--#calendar--> <!--#var "_.string.upper(mode[0])"-->: <!--#var date fmt=Date--> <!--#/calendar--> <!--#var standard_html_footer-->
I'd like to put this in Zone. Do you have any plans for expansion?
See. That what happens when you get Ty and me together... I complain a lot and tell Ty what I wish I had, and Ty goes away for a few hours and comes up with these jewels. :^) Actually, Ty said he had been thinking of it already, but he's gonna have to learn not to tell me that kind of information because I'll begin to question his zenhood. My suggestions were to provide a mechanism for managing a calendar 'wrapper' which could hold or reference other objects. I.e. you could either drop other Zope objects into a date or point at them somehow. Ty came up with the dtml extension to manage the calendar but we aren't quite sure how to hook things into it. Were hoping to get some suggestions. Also there's the question of 'look'. How much flexibility is needed in customizing the 'look' of the calendar? Is it just easier to take an example and write your own or is it worth it to try to build an editable folderish calendar product? What for? Well, I'm tasked with wrapping up the whole population genetics department into a publishable object where I just hired on, including all the genetics databases, management statistics and department scheduler sorts of things. They said they'd understand if it took me a while. :^) I'm mainly wandering around looking for ideas on how to cause trouble right now... I gave a talk on three of the projects I've worked on the last year and mgment's (I get to work with intelligent monkeys at this job :^) eyes lit up and they got all excited. So please give Ty some more ideas for this calendar thingy! How would you use it? what sorts of things would you want it to contain? Kent
Kent Polk wrote:
From: Michel Pelletier <michel@digicool.com>
Ty Sarna wrote:
<!--#var standard_html_header--> <!--#calendar--> <!--#var "_.string.upper(mode[0])"-->: <!--#var date fmt=Date--> <!--#/calendar--> <!--#var standard_html_footer-->
I'd like to put this in Zone. Do you have any plans for expansion?
My suggestions were to provide a mechanism for managing a calendar 'wrapper' which could hold or reference other objects. I.e. you could either drop other Zope objects into a date or point at them somehow. Ty came up with the dtml extension to manage the calendar but we aren't quite sure how to hook things into it. Were hoping to get some suggestions.
Also there's the question of 'look'. How much flexibility is needed in customizing the 'look' of the calendar? Is it just easier to take an example and write your own or is it worth it to try to build an editable folderish calendar product? <STUFF DELETED> So please give Ty some more ideas for this calendar thingy! How would you use it? what sorts of things would you want it to contain?
I would reccomend taking a look at the following URLs: http://www.geonorth.com/geocalendar/ http://www.when.com http://www.planetall.com I would love to be able to add events that could be personalized by filtering for category and/or geographical proximity, as well as letting end-users create and manage shared/group calendars with submission, editing and viewing permissions. Clicking on a particular day should bring up the day-mode, and I suppose you could do something similar for the week-mode. It should be possible to click on a link to see a more detailed listing for an event. This might actually involve creating a separate 'Event' product/class/lever/whatzit and dropping it in, although I'm not sure how you would create events that spanned several dates. Hope these ideas help, Michael Bernstein.
Michael Bernstein wrote:
I would reccomend taking a look at the following URLs: http://www.geonorth.com/geocalendar/ http://www.when.com http://www.planetall.com
Another site to look at would be: http://www.jump.com Michael Bernstein.
Michael Bernstein wrote:
I would reccomend taking a look at the following URLs: http://www.geonorth.com/geocalendar/ http://www.when.com http://www.planetall.com
I would love to be able to add events that could be personalized by filtering for category and/or geographical proximity, as well as letting end-users create and manage shared/group calendars with submission, editing and viewing permissions.
Ty's too busy doing real work for me while I get to goof off, so I'll try to reply.
It should be possible to click on a link to see a more detailed listing for an event. This might actually involve creating a separate 'Event' product/class/lever/whatzit and dropping it in, although I'm not sure how you would create events that spanned several dates.
This is where we want to go with this stuff, however, a 'calendar product' appears a bit too limiting, thus why Ty implemented the calendar wrapper in dtml. The one drawback, as mentioned is that a month calendar query may require performing separate queries for each day in the month, depending on the final version. Ty says that if you set caching on the queries, it may not be so bad even still. (I'll let him handle that one :^) Basically we are thinking that the calendar dtml would provide the info as in Ty's example, to another method, which could determine how to publish the items for that day. This could provide an very high degree of flexibility at the expense of having to write the stuff yourself. And of course, I expect we'll see the next version of TinyTables as a result, supporting editable rows (mmmm, tasty). This would mean that you could use a TinyTable to maintain info on how to reference other objects, basically anywhere. You could even have a 'sunset' column where you set an expiration date for the item and a corresponding method to expire items which match the sunset query. This also means that you could simply have one item extend over several days in the tinytable, or you could have a column named 'day', which could contain items which you want displayed for every day that matches (every Monday, or every 1st Monday as an extension) This brings to mind having a 'day list manager' or such which could provide an editable management wrapper for the tinytable. Maybe a folderish object which contains a tinytable or other query object (or combinations thereof) for managing the links. The dtml therein could be changed to support pretty much whatever you need.
Kent Polk wrote:
calendar wrapper in dtml. The one drawback, as mentioned is that a month calendar query may require performing separate queries for each day in the month, depending on the final version. Ty says that if you set caching on the queries, it may not be so bad even still. (I'll let him handle that one :^)
Yes, if performance really becomes an issue there is a trick to this. Have your dbFindEvents SQL query return all events in a date range, enable caching of results (at least for a short period of time), then do something like: <!--#calendar--> <!--#in "dbFindEvents(firstdate, lastdate)"--> <!--#if "eventdate.earliestTime() == date.EarliestTime()"--> render the event <!--#/if--> <!--#/in--> <!--#/calendar--> That is, have the rendering code for each day perform the exact same query (so the results will be cached) for the whole range to be rendered, and then pick out the relevant items. I suspect in many cases performance won't be enough of an issue that you'll need to do this kind of thing. I'll have to add firstdate and lastdate varibles for the per-day dtml to use.
At 03:06 PM 2/9/99 -0600, Kent Polk wrote:
It should be possible to click on a link to see a more detailed listing for an event. This might actually involve creating a separate 'Event' product/class/lever/whatzit and dropping it in, although I'm not sure how you would create events that spanned several dates.
This is where we want to go with this stuff, however, a 'calendar product' appears a bit too limiting, thus why Ty implemented the calendar wrapper in dtml.
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. 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 a Folderish. Then you can create different view of it inside it! Otherwise, you can always create DTML methods outside your object and use acquisition to bind your DTML methods to your object. 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 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! Just my two cents. -Amos P.S. Keep up the great contributions you guys rock!
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.
participants (4)
-
Amos Latteier -
Kent Polk -
Michael Bernstein -
Ty Sarna