[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/09 13:54:54

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

Log message:
        update

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst.diff?tr1=1.3&tr2=1.4&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.3 
fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst:1.4
--- fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst:1.3    Tue Sep 
 9 09:37:15 2003
+++ fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst        Tue Sep 
 9 13:54:53 2003
@@ -4,15 +4,15 @@
 
 :Authors:  Asko Soukka
 :Date-Created: 2003-09-09
-:Last-Modified: $Date: 2003/09/09 13:37:15 $
-:Revision: $Revision: 1.3 $
+:Last-Modified: $Date: 2003/09/09 17:54:53 $
+:Revision: $Revision: 1.4 $
 :Status:   Incomplete
 :Stakeholders: tjl, mudyc
 :Scope:    Minor
 :Type:     Interface
 
 This PEG introduces a new interface to generalize the handling of
-different node types in Fenfire.
+different visual node types in Fenfire.
 
 The visualization of ImageScrollBlock in Fenfire requires a new
 nodetype besides the current node types for 2DCanvases (papers) and
@@ -25,39 +25,6 @@
 Issues
 ======
 
-How are the different node types handled currently?
-
-       RESOLVED: BuoyViewConnectors have a public attribute for every
-        node type to be recognized (*currently only two*). The Fenfire
-        applitude (*currently FenPDF*) creates those node types needed and
-       sets them into created connectors.
-
-       NOTE: Node types in Fenfire are currently
-       inherited from ``org.fenfire.view.buoy.AbstractNodeType2D``.
-
-How is the right node type resolved/selected?
-
-       RESOLVED: The logic to resolve the type of the active main
-        node is currently decentralized into
-        BuoyViewConnectors.
-
-       COMMENT: Definitely, this is bad when the amount of connectors
-        and node types do increase.
-
-How should the right node type be resolved/selected?
-
-        RESOLVED: As centralized as possible. This PEG proposes an
-        interface ``org.fenfire.view.NodeTypeManager`` with a method
-       for querying the type for the node::
-
-         AbstractNodeType2D 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 parts of the applitude. Of course, the implementation
-        of the interface, holds the logic of resolving node types in
-        that applitude.
-
 Are node types relevant anywhere else than in visualization?
 
        RESOLVED: Yes, they are. We have been planning the use of
@@ -69,23 +36,78 @@
 
        RESOLVED: The module handling keybindings has no use for 
AbstractNodeType2D
        designed for visualization, but a simple Id specifying the node type 
would
-       be enough and simpler to use.
+       be enough and simpler to use:
 
          int getNodeTypeId(Object o);
 
        NOTE: The class implementing ``NodeTypeManager`` should define 
constants for
        return vales of ``getNodeTypeId``.
 
-Should the meanings for integers be fixed somewhere high enough to be same for 
all the
-Fenfire applitudes?
+       RE-RESOLVED: String as the return value has less restrictions.
+
+Why int? Why not, e.g., String or URL?
+
+       RESOLVED: Right. Int as return value would be too dangerous,
+        because        we can't control that two distinct applitudes (developed
+        without knowing each other) don't overlapping values.
+
+       String allows e.g. usage of URN-5 as an unique identifier for
+        a node type.
+
+       Let it be::
+
+         String getNodeTypeId(Object o);
+
+Introduction
+============
+
+Currently the BuoyViewConnectors have a public attribute for every
+node type they can recognized (*currently only
+two*). BuoyViewConnetors' public node type atributes are set by a
+Fenfire applitude (*currently FenPDF*) after it has created both the
+needed BuoyViewConnectors and sufficient node types.
+
+       NOTE: Node types in Fenfire are currently
+       inherited from ``org.fenfire.view.buoy.AbstractNodeType2D``.
+
+A major problem with the current implementation is that also the logic
+for resolving the type of node is written into BuoyViewConnectors -
+currently every BuoyViewConnector must have its own code to recognize
+all the existing node types. This decentralization is has already became
+a bottleneck for adding new node types or BuoyViewConnectors.
+
+This PEG resolves the bottleneck by centralizing the recognization of
+the type of any node. This PEG proposes an interface
+``org.fenfire.view.NodeTypeManager`` with a method for querying the
+type for the node::
+
+       AbstractNodeType2D 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
+parts of the applitude. Of course, the implementation of the
+interface, holds the logic of resolving node types in that applitude.
 
 Changes
 =======
 
-Create interface ``org.fenfire.view.NodeTypeManager`` with methods::
+Create interface ``org.fenfire.view.NodeTypeManager``::
 
-         AbstractNodeType2D getNodeType(Object o);
-         int getNodeTypeId(Object o);
+       /** Interface for methods to resolve the visual type
+        * of a node object.
+        */
+       public interface NodeTypeManager {
+    
+           /** Return an Id value corresponding the node type of given node.
+            * @return The Id value for the node type of the given node.
+            */
+           public int getNodeTypeID(Object o);
+       
+           /** Return the  AbstractNodeType2D for the given node object.
+            * @return The AbstractNodeType2D for the given node object.
+            */
+           public AbstractNodeType2D getNodeType(Object o);
+       }
 
 Implement the interface to FenPDF 
(``org.fenfire.fenpdf.FenPDFNodeTypeManager``).