Re: [Fenfire-dev] PEG NodeTypeManager (#3)

[Tuomas Lukka]

On Wed, Sep 10, 2003 at 11:57:58AM +0300, Asko Soukka wrote:
> ==========================================================================
> PEG view_nodetypemanager--humppake: NodeTypeManager
> ==========================================================================
> 
> :Authors:  Asko Soukka
> :Date-Created: 2003-09-09
> :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.
> 
> 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
> ======
> 
> 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 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.





> Why int? Why not, e.g., String or URL?
> 
>       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 use overlapping values.
> 
>       Using string allows e.g. usage of URN-5 as an unique
>         identifier for a node type.
> 
>       Let it be::
> 
>         String getNodeTypeId(Object o);
> 
>       RE-RESOLVED: Object as the return value has even less restrictions 
> :)
> 
> Why String? Why not Object?
> 
>       RESOLVED: Yeah, right... Using object allows e.g. usage of 
> individual
>         nodes as an unique identifier for a node type.
> 
>       Let it be::
> 
>         Object getNodeTypeId(Object o);


I already mentioned these: the issue should be complete or explicitly refer
to another issue. "Why int?" -- *WHAT* should be int? 

        Tuomas