[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 01:33:14

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.4&tr2=1.5&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.4 
fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst:1.5
--- fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst:1.4    Tue Sep 
 9 13:54:53 2003
+++ fenfire/docs/pegboard/view_nodetypemanager--humppake/peg.rst        Wed Sep 
10 01:33:13 2003
@@ -4,15 +4,15 @@
 
 :Authors:  Asko Soukka
 :Date-Created: 2003-09-09
-:Last-Modified: $Date: 2003/09/09 17:54:53 $
-:Revision: $Revision: 1.4 $
-:Status:   Incomplete
+:Last-Modified: $Date: 2003/09/10 05:33:13 $
+:Revision: $Revision: 1.5 $
+:Status:   Current
 :Stakeholders: tjl, mudyc
 :Scope:    Minor
 :Type:     Interface
 
 This PEG introduces a new interface to generalize the handling of
-different visual 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
@@ -34,25 +34,26 @@
 What methods the use of node type dependent keybindings would need from
 interface ``NodeTypeManager``?
 
-       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:
+       RESOLVED: The module handling keybindings has no particular use for
+       AbstractNodeType2D designed for visualization (and it using it would
+        make the architecture less flexible), but a simple Id
+        specifying the node type would be enough and simpler to use:
 
          int getNodeTypeId(Object o);
 
        NOTE: The class implementing ``NodeTypeManager`` should define 
constants for
        return vales of ``getNodeTypeId``.
 
-       RE-RESOLVED: String as the return value has less restrictions.
+       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,
+       RESOLVED: Right. Int as the return value would be too dangerous,
         because        we can't control that two distinct applitudes (developed
-        without knowing each other) don't overlapping values.
+        without knowing each other) don't use overlapping values.
 
-       String allows e.g. usage of URN-5 as an unique identifier for
-        a node type.
+       Using string allows e.g. usage of URN-5 as an unique
+        identifier for a node type.
 
        Let it be::
 
@@ -63,7 +64,7 @@
 
 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
+two*). BuoyViewConnetors' public node type attributes are set by a
 Fenfire applitude (*currently FenPDF*) after it has created both the
 needed BuoyViewConnectors and sufficient node types.
 
@@ -71,48 +72,51 @@
        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 -
+for resolving the node type 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
+all the existing node types. This decentralization 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
+the node type. This PEG proposes an interface
 ``org.fenfire.view.NodeTypeManager`` with a method for querying the
-type for the node::
+type for a node object::
 
        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.
+interface, holds the logic for resolving node types in that applitude.
 
 Changes
 =======
 
 Create interface ``org.fenfire.view.NodeTypeManager``::
 
-       /** Interface for methods to resolve the visual type
+       /** 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.
+           /** Resolve an identifier string unique to the
+            * node type of the give node object.
+            * @param o The node object, which node type is to be resolved.
+            * @return An 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.
+           /** Resolve the node type for the given node object.
+            * @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);
        }
 
-Implement the interface to FenPDF 
(``org.fenfire.fenpdf.FenPDFNodeTypeManager``).
+Implement the interface into FenPDF 
(``org.fenfire.fenpdf.FenPDFNodeTypeManager``).
 
 Modify ``org.fenfire.fenpdf.appearance.views.Views()`` to use
-FenPDFNodeTypemanager and to se it also into created
+FenPDFNodeTypemanager and to set it also into created
 BuoyViewConnectors.
 
 Modify BuoyViewConnectors ``org.fenfire.view.buoy.TTConnector`` and