[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum...
From: |
Asko Soukka |
Subject: |
[ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum... |
Date: |
Tue, 09 Sep 2003 13:54:54 -0400 |
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``).
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/09
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/09
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/09
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum...,
Asko Soukka <=
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/10
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/10
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/10
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/10
- [ff-cvs] fenfire/docs/pegboard/view_nodetypemanager--hum..., Asko Soukka, 2003/09/12