But now I think this through further - saying an *Element* is "just a view" and "it needs to have a Controller along side it" doesn't totally work because you can't insert a controller into a *Section.*
And you may want to encapsulate facets of behavioral-to-model logic within an Element, or Section so as not to have the root Controller become wildly complex being responsible for to many different things. These really are different kinds of things, right? Perhaps akin to a *View-Model *(??) Please humor this line of questioning. Backing out of a factoring and code-organization based on a faulty understanding of how to structure things gets more and more of a PITA with every new Element I make and use! :) Thanks guys!!! On Wed, Jul 11, 2012 at 7:41 AM, Phil Cockfield <p...@cockfield.net> wrote: > As I start to create custom cells by deriving from *Element* I need to be > careful I don't start messing up the clean MVC separation works in iOS. > > Is this a true and fair way to think of things: > > > - A derived [*Element*] should contain behavioral methods that are > responsible "only" for on screen manipulation of the visuals of the > Element's parts. It is conceptually the "View" of MVC. > > - A "model" per se should never be directly passed into a derived [* > Element*], rather > > - The relationship between a model, and the way the Element displays > is (via it's behavioral method mentioned above) should ALWAYS be managed > through a *UIViewController* (or *DialogViewController* as the case > may be). > > > That seems clear, and logical to me at the moment. Is it this clear cut > and simple - or do you guys start to blur things (passing models into > Elements)...and if so, is that OK/recommended? > > It's tempting to just ram some controller-like "model binding" behavior > into the derived element. Is that evil? > > Thanks! > > -- > *Phil *Cockfield > > > >
_______________________________________________ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
