+ 1 :) So I like the discussion. It would be nice to have Views that do not inherit from model. :) So let us get real model.
Stef > In CUIS the intent is to provide specialization on the model, And then >> each model holds the responsibility of creating the appropriate view >> (SystemWindow), by creating a composition of widgets. This is a subset >> of the model hierarchy, >> > >> Model >> TextModel >> Workspace >> PluggableTextModel >> TextProvider >> CodeProvider >> Browser >> HierarchyBrowser >> Debugger >> Inspector > > For me, this hierarchy is bad. > Workspace is not a model, it's a view basically. So why it inherits from > Model ? > The same for Browser, HierarchyBrowser, Debugger, Inspector and so on... > > > Maybe it's better to have something like > > > > <BrowserInheritance.pdf> > > > > > >> >> From what i've understood, you want to do something similar, but >> instead specialize the "View", and have a single "model"? Did i >> understood correctly you intent? >> >> If that is the case, then i advice to look at CUIS before. I believe >> the arguments below are quite strong ones for the CUIS approach ( >> Specialized Model and Generic View). >> >> I believe this scheme is flexible and extensible, because you make the >> view "stupid", and specialize the model. You avoid polluting an unique >> class (for example the mess in CodeHolder), and put the behavior in >> the model( in the proper sublcass). And you make the view dont know >> about the model logic, because it's just a composition of widgets. The >> downside is that the model knows how to "assemble" the view. But this >> means that you put the interaction handling logic in a model, and can >> assemble many different views on the same model >> >> Please dont take it the wrong way, i'm favor of discussing before >> blindly porting CUIS code, but i would like to know more about the >> reason behind your approach. So we can clean and simplify the ugly >> parts of the system! > > > Do not worry about, I'm always open to discussion, and always happy to learn > ;) > > > Ben > > >> >> Thanks, >> Fernando >> >> >> >> >> On Thu, Mar 31, 2011 at 1:28 PM, Benjamin >> <[email protected]> wrote: >>> >>> On Mar 31, 2011, at 10:50 AM, Stéphane Ducasse wrote: >>> >>>>> >>>>> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >>>>> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >>>>> in Pharo. At least Nautilus must have a model for the text ? In CUIS >>>>> the root class is called TextModel , in Pharo 1.3 is called >>>>> StringHolder. I propose moving this discussion on another thread. >>>>> Maybe Benjamin could clarify this? >>>> >>>> benjamin will let us know. >>> >>> I think that the text should be handled by a Browser but by the TextMorph, >>> or you will have the same ugly hierarchy than StringHolder, when a >>> Model/View are badly mixed and where each tool that manage source code >>> inherits from it, without using properly inheritance ... >>> >>> IMHO, it should be orthogonal to that, and should be "pluggable" in each >>> tool which need it. >>> >>> Right now for Nautilus, I have borrowed only 3-4 methods from >>> StringHolder/CodeHolder/Browser, almost all expected behavior is provided >>> by PluggableTextMorph >>> >>> >>> >>> Ben >>> >> >
