Re: [Gzz] cellview_naming

[Tuomas Lukka]

On Sat, Nov 02, 2002 at 03:08:42PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >benja wrote:
> > 
> >
> >>- ``CellView`` to ``CellBoxView``
> >>
> >>``CellContentView`` keeps its name. This makes sense because after all,
> >>both ``CellBoxView`` and ``CellContentView`` are just ways to view
> >>a cell, one with and one without a box around.
> >>   
> >>
> >
> >I disagree; having separate interfaces makes using CellInBoxHook a bother:
> >you can't then use it for either of the derived interfaces, since they
> >are abstract classes..
> >
> 
> Hm. There is no CellInBoxHook class as far as I can see, but I presume 
> you mean CellPlacementHook/CellInBoxPlugin. What are the intended use 
> cases for them? (It would be nice if this could be in the javadoc...)

This is intended to be there ;)

Sorry about that, the 5th day deadline is pressing badly.

The intended use case for now is floating buoys. For each cell placed in the 
cellview,
I get a call and can place a buoy if I like.

I'm not yet sure whether this will really be 

> I don't know, I like to have two different classes simply because 
> through static typing, it avoids putting a box inside a box inside a box 
> inside a box for a single cell... On the other hand, I wouldn't mind a 
> cellview that would be just the content, without any box around. Hmmm.
> 
> -- If the user of the interface declares it so, I guess it should be 
> possible to have box-in-box-in-box too, 

Agreed.

> but the problem is that 
> currently the CellView gets the CellContentView from the ViewContext:
> 
> CellView getCellView(); // used in the View
> CellContentView getCellContentView(); // used in the cell view
> 
> If a CellView were returned by getCellContentView(), that CellView would 
> potentially call getCellContentView().place() and go into an infinite loop.
> 
> It would be possible to have only the CellView interface and make the 
> box views work like this:
> 
> BoxCellView(CellView sub) { this.sub = sub; }
> void place(...) {
> -- Place the box, set the clipping.
> sub.place(...); // inside the box
> -- Remove the clipping.
> }
> 
> The problem I see with this is that the box view and the content view 
> are not independently selectable.

Well, they can be if we make a CellViewFactory whose only job is to
return a given cellview with the given cellcontentview.

But that might get nasty.

But it goes even further: actually, I think that ViewContext may not be
the right approach. Consider, for example, MultitypeCellContentView.
Now, if I want my text to be shown in a different way, that doesn't happen;
if we wanted that to work with this approach, then you'd need
getTextCellContentView() and getImageCellContentView() for ViewContext and .. 
yurck.

I think that maybe taking the approach you outline above would be better
(passing parameters in constructor).

        Tuomas