Re: [Gzz] PEG: Abstract node view, context and content

[Tuomas Lukka]

Mudyc: great work! Glad to see active PEGging going on.
Lots of comments - the ideas seem quite good, but you really
need to work on the presentation. Which this is great practice for!

On Wed, Apr 02, 2003 at 11:29:06AM +0300, Matti Katila wrote:
> In the past we did have usually text to show for user.

...we did usually have only...

> Today we have more medias: pagespans and images at least.

..more media types..

> Views has been designed too much for text only. 

Views have..

or

The View framework has

> Text based design is also very deeply seen in Space where we have 
> *VStreamNodeTexter* but that's an another story. 

A very important one, though... 
Actually, "texter" is a misnomer since it gives enfilades.

> Although text is the most common view media we should 
> easily show any content in nodes.

... easily be able to ...


> Issues
> ------
> 
>    - How this PEG affect to view_split--tjl ?
> 
>    - How this PEG affect to cellview_naming--benja?
> 
>    - What's view? I think view is buzzword. It says too much and nothing. 
>      In Loom there are simple and wheel view but the change between them is 
>      just about geometry. The reason I'm raising this issue now is about 
>      package naming and future where I think it's more common to view 
>      heap of nodes(you can image them as links also) instead of just one 
> node. 

Yes, the type of view you showed me which uses a bunch of cells is 
hard to place within these terms.

> Changes
> -------
> 
> Abstract ViewContext to NodeViewContext and ViewContext.

Before going into reason, you should explain what the division of labour is
between these. Just saying this doesn't tell me much.

>    Reason: In zz/Loom like views it is necessarily to have such methods as:
>     
>       -isMarked
> 
>       -getCursorColors
> 
>    Which are not very important in generality of NodeViewContext. 

What exactly are the responsibilities of NodeViewContext?

>    In focus+context views such as buoyoing we are only interested in
>    the focus. In NodeViewContext I would propouse the following methods:
> 
>       -getAccursed
> 
>       -setAccursed
> 
>       -getCursorOffset
> 
>    The last one is important because of frequency of textspans.
>    The rest of ViewContext would stay as it is.

Issue: If CursorOffset is important, what about e.g. position for page spans?

> Drop CellView and make content handler instead of it.

"Replace CellView with ContentHandler"

- why, what does ContentHandler do, 
  what's the difference between that and CellView?

- instead of "replace foo with bar" say "replace foo, which did X, with bar, 
that will do Y,
  because it's better because of Z"

> ContentHandler can place content in vobscene. 

That sentence doesn't say anything to me.

> We would have own handlers for different spans, i.e., TextHandler and 
> ImageHandler.

Subclasses of ContentHandler? 

> Handlers do not work with nodes but enfilades. 

This is the fact you should have started with.

> This is needed in future where we need to split enfilades to different 
> handlers
> because of multicontent nodes.
> 
> NodeView is abstract class which encloses the whole thing.

What whole thing?

> I hope the uml explains more ;)

Have you heards of CRC cards? A short description like those would also help a 
lot
before running into UML. Basically, just naming the classes and their 
responsibilities
and collaborations.

The UML doesn't explain much if you don't know how to start to read it...

        Tuomas