At 03:16 AM 9/7/99 +0900, chas wrote:

At 02:32 PM 9/6/99 -0400, Rob Page wrote:

...

Wow.. a great analysis of the whole Calendar/Schedule/Event problem! I'd encourage anyone considering calendar/schedule issues on their Zope projects to re-read Phillip's post.

Now, if we could only insert about a man month to implement and document... <sigh>

I know... he scared me off :(

Sorry. That's just how I design - think about what the problem *really* needs, and then figure out how to do a scaled down version of it that's actually implementable within budget. The nice thing about this approach is that it: A) helps prevent you getting stuck further down the road, and B) often gives you a simpler way of doing things, with spin-off benefits you weren't originally looking for. Polya's Paradox states that it's often easier to create a general solution for a class of problems and then to specialize it for your specific problem, than to build a specialized solution just for your one problem. The ZPublisher concept itself is a brilliant application of this principle.

But it WAS a great post and brought up a lot of requirements and considerations that I hadn't thought about.

Well, you probably don't need/want a full-blown scheduling system like what I described, but the basic ideas of an Event, Schedule, and CalendarEntry can probably still help you with your projects. You might even leave out Schedule, since Schedules are only needed to manage resource commitments, and it sounded like that would be external to your application. Anyhow, just focus the ideas much more specifically for your application. Then, if a full-blown system ever shows up, your application is already designed in a way that would make it conceptually straightforward to port over and take advantage of the rest. There is a good chance that I or other members of my team will be tackling some of these items in the not-too-distant future, though I expect it could be quite a while before we have a robust general system. I *do* have some interest in design collaboration by fellow Zopesters, however, and I think it would be great if we could hash out the interface protocol for the different pieces and then all begin making components that work according to that API. Maybe Zope needs some SIG's along the lines of the various Python SIG's... Hmmm. :)