No subject

Thu Feb 24 13:45:28 CET 2011

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!


On Thu, Mar 31, 2011 at 1:28 PM, Benjamin
<benjamin.vanryseghem.pharo at> wrote:
> On Mar 31, 2011, at 10:50 AM, St=E9phane Ducasse wrote:
>>> 2) 4) Regarding TextModel and subclasses such as CodeProvider and
>>> Browser in =A0CUIS: so it means that hierarchy wouldn't be needed at al=
>>> 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 f=
rom 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 StringHolde=
r/CodeHolder/Browser, almost all expected behavior is provided by Pluggable=
> Ben

More information about the Pharo-project mailing list