Randal - i guess i'll throw my 2 cents in here . . .

First off, don't type a single line of code until you have purchased and
read Kent Beck's Smalltalk Best Practice Patterns. trust me.

Secondly, since this is something you actually need to use, you'll want to
avoid complexities that aren't strictly necessary in the beginning. this
might mean using:

* a simple DoIt interface
  instead of a Morphic gui, just open a Workspace and keep a few simple
  lines to execute when you want to interact with your "program" like:
    | tracker |
    tracker := Tracker forWeek: '2/11'.
    tracker addHours: 2.
  and
    | tracker |
    tracker := Tracker forWeek: '2/11'.
    Transcript show: tracker weeklyReport; cr.
  once you have code that does what you need, go nosing around the image
  for a GUI that looks close to what you'd like for your program. copy
  code and/or ideas as necessary. (note that your program is working and
  providing value while you do this.)

* image persistance
  if writing to a file doesn't fill some immediate need, then don't worry
  about it at first. sure, images do get corrupted from time to time and
  writing out to a file might be higher on the warm fuzzies scale than
  just letting data hang out in the image, but the Smalltalk thing to do is
  to just hang out as the default and worry about external persistence when
  the need is truly clear. Workspaces and Transcripts can always be saved
  as text files when you are low on warm fuzzies. (and it is not that hard
  to make periodic backups of your image to guard againt an image going
  bad.)

Thirdly, try to write tests for your code (preferably using the latest
sUnit from http://ANSI-ST-tests.sourceforge.net/SUnit.html ). writing unit
tests, especially writing them *before* you write "real" code can be a hard
habit to get into, but it pays big dividends.

Concentrate on the value this program needs to deliver. Do the simplest
thing that could possibly work. Work top-down. Complete the more important
functionality before you move on to bells and whistles.

(not, of course, that you didn't already know this, but sometimes it helps
when others remind us of stuff that we already knew.)

happy squeaking!!

david

At 12:14 PM 2/15/01 -0800, you wrote:
>
>OK, I have a compelling need to track hours spent on a project for the
>first time in a few years.  I have this old rusty hypercard stack
>(modified to have a 'save as text') that I had formerly used, and I
>think it's about time to hack the same thing in Squeak instead.  So I
>have (ta da) my first Real Project in Squeak(tm).
>
>I think TimeTracker and TimeTrackedItem sound like the two most
>natural classes for this.  So I create TimeTracker as a subclass of
>Morph, I suspect.  Or should it be a subclass of SystemWindow?  And is
>a TimeTrackedItem on the screen as a submorph?  Does it have to be
>within the parent's bounding rectangle?
>
>Or do I even need classes?  Can I just hack a morph adding specific
>behavior/data?  I know... that's the VB approach. :)
>
>Presuming I'm using classes, where does the class code get stored?  Do
>I make a project, build it there, then fileout the project from time
>to time?  And then what about the data?  Should the class itself know
>how to store to a file (and if so, how?), or should I just use "save
>morph on file" to save the data?  And if I "save morph", but then
>alter the class to add additional behavior, will the restored morph
>become one of the new class instances, or somehow stay one of the old
>ones?  And does "save morph" also save all the live submorphs?
>
>I know this is probably all too basic to discuss on this list, but if
>someone would prod me in the right direction, I'm going for it.
>
>-- 
>Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
><merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
>Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
>See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
>
>
--
David Farber
dfarber at numenor.com