• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: More binding questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More binding questions


  • Subject: Re: More binding questions
  • From: mmalcolm crawford <email@hidden>
  • Date: Thu, 14 Jul 2005 10:49:31 -0700


On Jul 14, 2005, at 9:08 AM, Steve Weller wrote:

What does the ClickerController do for me that Clicker does not?
<http://developer.apple.com/documentation/Cocoa/Conceptual/ CocoaBindings/Concepts/WhatAreBindings.html#//apple_ref/doc/uid/ 20002372-177085>
So NSControllers add placeholder values for null and multiple selections. But NSObjectController only has one object to control, so the placeholder is only useful if you haven't connected it to its controlled object -- probably an error. They also allow the controller to manage pending edits, either committing or aborting. This does look useful, but not in my little app, since I have no persistent store or preferences to update. So in my particular case I am fine without an NSController.
The link you provide above provides a lot of useful information about bindings and it is more meaningful to me now I have attempted my own app.
[...]
The learner is reading the document because they do not understand bindings.


Issues about the contents of documentation itself aside, why is it that a learner trying to understand bindings would not have read, or would not go back to read, that document? (Serious question.) Despite the complaints, many questions asked here are answered directly in the documentation. What is it that's stopping people from looking or finding?


The learner is reading the document because they do not understand bindings. As they go down the page they encounter new terminology and concepts and get some of their questions answered and remember some of what they have just read. But then instead of concreting the learner's partially-formed mental model, the example at the end scatters that model by raising a host of new questions.

The idea is that it should raise questions. The document is an introduction, it is not intended to be exhaustive--there are others that give a more complete treatment.

What is worse is that the "real-world" example (combatants) is not the same as the example that has been in use all the way down the page (temp converter), so the learner has just wasted effort in trying to grok how and why it does what it does.

There isn't really any more to explain about the temperature converter. And as "real world" examples go, it's not "compelling". A "real world" example is intended to be more complex, and to illustrate the benefits of bindings, "... the example requires no actual code to set up the user interface—the controllers and bindings can all be created in Interface Builder. This represents a considerable reduction in programming effort compared with the traditional target-action based approach."


My concrete suggestions are thus (and will be submitted to Apple)
* Replace combatants with temp converter as the real-world example

There are good reasons why this would not be appropriate...

* Detail the diagram with "bind x to y"
* Show the objects set up with these bindings with IB screenshots (the finished set up only) so the learner has the opportunity to try to reproduce what they have read without a tutorial


The diagram does show all the bindings?

This document in general should also distinguish very clearly between binding and KVO since the learner is attempting to learn many things at once:

I'm not sure where it doesn't make that distinction clear?


* Binding is a two-way synchronization system built using the one- way observing facilities of objects that support KVO
* Binding set-up and tear-down is done behind the scenes if established with IB, or can be done explicitly using bind:, whereas KVO has to be set up and torn down programatically (am I correct here?)


See <http://developer.apple.com/documentation/Cocoa/Conceptual/ CocoaBindings/Concepts/HowDoBindingsWork.html>.


mmalc

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >State based on front most document (was RE: Documentation frustrations) (From: Erik Buck <email@hidden>)
 >More binding questions (From: Steve Weller <email@hidden>)
 >Re: More binding questions (From: mmalcolm crawford <email@hidden>)
 >Re: More binding questions (From: Steve Weller <email@hidden>)

  • Prev by Date: Re: Multiple pasteboard items
  • Next by Date: Re: Tables in Tiger NSTextView
  • Previous by thread: Re: More binding questions
  • Next by thread: Re: State based on front most document (was RE: Documentation frustrations)
  • Index(es):
    • Date
    • Thread