[Gzz-commits] fenfire/docs/pegboard/nodeview_abstract--mudyc ...

[Matti Katila]

CVSROOT:        /cvsroot/fenfire
Module name:    fenfire
Changes by:     Matti Katila <address@hidden>   03/04/02 06:41:29

Modified files:
        docs/pegboard/nodeview_abstract--mudyc: peg.rst 

Log message:
        a big upgrade

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst
diff -u fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.1 
fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.2
--- fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.1  Wed Apr  2 
03:07:55 2003
+++ fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst      Wed Apr  2 
06:41:29 2003
@@ -4,70 +4,117 @@
 
 :Author:   Matti Katila
 :Stakeholders: Matti Katila
-:Last-Modified: $Date: 2003/04/02 08:07:55 $
-:Revision: $Revision: 1.1 $
+:Last-Modified: $Date: 2003/04/02 11:41:29 $
+:Revision: $Revision: 1.2 $
 :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. 
+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 show any content in nodes.
+easily be able to show any content in nodes.
 
 
-Issues
-------
+Paragraph
+---------
 
-   - How this PEG affect to view_split--tjl ?
+The Idea
+""""""""
 
-   - How this PEG affect to cellview_naming--benja?
+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.
 
-   - 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. 
 
+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.
 
-Changes
--------
 
-Abstract ViewContext to NodeViewContext and ViewContext.
-  
-   Reason: In zz/Loom like views it is necessarily to have such methods as:
-    
-      -isMarked
+ContentHandler
+""""""""""""""
+- org.fenfire.nodeview.handler
 
-      -getCursorColors
+For different media types there must be handlers which can 
+present the given enfilade right way.
+
+Let's start with:
+   
+   - TextHandler
+   - ImageHandler
+   - PageSpanHandler
+   
+which implements ContentHandler. One important thing is that 
+handlers do not work with nodes but enfilades. 
 
-   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
+NodeView.Attrib
+"""""""""""""""
+- org.fenfire.nodeview
 
-      -setAccursed
+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
 
-      -getCursorOffset
+NodeView.text and NodeView.pagespan are extended of the NodeView's subclass 
NodeView.Attrib.
 
-   The last one is important because of frequency of textspans.
-   The rest of ViewContext would stay as it is.
+TextAttr which extends NodeView.Attributes would have methods get/set 
cursorOffset. 
+Otoh, PageSpanAttr would have methods best for it.
 
-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.
+Suitable NodeView.Attrib will be passed to ContentHandler among other 
attributes.
 
-NodeView is abstract class which encloses the whole thing.
 
-I hope the uml explains more ;)
+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!
+
+get"Size"
+---------
+
+You can ask from NodeContent to get width and height.
+
+
+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. 
+
+
+Optional Changes
+----------------
+
+In Loom like view extend NodeView to LoomView implementing the old ViewContext.
+This change makes it very easy to transfer all wanted data around without 
java's ugly type casting.
 
 
 UML figure
@@ -79,8 +126,7 @@
       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)
@@ -94,27 +140,45 @@
          +ContentHandler imageHandler
          +ContentHandler pageSpanHandler
          -RDFNode accursed
-         -int cursorOffset
- 
+         +NodeView.Attrib text
+         +NodeView.Attrib image
+         +NodeView.Attrib pagespan
+
+   class NodeView.Attrib SubClassOfNodeView
+
    class ContentHandler "interface"
       methods
-         +void place(VobScene vs, int box, Enfilade enf, NodeView nv=null)
+         +void place(VobScene vs, int box, Enfilade enf, NodeView.Attrib 
attrib, RDFNode accursed=null)
          +float[] getW[idth]H[eight](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
 
-   dep "gets accursed or cursorOffset" ContentHandler NodeView
-           
+   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(100, nodeview_h, NodeView, NodeView.Attrib, TextAttrib);
+   vertically(50, attrib, TextAttrib, PageSpanAttrib)
\ No newline at end of file