Re: Designing a calender

Thanks for the comments.

Yes it makes sense to look at it just as a list of events with dates. Quite
simple really!

Cheers Darren



John Almberg wrote:
> 
> Another way to put it is the events are the data and a calendar is  
> *one way* to view that data. Another view would be a list of events.  
> If you separate the events from the view used to display them, the  
> design looks a lot simpler.
> 
> -- John
> 
> On Oct 4, 2007, at 9:57 AM, Herbert König wrote:
> 
>> Hello Darren,
>>
>> g> This morning I woke up with a decision to create a calender in  
>> squeak for
>> g> the fun of it.
>> good way to wake up :-)
>>
>>
>> g> How I visually see this is that a calender has years which in  
>> turn hold
>> g> month, which in turn holds days and days have events. I'm not  
>> interested in
>> g> adding times to the days, times will be added to the event text.
>>
>> Um, I've been thinking about this several times already
>>
>> Some examples:
>>
>> Meet Jim at his office on December 30. Jim got a bellyache. The event
>> stays the same but you got to stick it into another month which you
>> find in yet another year.
>>
>> I dislike that.
>>
>> The fact that you wake up with the plan to design a calendar for fun
>> hints, that your personal calendar isn't that crammed right now, so
>> why have empty days?
>>
>> I would have a collection of events which (may) carry a date. "I
>> should empty the waste bin" type of events don't.
>>
>> So I would make finding the events of a day (or other timespan) a
>> function method.
>>
>> If you have a 3.8 or older image you might want to look at MonthMorph
>> which does its job without carrying days. For 3.9 the PDA on SqueakMap
>> has the MonthMorph. I often use it as a day picker.
>>
>> g> One aria where I'm confused is if an instance of class Calender  
>> holds
>> g> instances of class Year; how many years instances dose the  
>> calender hold?
>> g> Are years created as needed or should say one hundred years,  
>> into the future
>> g> be created when the calender is created? What I'm thinking is  
>> that an
>> g> instance of class year should be created when a date is added to  
>> that year.
>> g> Am I looking at this all the wrong way?
>>
>> Can't tell if it's wrong but I personally think the calendar is the
>> means and the ends are the events.
>>
>> g> As I see it repeat events need to be accessed by all instances  
>> of class
>> g> year. So It would seem that a class variable is the best place  
>> to store
>>
>> This just looks like things get complicated because your thoughts
>> center around the calendar instead around the events.
>>
>> g> these. How do instance methods access class variables?
>> By using its name (which is capitalised) just like it accesses an
>> instance variable. Or by adding an accessor for the class and using
>> that one.
>>
>> Cheers
>>
>> Herbert                            mailto:herbertkoenig@xxxxxxx
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@xxxxxxxxxxxxxxxxxxxxxxxxxx
>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Websites for On-line Collectible Dealers
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Identry, LLC
> John Almberg
> (631) 546-5079
> jalmberg@xxxxxxxxxxx
> www.identry.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> _______________________________________________
> Beginners mailing list
> Beginners@xxxxxxxxxxxxxxxxxxxxxxxxxx
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Designing-a-calender-tf4568663.html#a13059180
Sent from the Squeak - Beginners mailing list archive at Nabble.com.