Hi Enrico, hi Bob,
what I don't understand is, if the module is developed for the latest stable
release 0.28.1, in which case Bob's proposal would not be applicable, or for
the current svn version, in which case we could indeed find a way how ArgoUML
could be modified so that the module can benefit from that. Enrico, can you
tell on which code base of ArgoUML do you develop?
I'll first answer Bob's mail:
> public class GetterSetterActionFactory {
> public class GetterSetterActionFactory() {
> }
>
> public Action createAction(Object modelElement) {
> if (Model.getFacade().isAClass(modelElement) ||
> Model.getFacade().isAInterface(modelElement)) {
> // This is creating an instance of your own Action class
> return new GetterSetterAction(modelElement);
> } else {
> // The action is required in the context so return null
> return null;
> }
> }
> }
>
>
> It registers those through some means like this
>
> ContextMenuManager.getInstance().addActionFactory(new
> GetterSetterActionFactory());
>
> When ArgoUML creates a context menu on the explorer or on a diagram
> Fig it calls each of these factories in turn by querying the
> ContextMenuManager. If the factory decides that the menu item is
> needed from the context passed to it (the model element) then it adds
> that action to the menu before displaying it to the user.
>
> So we need some internal changes to allow for this in a clean way but
> I think that is better than having module writers tie themselves
> directly to our diagram and explorer implementations that may change
> in future.
Yes, I agree! I like the factory approach. Maybe the check if the action should
be created could be extracted, but then could it still be in the factory, or is
a helper needed? This change is quickly done, but there should be a feature
request in issuezilla.
And here is my answer to Enricos most recent mail, comments inline:
> Yay! (pretty long)
> I did mainly everything, now this are things done (all with
> PropPanelFactory-like approach)
>
> 1) Added a button with action on the PropPanel following the type of the
> target
> (in my specific case isAClass)
> 2) Added a button with action on the Toolbar understanding if it's a
> manipulate/uml/comment/shape action
> 3) Added a new menu element on the Explorer panel associated with the type
> of
> object to create (with the MetaType that in my situation is an Attribute)
> 4) Added a context menu for the module plus the menuitem based on the type
> of
> container (in my situation is a FigClass)
>
> What are my doubts now?
>
> a) I don't understand if i should use the org.argouml.i18n.Translator or
> the
> cogintive one
You should use the Translator, just have a look into the sources of the Java or
C++ module how this is done.
> b) Is there a way to add my resource files (the ones into the module) to
> the
> ones seen by the Translator (the problem raise on the Explorer panel where
> the
> mapping seems to be done internally, i have not seek'd too much)
Have a look into the sources of the Java module, or the C++ module:
http://argouml-cpp.tigris.org/source/browse/argouml-cpp/trunk/src/org/argouml/
> c) Same thing inside the Explorer panel for the icon to show, i have mine
> in my
> module but i don't get how to associate it
I don't know the answer to this one. The C++ module has some icons inside (the
Java module too, but I don't use them), so maybe Luis can tell more.
> After this comes the cleansing of the whole stuff but i have some other
> doubt
> about this, mainly because of the different approaches to the context menu
> /explorer menu/toolbar generation.
> Now i managed to let everything works but there are very etherogenous ways
> to
> create all these things (yes they are different but...i like to suffer :P
> )
> 1) Property Panel, use the PropPanelClass that adds the button with the
> (Undouable)Action and creates, eventually its own property panel. It
> knows what
> is the element on wich should work
> 2) Toolbar, as far as i ve seen it's built inside the UMLDiagram, it works
> with
> straight Object[] for the various kind of elements. Use the targetFollower
> defined in the (Undouable)Action at 1)
> 3) Explorer Popup, relies on a static array of types and actions, it uses
> the
> type (if i understood well) given in this array to understand if the
> object
> select allows the specific (Undouable)Action at 1)
> 4) Context Menus, relies on the Fig* implementation, it understand (in my
> implementation) the instanceof the class to allow the menu to appear with
> the
> right elements
>
> Do you think this approach could be ok?
>
> Of course as far as i have a consistent (and cleaned, and commented)
> system i
> will let you have the code for all these things, of course if there is
> someone
> interested in this
OK, would make things easier to discuss. So basically, you managed to get work
everything, though you needed to go deep into the ArgoUML implementation, which
is not optimal. That's why I asked if it's OK for you if we build the needed
API now, or if it's too late for you.
By the way: for ad hoc question, there is also the #argouml irc channel.
Thomas
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2409751
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
