On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > 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
Description: Adobe PDF document
> > 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 >> >
