[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fenfire-dev] PEG NodeTypeManager
From: |
Asko Soukka |
Subject: |
[Fenfire-dev] PEG NodeTypeManager |
Date: |
Tue, 9 Sep 2003 16:23:27 +0300 |
User-agent: |
Mutt/1.4.1i |
==========================================================================
PEG view_nodetypemanager--humppake: NodeTypeManager
==========================================================================
:Authors: Asko Soukka
:Date-Created: 2003-09-09
:Last-Modified: $Date: 2003/07/28 13:53:51 $
:Revision: $Revision: 1.4 $
:Status: Current
:Stakeholders: tjl, mudyc
:Scope: Minor
:Type: Interface
This PEG introduces a new interface to generalize the handling of
different node types in Fenfire.
The visualization of ImageScrollBlock in Fenfire requires a new
nodetype besides the current node types for 2DCanvases (papers) and
PageScrollBlocks (PDFs). Unfortunately, the selecting between those
two node types is fixed in the current code. The interface introduced
by this PEG is needed to generalize the way of handling several
different node types and therefore make it easier to add new types
also later on.
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
local keybindings depending on the type of the current main
node (know also as *plane*, or *focus*).
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.
int getNodeTypeID(Object o);
NOTE: The class implementing ``NodeTypeManager`` should define
constants for
return vales of ``getNodeTypeID``.
Changes
=======
Create interface ``org.fenfire.view.NodeTypeManager`` with methods::
AbstractNodeType2D getNodeType(Object o);
int getNodeTypeID(Object o);
Implement the interface to FenPDF
(``org.fenfire.fenpdf.FenPDFNodeTypeManager``).
Modify ``org.fenfire.fenpdf.appearance.views.Views()`` to use
FenPDFNodeTypemanager and to se it also into created
BuoyViewConnectors.
Modify BuoyViewConnectors ``org.fenfire.view.buoy.TTConnector`` and
``org.fenfire.view.buoy.TransclusionConnector`` to use
NodeTypeManager.
--
Asko Soukka <address@hidden>
<http://www.iki.fi/asko.soukka/>
- [Fenfire-dev] PEG NodeTypeManager,
Asko Soukka <=