Bugzilla – Full Text Bug Listing
| Summary: | Tigerstripe incorrectly assumes a naming conflict when a new artifact is created in a diagram | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] Tigerstripe | Reporter: | Navid Mehregani <nmehrega> | ||||
| Component: | Diagrams | Assignee: | Project Inbox <tigerstripe.diagram-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | chrhartl, erdillon, rcraddoc | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 0.5M0 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Navid Mehregani
Not sure this is actually a problem: The design was that the user would normally be entering their own name for an artifact - the default of "Entity22" ro whatever is pretty meaningless, and is only there to prevent the model being created in error. Orignially the user was put directly into the case of editing the name in the text field on the diagram, but they need to use the refactor framework, so we updated to use the refactor dialog. The reason the Next and Finish buttons are greyed out is that the name has not been changed as far as refactor is concerned. So we have a choice: We can just create the artifact - and leave it up to the user to immediately refactor it. Or we *assume* they will want to refactor and pop-up this dialog. I chose the latter. This definitely feels like a bug from a user's perspective. The fact that we're using the refactor framework to name an artifact is an implementation detail. The user is (and should be) oblivious to that. Thus, from a user's perspective there is no logical reason why the next/finish buttons are disabled. Perhaps we can leave the name field empty when the refactor dialog pops up. This will force the user to specify a name before clicking on the finish button. Upon creation of the artifact on the diagram (having played with it a bit), the dialog does seem to pop up and get in the way. Ideally, the pop-up would only show up on a "true" refactor, not at creation. Is that feasible? The refactoring framework is there because TS uses FQN references rather than immutable IDs. From a user standpoint, creation of an artifact involves adding it on the diagram and then naming it. This should form the initial 'create transaction' and until it is complete there is no other diagram or artifact that could have a reference to it and so no need for the refactoring framework to 'kick in'. It does make creation seem clumsy - but is not a 'show stopper' issue. Created attachment 175723 [details]
Patch
This patch modifies the artifact directly when it's been created for the first time. For subsequent edits, it uses the refactoring framework.
Modified files:
AssociationClassClassNamePackageEditPart
AssociationNamePackagedEditPart
DatatypeArtifactNamePackageEditPart
DependencyNamePackageEditPart
EnumerationNamePackageEditPart
ExceptionArtifactNamePackageEditPart
ManagedEntityArtifactNamePackageEditPart
NamedQueryArtifactNamePackageEditPart
NotificationArtifactNamePackageEditPart
SessionfacadeArtifactNamePackageEditPart
UpdateProcedureArtifactNamePackageEditPart
Please review and commit.
Applied patch from Navid |