[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] cellview_naming
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] cellview_naming |
Date: |
Sat, 2 Nov 2002 16:25:04 +0200 |
User-agent: |
Mutt/1.4i |
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
- [Gzz] cellview_naming, Tuomas Lukka, 2002/11/02
- Re: [Gzz] cellview_naming, Benja Fallenstein, 2002/11/02
- Re: [Gzz] cellview_naming,
Tuomas Lukka <=
- Re: [Gzz] cellview_naming, Benja Fallenstein, 2002/11/02
- Re: [Gzz] cellview_naming, Tuomas Lukka, 2002/11/02
- Re: [Gzz] cellview_naming, Benja Fallenstein, 2002/11/02
- Re: [Gzz] cellview_naming, Tuomas Lukka, 2002/11/02
- Re: [Gzz] cellview_naming, Benja Fallenstein, 2002/11/02