Feature request : add metadata information in all components

[Hervé]

Hi Phil,
Hi JB,

At the moment, my database plugin is changing the internal objects ID to store inormation required by my plugin.

This is a bad behaviour ...

I do not want to store them in properties as they would visible (and updatable) by the users and was rather thinking about adding metadatas to some of your classes (elements, relationships, diagrams, connections, etc ...) ?

All the objects would then present the following two methods (the same than the "model" class) :
     IMetadata getMetadata();
     void setMetadata(IMetadata value);

What do you think about my request ?

Thanks and regards
Hervé

[Jean-Baptiste Sarrodie]

Hi Hervé,

My personnal feeling is that this should not be needed and that there's certainly another/better way to do it...

Could you elaborate a bit more about your needs so that we coud help you find other options?

BTW If you work near Paris we could meet someday to discuss about Archi ;-)

Regards,

JB

[Hervé]

Hi JB,

I live and work south of Paris (close to Evry) and would be very interested to meet you :-) I can even send you my mobile phone number in a private message.

My request is related to the new collaborative plugin I'm thinking of ...

There are always other ways to do things but I was thinking about adding new properties in your class because the information would be serialised in the archimate files. This way if someone copy the Archimate file to someone else, the information would be kept. And your existing software do not use these properties, then I was expecting the impact to be as less as possible.

Here is some more technical details about what I'm working on :

My postulates :

• An Archi model is a "self sufficient" container
• This means that, at all times, it contains all the elements and relationships and their graphical representations
• This means as well that one person cannot work on a part of it, but only on the whole model
• In conclusion, there is no way for several people to work on the same model at the same time

[li]
[/li][/list]

The sparkling : ==> uncorrelate models from their content <==

All the elements and relationships will be stored in the database, outside any model structure, without any graphical representation. They will live their own life :
   - They will have an owner
   - They will have access rights (at least basic ones)
   - They will have an expiration date
   - They will have a creation date
   - The updates will be tracked with version numbers, modification dates, modification purpose, etc ...

Then, and only then, come the model. The model will only be used to organise views : one will be able to import any version of any component in any model

What that implies by design :

• When you import an element (without specifying any version), then the latest version will be imported.
• If you open again your model few days later, if the component has been modified (by anybody, in any other model, ...) then these modifications will be visible in your model as the latest version would always be imported
• On the opposite, you will be able to specify a specific version of a component, meaning that whatever modifications are done to it, they will be ignored as the same version of the component will always be imported
• It also mean that you would not be able to modify the component in your model because modifying it would mean create a new version and this new version would not be the one you represent in your model

My apologies, this becomes clearer and clearer every day in my head, but it is not really easy to summarise it in a post.

Nevertheless, I need to store new information related to the components :
   - are they new ones ? thus they need to be created in the database
   - are they a new version of existing ones ? thus I just need to create a new version in the database
   - has the latest version of the component been imported or was it a specific version (a point in time) ?
   - should I allow it modification or not (is it read-only or read-write) ?
   - is the component flagged as read-only in the database anyway ?
   - what is its actual version ?
   - has it been updated since its last import ? i.e. do I need to export it or may I bypass it (in order to accelerate the export process, I will only export the modified components)
   - and so on ...


To achieve this, I need some temporary information but I also need some permanent information (the version number, the access rights, ...) and was thinking to store them inside the component objects themselves.


I've learnt how to overwrite your factories so I believe I should be able to extend your classes (to add my own methods) and to add my own callbacks to do some testing on component updates.

But (their's always a but) my classes would not be the one you serialise. Thus someone who save its model in an Archimate file and close Archi would loose all the information my plugin needs. If they open back the model from the Archimate file and try to export it back to the database, they will have a lot of error messages because of the missing information.



That's the reason why I was thinking of having a metadata property in your original classes that would be serialised in the Archimate file.

Quod Erat Demonstrandum   


Sorry for being prolix, but you shouldn't have asked

I'm looking forward to talk (verbally) with you on this subject.

Best regards
Hervé


ps: by the way, please be aware that my ultimate goal is to be able to, one day, transform this collaborative and database stuff into a real-time collaborative plugin meaning if someone modifies a component in its model, then your own model would be updated in real-time. I was even thinking on a color code or may be drawing a lock on components that are being modified by other people. I do not know if I will be able to do it, but I'm quite an optimistic person 

[Phil Beauvoir]

Hi,

I would prefer not to make big changes at this late stage of beta of Archi 4.

I wonder if you could use the existing single Metadata by using object IDs as a prefix key string?

Phil

[Hervé]

Hi Phil,

Thanks for your answer. Yes, this is an option.

Best regards
Hervé