fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fenfire-dev] PEG NodeTypeManager


From: Tuomas Lukka
Subject: Re: [Fenfire-dev] PEG NodeTypeManager
Date: Tue, 9 Sep 2003 18:20:09 +0300
User-agent: Mutt/1.5.4i

On Tue, Sep 09, 2003 at 04:23:27PM +0300, Asko Soukka wrote:
> ==========================================================================
> 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.

A very good introduction!

> 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``.

Again, a non-issue issue.

An issue is something that needs to be decided about what this PEG specifies.
This is not like that, and should go after the issues as an "Introduction" 
section.

> 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.

Same here

> 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.

This is more real issue. But even this rings a little fake, and would
be better down below. Issues are best kept short.

> 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``.

ISSUE: Why int? Why not, e.g., String or URL?

> Changes
> =======
> 
> Create interface ``org.fenfire.view.NodeTypeManager`` with methods::
> 
>         AbstractNodeType2D getNodeType(Object o);
>         int getNodeTypeID(Object o);

In this situation, it might be better to give the whole class here,
with all javadocs as they will be on the final version.

> 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.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]