[Uml-devel] Thoughts about U2 "tree view"

[P. Fleury]

Andrew Sutton wrote:

>On Monday 12 May 2003 10:31 am, Sebastian Stein wrote:
>  
>
>i think one possibility would be to define some kind of action manager that 
>implements a publish/subscribe style interface. components can subscribe to 
>sets of actions (defined by text strings or maybe an enum). when the app 
>reaches a state where a set of actions need to be updated, the subscribed 
>apps are notified by a published message and they can do whatever they have 
>to. of course, i might be re-inventing a wheel with this, but i'm not a 
>KAction guru by any stretch of the imagination.
>
Netbeans, the Java IDE, has similar problems, as they see the source 
code "tree" as a repository, and several view can display that tree. In 
it, there are classes, interfaces, GUI classes, files, JSP files, 
*.class, methods, attributes, JAR files, HTML files, image files, XML, 
Ant build scripts and whatsnot... each having a different set of 
actions. Also, it is extensible enough for 3rd parties to write new node 
types, with their action sets.
They have a pattern they called cookies and data models which might suit 
our needs. Plus, they have a description in the OpenIDE specs they have 
written: 
http://www.netbeans.org/download/dev/javadoc/LoadersAPI/org/openide/loaders/doc-files/api.html

This is all designed in Java, and the only point I see which may lead to 
changes in it is the fact that the definition of a Cookie is that it 
implements the  cookie interface. It is then cast down to the proper 
type for accessing the methods. This casts exists in C++, there are a 
few in Umbrello's code, so I guess this would not even be a problem. The 
other thing to change, maybe, is the name of the pattern, as cookie is 
too netscapish ...

And this can be implemented as a layer (maybe materialized as library) 
sitting between the GUI stuff, and the MOF/UML model. Each cookie knows 
how to handle a particular action for a node, each loader knows what 
cookies to load for a particular node. The GUI can then use the set of 
cookies for a given data node to display child nodes/menu items/activate 
toolbar buttons, etc. Having it as a layer shields the MOF/UML model 
from GUI stuff, and the GUI stuff from having too much model-related code.

--Pascal