Introducing MDriven TaJson

I know – we have grown accustomed to things being REALLY complicated when it comes to software development.

But what if everything was easy? How would it be then? Would we get time over and invest that time into building complicated things? Probably. So there might be no Nirvana were our brains are not needed any more – but that does not mean that we should abuse ourselves by doing common simple things in complicated ways.

This is why we constructed MDriven TaJson.

The common current consensus to communicate data between systems is Json.

When receiving data in Json format we often need to merge this data with data we already have – this entails discovering if an item has been added to a link or removed from a link.

Why is this still hard 2019? Well it is not – or maybe just because you do not use MDriven TaJson – yet.

MDriven TaJson is 3 new Ocl/Action-operators:

• self.AsTaJson( viewmodel , skipempties) – will give you the json based on the self and viewmodel
• self.ApplyTaJson( viewmodel , jsonstring) – will update self through the lens of the viewmodel with the matching data from the jsonstring. Will update relations and add and remove objects in links.
• self.MergeTaJson( viewmodel , jsonstring) – same as ApplyTaJson but will not remove objects of multilinks in target – only add new if needed.

Starting with the simple task to turn your objects into json. I will use the default model in MDriven designer – and the MDriven designer debugger.

Follow this link For more on the debugger.

In the debugger we have the tab taJson workbench – create some Thing-objects, and select them:

Switch to taJson workbench and pick a root object and a viewmodel:

Using the AsTaJson button I get some JSon that follows the ViewModel “ViewOneThing” – this actual expression executed to give this result is self.asTaJson(Thing.Viewmodels.ViewOneThing,false)

In the debugger I switch to the Viewmodel tab and update the data so that we can see with more details:

Then as TaJson again:

I will copy this output Json to a notepad – then change it a bit and paste it back into taJson Workbench.

Execute ApplyTaJson and switch to the ViewModel-view again and verifying the new data on root level:

Notice that the ComboBox single link updated to another valid value – it changed the reference and did not change the value of the old picked object as one naïve implementation could have been:

What happens if we set a non existing value in the single link? Lets try 8:

ApplyTaJson

No – change! Since the logic could not find a valid value – it skipped it. If it the value is not in the combo – it is not accepted.

Lets try adding rows to the multi link:

Trying Remove from multi link:

And this is were we can see the difference between merge (that never removes) and apply that does delete:

In the above image we see that in data is only 2 rows – but merge was used and the result data now has 3 rows since the row missing from indata was not removed.

TaJson ALWAYS USE THE FIRST ATTRIBUTE (in the viewmodel nesting) AS THE KEY for identifying rows – in the example above that is Attribute1.

Exceptions to the Rule

We have added some ability to tweak the TaJson functionality so that it will better adapt to odd cases:

• Action [ViewModelColumn]_AddNew will be used to create new objects needed for viewmodel-association with name ViewModelColumn. Action must return created object – if action is not found we will look at type info and create object
• Variable vImportKey:string if found will be updated prior to creating a object – can be used in the _AddNew action to look up existing object
• Action Delete in nesting will be used if found when we need to delete object due to missing in input and merge mode is not in effect – use this if you do not want to delete and instead want to unlink
• Action CleanUpAction if found on root ViewModelClass will be called after the import is finished

What is in a name?

Why is this logic named TaJson? Because it sounds like (Mike) Tyson – and it will knock you out in its simplicity and awesomeness. Also, the fact that in the C# code for the MDriven Framework, we call it JsonHierarchyImportExport – and that is too long, too uncool, and a bit boring.

Fun fact: We first developed this logic to allow for textual change of model information. This is found in the MDriven Designer: