new toolbox plugin

[Hervé]

Hi Phil, JB,

Long time I haven't wrote on this forum Work has been very tough lately ...

Could you please create a new archi-contribs/toolbox-plugin on GitHub and give me access?

I need to implement new functionalities for my new company like the ability to make some concepts as read-only, forbid dupplicates, ... and this cannot be achieved using jArchi.

Thanks and regards
Herve

[Phil Beauvoir]

Hi Hervé,

good to see you on the forum!    But sorry to hear that work has been tough... 

I created the git repo for you. You should have a notification.

> I need to implement new functionalities for my new company like the ability to make some concepts as read-only, forbid dupplicates

I don't think that will be easy, as there are lots of places in the UI where you would need to trap this.

Cheers,

Phil

[Hervé]

Overriding the actions is quite easy using the Eclipse framework.

At the same time, I whish to print the read-only concepts in a different color in the model tree, and found that modifying the com.archimatetool.editor.views.tree.TreeModelViewer$ModelTreeViewerLabelProvider.getForground() method does the job.

Unfortunately, you're using a lot the "private" modifier and so far, I failed to override this method without overriding the com.archimatetool.editor.views.tree.TreeModelView and com.archimatetool.editor.views.tree.TreeModelViewer classes which is quite overkill and risky in case you change the code in those classes.

[Phil Beauvoir]

Unfortunately, you're using a lot the "private" modifier and so far, I failed to override this method without overriding the com.archimatetool.editor.views.tree.TreeModelView and com.archimatetool.editor.views.tree.TreeModelViewer classes which is quite overkill and risky in case you change the code in those classes.

Hi Hervé,

if something is private it usually means it's not API, so you'll see a lot of private stuff in the code. As you say, the risk is that much of the code can, and will, change.

I think what you will try to do will involve a lot of hacking, which is not ideal. The proper solution would be to have API extension points so one could extend, or add, label providers and so on. But things like the Models Tree was never planned to be extended in this way.

I don't know what the solution is.

Phil

[Hervé]

Hi Phil,

quite complicated indeed. I lost a lot of time to try to acheive my goal by overriding Archi classes, when it would be much easier to update Archi.

Would you consider a pull request that adds a "read-only" functionality to Archi concepts ?

Roughly, I'm planning to:

• Manage a "isReadOnly" feature (or property, not yet decided)
• Add isReadOnly(), setReadOnly(true/false) methods to the IArchimateConcept interface and ArchimateConcept class
• Add menu entries to set and unset the isReadOnly feature / property on Archimate concepts
• Update run() method from DeleteFromModelAction, DeleteAction, RenameAction, ... classes to check if at least one selected concept is read-only
• Update the getTextColor() of the TreeViewpointFilterProvider class to show the read-only concepts in blue

[Phil Beauvoir]

Hi Herve,

I'm not sure whether a "read-only" attribute should be implemented directly at the model level and may well apply to more than just concepts (folders, views, etc) and perhaps different contexts. Also, what is the granularity? Does it apply to modifying an object as well as deleting it? And how do you enforce it given all of the vectors available - various points in the UI, jArchi, coArchi, exchange format, model import, csv import, other plug-ins, etc? I'm not entirely sure what the direct and indirect impact of this might be.

This is not something I want to rush into, and not something planned in my own immediate roadmap, so I think for your use case you should implement it as a "feature".

Phil