Re: Action based undo or snapshot based undo? Summary!
Re: Action based undo or snapshot based undo? Summary!
- Subject: Re: Action based undo or snapshot based undo? Summary!
- From: Alexander Lamb <email@hidden>
- Date: Fri, 07 Feb 2003 14:22:20 +0100
>
It will also often turn out to be very common to change many related
>
objects or many related attributes in the same event, so it can be a
>
big efficiency win to coalesce notifications so that your controllers
>
and UI don't need to do more work dealing with intermediate states of
>
the model objects. I.e. set up a structure where you can delay
>
notifications. Instead of notifying on every attribute change, mark the
>
object as "hasChanges" and then post-process your model at the end of
>
the event and have every changed object send a single notification then.
>
Absolutely. You could probably easily achieve this by having the association
objects listen to the notifications but not process them. Each new
notification replacing the old one (for that one association of course).
Then at the end, send a "process changes" to have the association reflect
the UI changes.
Now, to have something happen really at the end of the event loop, my
"solution" would be to queue an event in the event loop upon receiving the
first notification in an association object (could be a class method keeping
a global state for the event loop).
>
> And... To make it even more generic, create an association class that
>
> is
>
> instantiated for each UI object that needs to either be updated or that
>
> changes the value of an object (again, more or less on the model of
>
> EOF).
>
> This association objects listen to "attribute update" and decide if
>
> they
>
> need to update the given UI object they monitor. In that way, the
>
> controler
>
> code becomes even simpler since you don't need to listen to
>
> notifications,
>
> but simply create association objects upon initialisation. To go even
>
> further, as in EOF (my obsession as you can see:-), have the
>
> associations
>
> classes as a palette in IB. Since there is no EOModel, simply have the
>
> inspector of the association display a text field where the name of the
>
> attribute would be entered.
>
>
Don't forget display groups.... you need to know which are the selected
>
objects whose changes should be reflected in the UI. And writing the
>
controller code for a specific UI object is about the same amount of
>
code and much easier for a beginner to understand than writing an
>
association class that does the same thing. So it doesn't really save
>
you work unless you reuse UI elements in more than one place.
>
>
I think you are absolutely right that associations and display groups
>
are incredibly useful ideas and are a great way to set up a UI with IB.
>
A bunch of us tried to convince NeXT/Apple for a long time to chop
>
EOInterface out of EOF and give it to the AppKit team to use with all
>
applications.
>
>
But it isn't an easy set of code to write. And it does have its own
>
drawbacks.
>
No, but the advantages are numerous. I am wondering, since you certainly
have more contacts with engineering than me (at least recently), if you have
the feeling the Cocoa team could be working on something like that? It would
be a pitty to start a generic framework of associations/display groups,
etc... To have Apple come out with an "advanced UI manager" at WWDC!
>
For instance, enabling/disabling appropriate UI controls for the
>
current state. In EOF apps, if you use associations to enable/disable
>
UI, then you need to have the logic for that exposed as an attribute in
>
your model for your association to hook up to. But often that is logic
>
that is really external to the model itself and should be in the
>
controller layer instead. This is an example of how using associations
>
tends to 'squeeze' your controller layer. It encourages you to put more
>
code in the model or in the UI and avoid putting code in the
>
controller, so that your controller layer basically ends up being the
>
series of association connections in IB and that is pretty much all.
>
Yes, but is this really that bad? I mean, you still can use categories if
you don't want to mix things in the same source file. I had the same kind of
trouble on a project where the color of a trade was determined by some
business logic.
>
That works really well for database apps. There isn't usually a whole
>
lot of interrelationships between attributes or complicated logic in
>
the controller. "This field is displayed here, this other field is
>
displayed there" can be most of the controller work in a database app.
>
Associations shine for this. But the more interrelationships you have,
>
the more display preferences you have for displaying things differently
>
even though the model doesn't change, the more complex views you
>
have... the more difficult it is to shoehorn what you want to do into
>
an association model. You can always write more different types of
>
associations, but it stops being the most straightforward way to do
>
things.
>
>
Again, it all depends on your app. If you have a lot of similar UI and
>
similar control structures for a lot of different windows, then writing
>
generic association style connections between model and view can be a
>
big win. If not (and it is usually not), then writing your own
>
controller logic for catching notifications and updating UI is more
>
straightforward and not really any more code.
>
Associations were not meant as the only solution. But if it does 80% of the
job on regular apps, I am ready to hard-code the remaining 20% (to update
graphs, gantt charts or whatever).
Alex
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.