[ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum...

[Asko Soukka]

CVSROOT:        /cvsroot/fenfire
Module name:    fenfire
Branch:         
Changes by:     Asko Soukka <address@hidden>    03/09/10 07:11:48

Modified files:
        docs/pegboard/view_nodetypemanager--humppake: peg.rst 

Log message:
        fixes

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst.diff?tr1=1.7&tr2=1.8&r1=text&r2=text

Patches:
Index: fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst
diff -u fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst:1.7 
fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst:1.8
--- fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst:1.7    Wed Sep 
10 04:59:40 2003
+++ fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst        Wed Sep 
10 07:11:47 2003
@@ -4,8 +4,8 @@
 
 :Authors:  Asko Soukka
 :Date-Created: 2003-09-09
-:Last-Modified: $Date: 2003/09/10 08:59:40 $
-:Revision: $Revision: 1.7 $
+:Last-Modified: $Date: 2003/09/10 11:11:47 $
+:Revision: $Revision: 1.8 $
 :Status:   Current
 :Stakeholders: tjl, mudyc
 :Scope:    Minor
@@ -46,7 +46,7 @@
 
        RE-RESOLVED: String as the return value has less restrictions.
 
-Why int? Why not, e.g., String or URL?
+Wouldn't String be better ``getNodeTypeId()`` return value than integer?
 
        RESOLVED: Right. Int as the return value would be too dangerous,
         because        we can't control that two distinct applitudes (developed
@@ -61,10 +61,14 @@
 
        RE-RESOLVED: Object as the return value has even less restrictions :)
 
-Why String? Why not Object?
+Wouldn't Object be even better ``getNodeTypeId()`` return value than String?
 
        RESOLVED: Yeah, right... Using object allows e.g. usage of individual
-        nodes as an unique identifier for a node type.
+        nodes as an unique identifier for a node type. Altought, using Object
+       may complicate the use of identifier (since we have to know it's type
+       from the context). Still the usage of Object as return value
+        is versatile and therefore could be a good solution in such
+        common level interface like this.
 
        Let it be::
 
@@ -80,7 +84,8 @@
 needed BuoyViewConnectors and sufficient node types.
 
        NOTE: Node types in Fenfire are currently
-       inherited from ``org.fenfire.view.buoy.AbstractNodeType2D``.
+       inherited from ``org.fenfire.view.buoy.AbstractNodeType2D``,
+       which implements ``org.nongnu.libvob.buoy.BuoyViewNodeType``.
 
 A major problem with the current implementation is that also the logic
 for resolving the node type is written into BuoyViewConnectors -
@@ -93,7 +98,7 @@
 ``org.fenfire.view.NodeTypeManager`` with a method for querying the
 type for a node object::
 
-       AbstractNodeType2D getNodeType(Object o);
+       BuoyViewNodeType getNodeType(Object o);
 
 Fenfire applitudes should implement the interface only once, but so
 that the node type querying method is reachable from all the relevant
@@ -121,7 +126,7 @@
             * @param o The node object, which node type is to be resolved.
             * @return An AbstractNodeType2D for the given node object.
             */
-           public AbstractNodeType2D getNodeType(Object o);
+           public BuoyViewNodeType getNodeType(Object o);
        }
 
 Implement the interface into FenPDF 
(``org.fenfire.fenpdf.FenPDFNodeTypeManager``).
@@ -132,5 +137,11 @@
 
 Modify BuoyViewConnectors ``org.fenfire.view.buoy.TTConnector`` and
 ``org.fenfire.view.buoy.TransclusionConnector`` to use
+BuoyViewNodeTypes instead of AbstractNodeViewType2D.
+
+Modify BuoyViewConnectors ``org.fenfire.view.buoy.TTConnector`` and
+``org.fenfire.view.buoy.TransclusionConnector`` to use
 NodeTypeManager.
+
+