[Gzz] Repost: PEG nodeview_abstract

[Matti Katila]

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

:Author:   Matti Katila
:Stakeholders: Matti Katila
:Last-Modified: $Date: 2003/04/02 17:46:09 $
:Revision: $Revision: 1.4 $
:Status: Incomplete  

Abstract
--------

In the past we did usually have only text to show for user.
Today we have more media types: pagespans and images at least.
The View framework 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 be able to show any content in nodes.


Paragraph
---------

The Idea
""""""""

We need abstract layer where we can just place a node and 
where we shouldn't need to know what kind of types of spans 
are in the node's enfilade.


NodeView
""""""""
- org.fenfire.nodeview

The idea is to give a node to NodeView and let it put 
the right media type in the vobscene without of the fear of wrong span.
Giving the node is done through the NodeContent interface (place method)
which is implemented by NodeView.


ContentHandler
""""""""""""""
- org.fenfire.nodeview.handler

For different media types there must be handlers which can 
present the given enfilade right way.

Let's start with:
   
   - TextHandler
   - ImageHandler
   - PageSpanHandler
   
which implement ContentHandler. One important thing is that 
handlers do not work with nodes but enfilades. 


NodeView.Attrib
"""""""""""""""
- org.fenfire.nodeview

So, if texthandler wants to know the cursoroffset to render cursor, 
texthandler must ask it from NodeView.text or if PageSpanHandler 
wants to know the position for page spans pagespanhandler must ask it from 
NodeView.pagespan

NodeView.text and NodeView.pagespan are extended of the NodeView's subclass 
NodeView.Attrib.

TextAttrib which extends NodeView.Attrib would have methods get/set 
cursorOffset. 
Otoh, PageSpanAttrib would have methods best for it.

Suitable NodeView.Attrib will be passed to correct ContentHandler among other 
attributes.


NodeViewContext
"""""""""""""""
- org.fenfire.nodeview

There's continuous need to identify the accursed node. 
For example text could be reddish if it is focused or 
different box can be drawn in Loom like view if node is accursed.

That's why NodeView implements NodeViewContext which has only ''get/set 
accursed node'' interface.


Multicontent and Future
"""""""""""""""""""""""

By splitting nodeview to handlers we also ensure the future about multicontent 
nodeviews.
Multicontent node view can now be easily extended from NodeView, make it split 
enfilades to
adequate handler and there it is.


getSize
-------

You can ask from NodeContent to get width and height of the content in 1:1 
factor.
This makes it easier to make zoomable views. NodeView implements NodeContent.


Issues
------

   - How this PEG affect to view_split--tjl ?

      RESOLVED:

         -PEG's status is irrelevant.

   - How this PEG affect to cellview_naming--benja?

      RESOLVED:

         -PEG's status is irrelevant.

   - 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. 

   - What if one wants to change color of text?

      RESOLVED:
  
         - NodeView.text.setColor(Color c) which replaces or sets
           current TextVob with better color.

   - Do we really need ContentHandler interface?

      I don't know if java has speed problems because of this as does C++ has. 
      If it has got speed issue we can forget handler interface and call 
directly
      the specific handler.

   - How this PEG affect to ViewContext?

      RESOLVED:
         
         In Loom like view extend NodeView to LoomView by implementing the 
         old ViewContext. This change makes it very easy to transfer all 
         wanted data around without java's ugly type casting.

   - Is NodeViewContext in right place? Should this be an issue as same as the 
     previous ViewContext issue?

      UNRESOLVED.

   - Should getSize return Dimension rather than float[2]?

      UNRESOLVED.


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

.. UML:: Abstract-of-NodeView

   class NodeViewContext "interface"
      methods
         RDFNode getAccursed()
         void setAccursed(RDFNode node)
 
   class NodeContent "interface"
      methods
         +float[] getSize(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
         +TextAttrib text
         +ImageAttrib image
         +PageSpanAttrib pagespan

   class NodeView.Attrib "SubClassOfNodeView"

   class ContentHandler "interface"
      methods
         +void place(VobScene vs, int box, Enfilade enf, NodeView.Attrib 
attrib, boolean accursed=false)
         +float[] getSize(Enfilade enf)

   class TextHandler
      realize ContentHandler

   class TextAttrib
      inherit NodeView.Attrib
      methods
         int getCursorOffset(RDFNode node=null)
         void setCursorOffset(int offs, RFDNode node)

   class ImageHandler
      realize ContentHandler
   
   class PageSpanHandler
      realize ContentHandler

   class PageSpanAttrib
      inherit NodeView.Attrib
      methods
         int getFooo


   dep "gets cursorOffset or pagespan attributes etc.." ContentHandler NodeView
   dep "subClass" NodeView.Attrib NodeView              

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

   horizontally(150, nodeview_h, NodeView, NodeView.Attrib, TextAttrib);
   vertically(50, attrib, TextAttrib, PageSpanAttrib)