Designing a calender
Locked
 
|
Hello
This morning I woke up with a decision to create a calender in squeak for the fun of it. I though I would run my design thoughts throw with you guys, so you can tell me what a stupid way of doing x or y is. How I visually see this is that a calender has years which in turn hold month, which in turn holds days and days have events. I'm not interested in adding times to the days, times will be added to the event text. One aria where I'm confused is if an instance of class Calender holds instances of class Year; how many years instances dose the calender hold? Are years created as needed or should say one hundred years, into the future be created when the calender is created? What I'm thinking is that an instance of class year should be created when a date is added to that year. Am I looking at this all the wrong way? As I see it repeat events need to be accessed by all instances of class year. So It would seem that a class variable is the best place to store these. How do instance methods access class variables? Sorry for being vague as usual, I'm a vague and confused person. Darren |
|
|
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:[hidden email] _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
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:[hidden email] > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Websites for On-line Collectible Dealers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Identry, LLC John Almberg (631) 546-5079 [hidden email] www.identry.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
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
|
«
Return to Squeak - Beginners
|
1 view|%1 views
| Free forum by Nabble | Edit this page |