Hi Randall.

OK, this may not be very useful to you, since you have many years in the
business, but you sparked my interest.  I hope this is helpful!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Well, you've got lots of questions.  Let's ignore them for now.  :-)  

The first thing I would do, if I were to approach a new problem, is make a
short list of my requirements.  I'd start by writing down what I want to
accomplish, what information I want to save (persistent) and how am I
planning on using the persistent information now and maybe later on.  This
is really basic stuff, but it works.

Once I've got some idea of the general functionality I want and some notion
of the persistent information, I can then plan a human interface to that
stuff.  Perhaps an editor -- to add the data -- and a report module -- to
see the data in interesting ways.  Sketch this on a piece of paper.

Next, I recommend drawing lots of shapes on a piece of paper and connecting
them with lines (shapes = objects, lines = relationships).  Once you have an
idea of how your objects interact, you can jump quickly, and confidently,
into implementation.

Things *you* may be interested in saving:
1.  A job/project object -- this may include info pertaining to date(s) of
the activity, time/units estimated, actual time spent, etc.
2.  A customer object -- linked to one or more job/projects
3.  Job type/description -- linked to one or more jobs

& whatever else is interesting.  Keep the list of persistent things small at
first.  If you start out small, you can come up with something workable
quickly.  You can always build on it.

*** Note:  Keep in mind that it is often useful to abstract the persistence
layer from the business model.  I have often used the Facade pattern for
this (see gang of 4's book:  Design Patterns).  What this means is, it's
nice to go through one knot-hole to get at your data (a common interface).
That way, you can swap out your whole persistence layer without changing
your application's design in any way.  So, if you want to go from a blob
database of objects to a relational SQL database, you only have to swap out
your database manager.  None of your application code, engine or GUI has to
change at all!  :-)  I had to do this on one project; we had 3 different
database back-ends in 1 year!  The facade pattern saved that project!

Once you have some plan for your persistent objects, you need to consider
the business model -- the objects that do interesting
calculations/manipulations on/of the persistent objects.  What objectives do
you have for this data?  Do you just want to type it in and report it back
verbatim?  Perhaps you need a summary engine that can crunch your data into
something useful.  This engine would be useful if you want to make different
reports on your data.

Finally, you need a user interface.  This may be just a simple editor that
allows you to enter the data.  See Bob Arning's examples on his charm.net
website.  He built some simple data entry morphs.  That might be a good
place to start.

You will probably also want to report on the data.  You ask your engine to
crunch the data and then spit it out into the Transcript or a file.  If
you're feeling fancy, there are lots of graphical morphs in Squeak that may
be useful.  You might want to make some charts, etc.  Browse your image for
the graphical morphs & see how they are used.

Good luck!

---==> Chris

> -----Original Message-----
> From:	merlyn at stonehenge.com [SMTP:merlyn at stonehenge.com]
> Sent:	Thursday, February 15, 2001 3:14 PM
> To:	squeak at cs.uiuc.edu
> Subject:	basic patterns for persistence
> 
> 
> 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!
>