Hi Tom I do see your point. We need to be able to manage where names are null and if we don't create them as such we can't be sure our code is robust against models from other tools.
In some ways having some default text is a waste of time. When generating the text newOperation() we know we want the user to change it. However it does act as a visual cue to the user of where something was created and where to change and also the format of what to change. e.g. "attribute : Integer" clearly shows the format of entry before the user even double clicks to edit the string. It is certainly a waste of time when called from some non-gui subsystem like reverse engineering. The code will be doing more than it needs to in setting a default name and then overwriting with the method/variable name found in the code. I guess in a perfect world the model elements should always be created with a null name but the notation for the Fig should display this appropriately as "unnamed attribute" in greyscale. We would have quite some work on our hands to achieve that now. On the other hand there is a part of me that feels it is the duty of the model subsystem to create elements in as close to a well-formed state as it can and so there should be some default if only an empty string. We also need to be more consistent where we do create default values. For example double click on the attribute compartment in FigClass and an attribute is created "newAttr : Integer". Press the new attribute button in the property panel and it is just created as "newAttr". I'm against doing this work in Actions as it requires that work to be spread over several actions. Actions are also swing classes and we have RCP in mind in the long term. The setting of any default value should be in a factory still. Question is should that be a new factory class that is outside of the model subsystem or still the responsibility of some part of the model subsystem. Now that the panels are driven my the meta model (indirectly at the moment by the panels xml file) there is now far more use of the UmlFactory.buildNode and buildConnection methods rather than the specific factory method for a type (e.g. CoreFactory.createAttribute). I would suggest we either move the responsibility for giving a default value to the UMLFactory methods and have the GUI consistently use those. Else we create a new factory in kernel with methods that act as a proxy to the main UmlFactory methods and that factory gives the added value of providing defaults. I'm leaning towards the latter because we would want the same default value for things whether they are UML1.4 or UML2. I wouldn't want to see default values removed from elsewhere until that that other mechanism is in place though. Regards Bob. On 8 April 2010 21:52, Tom Morris <[email protected]> wrote: > When doing some of the merge work I came across places where code has > been added to give newly created elements names like "newOperation" or > "arg1." > > I don't feel the model subsystem is the appropriate place for this > code because it has no knowledge of the user's language, so there is > no way to localize this. The strategy the initial implementation took > was to not set the names of newly created objects. If this causes > serious problems someplace, we could set the names to the empty > string, but since there's no guarantee that models we receive from > other tools will have the name set, I think the null name case needs > to be dealt with anyway, so that would be my preference. > > What are others' thoughts on this? > > Tom > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2525354 > > 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]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2529719 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]]
