Re: [neelix-devel] neelix/model model.rb,1.4,1.5

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

/* Quoth Jacob Fugal <ja...@fu...>
   on Mon, 22 Dec 2003 at 15:46 -0700
   in <3FE...@fu...> */

> Hans Fugal wrote:
> | I have an idea for the ordering stuff. Position is stored in the
> | ingredient itself; why not make the ingredients array a set? Then the
> | array only ever changes when the set changes (addition or deletion) but
> | not when the ordering changes. To get the items in order, just do
> | recipe.ingredients.sort. (we need to def <=3D> for Ingredient, of cours=
e)
> | To change orders, just twiddle the position numbers - no array
> | notification since the array itself doesn't change, just the items.
> | Move the repositioning (promote/demote) into the presenter. When the
> | presenter has done its thing, it can call ingredientList.update.
>=20
> Ok, I added some separate presenter logic to take care of the
> promotion/demotion/deletion. Pretty slick, a lot less confusing than
> what I did at first. I did still run into one problem though:
>=20
> Hans, why did you wrap the non-in-place array operations in
> ObservableArray? Specifically, sort (not sort!, just sort).
>
> I added a sort to the ingredients display code block in view/fox.rb and
> found myself in an infinite loop. sort notifies the ingredients
> observers, of which the method calling sort is one. Taking :sort out of
> the wrap_methods list fixed it. Is there a reason it needs to be in there?
Hmm, I claim the fifth. I think I had a reason, but I think it was
probably a poor reason, not well thought out.

> Second, rather than having the presenter function call notify_observers
> on the ingredients array|set, I just added an observer to the ingredient
> itself that tell the ingredients set(s) it belongs to to
> notfiy_observers. That way if the ingredient is somehow changed
> somewhere else (think maybe concurrent editing), any changes are
> instantly transmitted to all ingredient lists, not just the one that
> requested the change. Capiche? Is there any reason not to do it this way?
That is about what I had envisioned. I'm still not clear on how you're
doing it but when I see the code I will be more so.

> I'll commit the changes (the 'structure' in the presenter isn't very
> refined, but it's rudimentary and it works -- we can refactor it as we
> add more stuff) once you confirm this approach.
Go ahead.

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