An Outline Code Editor First Steps

Laurence Rozier lrozier at thepattern.com
Fri Aug 20 16:52:06 UTC 1999


Bob Arning wrote:

> On Thu, 19 Aug 1999 10:19:57 -0700 Laurence Rozier <lrozier at thepattern.com> wrote:
>
> >My first, quick and dirty approach was to
> >subclass ListItemWrapper, overriding the contents method in the same way
> >ObjectExplorerWrapper does. Not surprisingly that's not a very flexible approach.
> >It expects that all nodes displayed will be homogeneous.
>
> Well, not exactly. ObjectExplorer is a very simple example and does not illustrate some of the possibilities. What I had in mind when I wrote the ListItemWrapper was two-fold:
> 1. To keep view-specific code out of the model classes where possible for esthetic and practical reasons.

I agree. Model objects should have some basic knowlege about how to present themselves, but they shouldn't have to know anything about the implementation of views - this should be kept out "where possible". In some cases knowing about different views is the responsibility of a model object - print, inspect, and now explore are examples. For
more complex or application specific views a Presenter/Controller may be the answer.

> 2. To allow for multiple types of views for the same model object. The difficuly with #getChildNodes is that it limits a given class to only one representation. Creating subclasses (as many as you want) of ListItemWrapper will allow you retain the current view as a "standard" explore and yet have other views that look at items differently.
>
> For more examples, including different representations of the same object, see
>
> http://www.charm.net/~arning/BobsBrowser.14Apr1206pm.cs.txt
>
> Note: while this can be filed into 2.5 and work reasonably well, it was written for a slightly older squeak and I would advise saving the image with this loaded. But you can run it and see some different implementations of ListItemWrapper subclasses.
>
> [snip]

I've seen this and it is valuable, but not exactly what I want in this case. Within a single hierarchical list, I want to have nodes that use different representations - MethodNodes, BlockNodes, AssignmentNodes etc. The contents method of ClassDrillerWrapper does something like this but it's not generic. I agree that getChildNodes has an
inherent limit. I'm going to change it to something like

getChildNodes: #wrapperName

The default behavior in Object>>getChildNodes: will be to invoke the named class. Then you can define as many different views for each node as you like. You can still override getChildNodes: to handle pre/post processing and get the best of both worlds. I'll post this over the weekend.

>
>
> >1. Get rid of the curly braces!
>
> They are generated in ParseNode>>printOn:. You could write a similar method that did not include them.

thanks

>
>
> [snip]
>
> >Comments, suggestions?
>
> One thing you will want to do is to insure that #hasContents answers truthfully about the state of #contents. Otherwise, you will walkbacks and inconsistent behavior.

Good point.

>
>
> Cheers,
> Bob

Regards,
Laurence





More information about the Squeak-dev mailing list