[Fenfire-dev] PEG NodeTypeManager

[Asko Soukka]

==========================================================================
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/>