Apologies for the immediate followup, but two more quick things: - I've committed a first cut of the proposed org.argouml.notation.NotationSettings for those who want something concrete to look at.
- There's clearly a lot of overlap with things which are currently included in DiagramSettings. The plan would be to refactor that class to remove all notation related settings and have them stored exclusively in NotationSettings. I've included a quick summary below. Move to NotationSettings ------------------------------------ ? notationLanguage : String ? showAssociationNames : Boolean showInitialValue : Boolean showMultiplicity : Boolean showProperties : Boolean showSingularMultiplicities : Boolean showStereotypes : Boolean showTypes : Boolean showVisibility : Boolean useGuillemets : Boolean Stay in DiagramSettings ----------------------------------- defaultShadowWidth : Integer defaultStereotypeView : StereotypeStyle fontBold : Font fontBoldItalic : Font fontItalic : Font fontName : String fontPlain : Font fontSize : Integer ? notationLanguage : String ? showBidirectionalArrows : Boolean showBoldNames : Boolean [ we're obviously missing things like line colors & widths, fill colors, etc, but these aren't customizable in ArgoUML currently] Tom On Tue, Dec 16, 2008 at 3:13 PM, Tom Morris <[email protected]> wrote: > > Michiel and I disagree over the design of the data structure to hold settings > which control the generation of text in the notation subsystem and he > considers this an "architecture level" decision, so asked that it be opened > to general discussion. Examples of the types of settings are things like > whether to use <<angle brackets>> or «guillemots» for stereotypes, whether > 1..1 multiplicities should be displayed as "1" or blank, etc. > > The current design uses a raw HashMap<String, Object> to hold these settings > with the String keys being free form text. To change a setting, the caller > uses something like > > getNotationArguments().put("visibilityVisible", Boolean.TRUE) > > and then all the current arguments are passed to the text formatter in the > notation subsystem by something like > > notationProvider.toString(modelElement, modelElement.getNotationArguments()) > > where the formatter will check for the an entry with the key > "visibilityVisible" if it uses that in its formatting decisions. > > I propose storing all notation settings in an explicitly designed > NotationSettings value object with setters/getters for each setting. The > example above would look like: > > getNotationSettings().setShowVisibility(true); > > and then the formatter would use > > notationSettings.isShowVisibility() > > to check the specific settings that it is interested in. > > The problems that I see with the current design include: > > - it's opaque - there's no way to tell who is using what settings without > searching for magic strings in the source code > - it's not opaque - the implementation type of the setting storage (i.e Map) > is exposed through the API > - it's big - hundreds of bytes vs dozens of bytes (ie 10X worse space > performance) for *every* Fig in the project > concretely 224 bytes vs 24 bytes for four settings entries on a 32-bit > machine > - it's slow - keys have to be hashed and then searched for > - it's error prone - since the keys are typed free form by hand every time, > any typo will cause things to stop working > > There's a general discussion of why our existing design isn't a good idea on > the SAP blog and I agree with everything they've written. > https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/5163 > > My proposal will be smaller, faster because each setting is directly indexed > as a field in the object, less error prone because the compiler will check > all names, more transparent because we'll be able to easily tell which > settings are used where. For cases where extensibility is needed, > NotationSettings can be subclassed and extended with additional > setters/getters, so we don't lose the extensibility aspects of the current > design. > > I am strongly in favor of changing the design, but I wanted to give others > the opportunity to defend the current design if they think it is a better fit > for the requirements of the task. > > Discuss! > > Tom ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985214 To unsubscribe from this discussion, e-mail: [[email protected]].
