tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/953-mutiple-instatiations-of-a-view-classRobotlegs: Discussion 2012-07-10T09:34:03Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/171961172012-07-10T05:52:11Z2012-07-10T05:52:11Zmutiple instatiations of a View class. <div><p>Hi there,</p>
<p>I've reached a point with my RobotLegs learning curve where
things are getting awesome! Thanks guys!</p>
<p>I've a question though about an app I'm developing. In View 1
people can click on an object to load up indepth info about that
object to edit in a separate View 2 (x,y,z, width height). I really
like the idea that they can click on several objects and thus load
up several instantiations of View 2 at the same time (each
examining a different object). I've a Q or 2!</p>
<p>-I'm storing V2s as VOs in a model. Is this a no no? Got a
feeling it is!</p>
<p>-I'm contemplating accessing all instantiations of V2 via a
single Mediator (checking some property to then handle the required
View). Is this a no no too?</p>
<p>Good to hear your thoughts. Thanks!<br>
Andy.</p></div>andytwoodstag:robotlegs.tenderapp.com,2009-10-18:Comment/171961172012-07-10T08:34:50Z2012-07-10T08:34:53Zmutiple instatiations of a View class. <div><p>Take this with a pinch of salt - I'm not the expert around
here!</p>
<p>A view is a view. A VO is a small immutable container for
values, nothing more. You can store VOs in a Model. Instantiating
Views and storing them in the Model is a definite nono - avoid at
all costs.</p>
<p>You should be able to use a single mediator for all Views of a
particular type. In fact it think I've done it before - it may even
be the recommended way, I'm not sure.</p></div>Jamestag:robotlegs.tenderapp.com,2009-10-18:Comment/171961172012-07-10T08:43:56Z2012-07-10T08:44:04Zmutiple instatiations of a View class. <div><p>Just wondering where I store my collection of views though?
Ta!</p></div>andytwoodstag:robotlegs.tenderapp.com,2009-10-18:Comment/171961172012-07-10T09:20:15Z2012-07-10T09:20:16Zmutiple instatiations of a View class. <div><p>You shouldn't store them anywhere. The whole idea is to decouple
your views from everything.</p>
<p>A view exists on its own and does it's own thing, almost like an
independent application. The mediator tells it if something in the
application happens that it needs to know about. If something
happens within the view that the application needs to be told
about, the mediator will tell it.</p>
<p>Does that help?</p></div>Jamestag:robotlegs.tenderapp.com,2009-10-18:Comment/171961172012-07-10T09:25:29Z2012-07-10T09:25:32Zmutiple instatiations of a View class. <div><p>Wow! RobotLegs is deep! I get this. Thanks for your help!</p></div>andytwoodstag:robotlegs.tenderapp.com,2009-10-18:Comment/171961172012-07-10T09:33:45Z2012-07-10T09:33:45Zmutiple instatiations of a View class. <div><p>If you're talking about where to keep persistent references to
views, either for pooling or to preserve state, keep that stuff in
your view layer.</p>
<p>MVCS are packages that refer to purpose, not implementation. So
it's reasonable to have a pure-data class inside your view package
which is used for pooling / referencing instances of views (so that
parent views can then add them).</p>
<p>As James says - moving those to the model layer would be
unusual. However, there are very specific usecases where the model
might hold references to views - for example if your app was a
sketching app - the sketches could be considered to be part of the
model.</p>
<p>hth,</p>
<p>Stray</p></div>Stray