Regarding SimpleMorphic

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Regarding SimpleMorphic

Torsten Bergmann
Stef wrote:
>Why this hierarchy is wrong?

I did not say that the hierarchy is correct! And agree that
composition is better suited than inheritance here.

But Benjamin said "Workspace is not a model, it's a view basically."

This is wrong since this is more centralized towards what you
see (the workspace view) and not whats behind it.

I'm just at the position that a Browser IS A model and NOT a view
and that it can have one or more different views.

Nothing more said in my post.

Fernando Olivero
>Correct, but this is not enough to advocate for the removal of the
>Browser as a "model" for the view.

+100

Just because the model assembles the view that doesnt mean we
should remove a clean browser model!!!

We should clearly support MVC in the future and also introduce
a View class. Let's think about it:

   Model
     subclass Browser
   View
     subclass BrowserView

If we have a browser view - how strongly connected should it
be to Morphic - especially when we think of other kind of UI
bindings like Morphic, SimpleMorphic, GtK, HTML, ...
Or should we name it BrowserMorph?

And is this hierarchy design/naming correct. Let's verify:
 
It is not necessary that the model assembles the view - but
often wished that you open the view by sending a simple
message. Currently in Pharo you send it to the model:

    "Browser open"

If you evaluate the result you SEE is a view, the result
you GET if you inspect it is the model (who shouldnt know
about the views).

But often you also wish to acess the view (who always knows
about its model). So we have a conflict here and have to
use tricks to access the view afterwards.

So what about a different design, lets use the name
"Browser" for the view part:

   Model
     subclass BrowserModel
   View
     subclass Browser

If you evaluate "Browser open" you should get a view back
on the browser and if you ask for "model" you should
get the instance of BrowserModel. Looks cleaner but
different from what we currently have.

Maybe we talk all about the same thing and it is more
about naming. We could also be more explicit:

   Model
     subclass BrowserModel
   View
     subclass BrowserView

Bye
T.




--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de