neelix-devel

[neelix-devel]uml for the model

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

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.

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. 

You might notice I made the accessors attributes. I love how ruby blurs
the distinction between an attribute and its accessor.

-- 
 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

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

Re: [neelix-devel]uml for the model

[Jamis B. <jg...@em...>]

Hans Fugal wrote:

>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.
>  
>

This sounds a lot like what I did for Penny Pincher (a Swing-based 
financial tool I've been working on: http://penny-pincher.sf.net), at 
least as far as the observers.  I created a DatabaseEventMediator, and 
anytime anyone changed the database in anyway, they notified the DEM and 
told it which table and record (or records) were modified.  Then, any 
objects that were registered listeners on the given table were notified 
of the change.  Works quite well.

>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.
>  
>

For what it's worth, Danny and I have been taking 456 (GUI's) this 
semester, and Dr. Olsen is of the opinion that there is no added value 
in separating the view from the controller.  He said that it used to be 
done, but caused a lot more complexity for few additional benefits.  
Also, he said that the only reason for separating the view from the 
controller is if you want to reuse the controller or view independently 
of one another (ie, attach the same view to a different controller, or 
vice versa).  This happens extremely rarely.

- Jamis

-- 
Jamis Buck
jg...@em...

ruby -h | ruby -e 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'

Re: [neelix-devel]uml for the model

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

/* Quoth Jamis Buck <jg...@em...>
   on Fri, 12 Dec 2003 at 12:43 -0700
   in <3FD...@em...> */

> >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.
>=20
> For what it's worth, Danny and I have been taking 456 (GUI's) this=20
> semester, and Dr. Olsen is of the opinion that there is no added value=20
> in separating the view from the controller.  He said that it used to be=
=20
> done, but caused a lot more complexity for few additional benefits. =20
> Also, he said that the only reason for separating the view from the=20
> controller is if you want to reuse the controller or view independently=
=20
> of one another (ie, attach the same view to a different controller, or=20
> vice versa).  This happens extremely rarely.

=46rom more reading I've done, I think another aspect at play is that what
with the toolkits we have nowdays the controller aspect is usually
extremely simple and very tightly coupled with the view (also done with
the same toolkit. in fact some widgets are both controllers _and_
views). I just read about the Model-View-Presenter model[1] and I really
like that approach. It almost exactly maps onto the four-layer
architecture[2] as well.

1. http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.=
htm
2. http://c2.com/cgi/wiki?FourLayerArchitecture

--=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