gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matti Katila
Subject: [Gzz] PEG: Abstract node view, context and content
Date: Wed, 2 Apr 2003 11:29:06 +0300 (EEST)

=====================================================================
PEG nodeview_abstract--mudyc: Abstract node view, context and content
=====================================================================

:Author:   Matti Katila
:Stakeholders: Matti Katila
:Last-Modified: $Date: 2003/04/02 08:07:55 $
:Revision: $Revision: 1.1 $
:Status: Incomplete  

Abstract
--------

In the past we did have usually text to show for user.
Today we have more medias: pagespans and images at least.
Views has been designed too much for text only. 
Text based design is also very deeply seen in Space where we have 
*VStreamNodeTexter* but that's an another story. 
Although text is the most common view media we should 
easily show any content in nodes.


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. 


Changes
-------

Abstract ViewContext to NodeViewContext and ViewContext.
  
   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. 
   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.

Drop CellView and make content handler instead of it.
ContentHandler can place content in vobscene. 
We would have own handlers for different spans, i.e., TextHandler and 
ImageHandler.
Handlers do not work with nodes but enfilades. 
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.

I hope the uml explains more ;)


UML figure
----------

.. UML:: Abstract-of-NodeView

   class NodeViewContext "interface"
      methods
         RDFNode getAccursed()
         void setRDFNode(RDFNode node)
         int getCursorOffset(RDFNode node=null)

   class NodeContent "interface"
      methods
         +float[] getW[idth]H[eight](RDFNode node, float scale=1)
         +void place(RDFNode node, VobScene vs, int box)

   class NodeView "Abstract"
      realize NodeViewContext
      realize NodeContent 
      fields
         +ContentHandler textHandler
         +ContentHandler imageHandler
         +ContentHandler pageSpanHandler
         -RDFNode accursed
         -int cursorOffset
 
   class ContentHandler "interface"
      methods
         +void place(VobScene vs, int box, Enfilade enf, NodeView nv=null)
         +float[] getW[idth]H[eight](Enfilade enf)

   class TextHandler
      realize ContentHandler

   class ImageHandler
      realize ContentHandler
   
   class PageSpanHandler
      realize ContentHandler

   dep "gets accursed or cursorOffset" ContentHandler NodeView
           

   -----
   horizontally(150, cont_h, TextHandler, ImageHandler, PageSpanHandler);
   horizontally(150, node_h, NodeViewContext, NodeContent);
   vertically(200, all, ImageHandler, ContentHandler, NodeView, 
NodeViewContext); 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]