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