Re: [neelix-devel]uml for the model

[Hans F. <ha...@fu...>]

I should add I forgot to include the Shelf, which is an aggregation of
cookbooks. While I'm explaining things I'll touch on the Replicator,
which is a fun little creation of ours. The replicator is basically a
factory pattern. You ask it for (type,id) and it gives you the
corresponding object. It may already have that object, or it may have to
create an object from the database. It also has a create method to add
objects to the database. So, if you get your objects from the replicator
always there will only ever be one object with the same (type,id), and
it will keep itself in sync with the db, but we do not have to create
all the objects up front (surely it will be rare that you look at every
recipe during one invocation of the program - we save some time and
memory however negligible it might be).

In MVC it's fairly standard for the model to notify the view when it has
changed (i.e. observer pattern). I think each object in the model will
have a registry of observers (objects in the view) that get notified on
change (e.g. when an object in the controller changes a value, or any
model-internal processes do the same, although that's not likely to
happen in neelix). This will nicely address the datatarget issues Jacob
and I were trying to work out earlier. It was getting pretty hairy.

In summary, the replicator is the gate to the model. The view and
controller get to the model (set of objects) via the replicator. Views
register as observers to keep up-to-date.

On the MVC issue, can anyone give me a good reason why view and
controller are separate? Some suggest tightly coupling them and I really
am having a hard time figuring out the benefit in keeping them separate.
Maybe as I read more[1]...

1.=A0http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

/* Quoth Hans Fugal <ha...@fu...>
   on Fri, 12 Dec 2003 at 12:08 -0700
   in <200...@fa...> */

> Made this with umbrello. Umbrello was pretty cool until it segfaulted
> when I exported this image, before I got the chance to save my work.
>=20
> This is more or less the data model that neelix does and will use. It
> reflects the database schema as well. I left out the attr_accessors for
> aggregations, leaving that up to the imagination via the aggregation
> associations. Also note that quantity should be public just like all the
> other accessors.=20
>=20
> You might notice I made the accessors attributes. I love how ruby blurs
> the distinction between an attribute and its accessor.
>=20
> --=20
>  Hans Fugal                 | De gustibus non disputandum est.
>  http://hans.fugal.net/     | Debian, vim, mutt, ruby, text, gpg
>  http://gdmxml.fugal.net/   | WindowMaker, gaim, UTF-8, RISC, JS Bach
> ---------------------------------------------------------------------
> GnuPG Fingerprint: 6940 87C5 6610 567F 1E95  CB5E FC98 E8CD E0AA D460





--=20
 Hans Fugal                 | De gustibus non disputandum est.
 http://hans.fugal.net/     | Debian, vim, mutt, ruby, text, gpg
 http://gdmxml.fugal.net/   | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95  CB5E FC98 E8CD E0AA D460