[Cuis] Patterns

[Dan Norton]

The repo now contains two pairs of classes: coupled and decoupled. As it stands, the 
coupled example comes up the same, whether from the World->New morph... menu or from 
a Browser or Workspace.

The decoupled example does not do this and I don't know what to have in the pattern to 
avoid the following pitfalls:

follow the BrowserWindow class #openBrowser and get MNU: owner
follow the ColorEditorPanel class #initializedInstance and get wrong color subMorphs

 - Dan

On 17 Nov 2015 at 11:00, Juan Vuletich wrote:

> Hi Thierry,
> 
> 
> On 11/17/2015 1:42 AM, Thierry Goubier wrote:
> > Le 17/11/2015 02:47, Germán Arduino a écrit :
> >>
> >>
> >> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <juan at jvuletich.org
> >> <mailto:juan at jvuletich.org>>:
> >>
> >>     __
> >>
> >>     Well, I don't like the #open method in the model. The idea of
> View /
> >>     Model separation is that views know about models, but models
> don't
> >>     know about views. A Model should exist independently of being
> used
> >>     from Morphic, MVC, Seaside, or any other UI framework. It
> could
> >>     live, for example, in a Gemstone database with no UI at all.
> Or ir
> >>     could travel to and from other systems, like VA Smalltalk,
> where the
> >>     UI framework is completely different from Cuis'.
> >>
> >>
> >> Interesting, really I never heard of the use of  #open at the
> model or I
> >> do not remember it at all, but I think similar to Juan.
> >
> > Hum, #open has to go somewhere, so...
> >
> > Either it goes into a sort of Application Model, which regroup the
> > duties associated with the application (the view + model +
> whatever is 
> > necessary in environment X), or it goes into an Application View
> which 
> > then has model concerns in it (it knows how to start or connect to
> the 
> > model, it knows what the model is composed of to connect subviews
> to 
> > model elements, etc...).
> >
> 
> The idea of view / model separation is pretty well explained in
> "Inside 
> Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11.
> 
> I agree that an Application object or such might make sense when you
> are 
> building an application, especially if you need to deal with en
> external 
> environment. But here we were talking about whether the Model
> classes 
> should know about Morphs or not.
> 
> >>     I think it is better for the View to start it all.
> >>
> >>
> >> +1
> >
> > I prefer to model an Application concept in the target desktop 
> > environment if I want to model highly portable stuff.
> >
> > That application concern can be folded into a dedicated view if
> that 
> > is the preferred convention in the target environment.
> >
> > Regards,
> >
> > Thierry
> 
> I wonder how would this result in practice. Do you have some
> examples to 
> share?
> 
> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org