Before you go berserk and scream at the top of your voice : “STYLING IS A UI THING AND SHOULD NOT GO INTO THE MODEL SINCE IT WILL BREAK THE PRINCIPLE OF VIEW/MODEL SEPARATION ” – before you do that I would like to calmly state that a lot of the time we use styling like color and fonts to convey model based information.
Hmm – got you thinking?
There are two different parts to styling: theme and communication-by-style.
Theme should not go into the model since it will break the View/Model separation.
Communication-by-style; like “Look at me I am all red because you need to fix something”, and “let me bring your attention to this part of the screen that turned all yellow just now”, and “there is a clear divider between numbers on this row and on the other row to make it clear that they mean very different things” – this kind of communication MUST really go into the model with all the other information we use to build a software system.
In MDriven we have had a lot of different technologies (modernity as we call it) over the years. Currently the actively maintained are Windows Presentation Foundation and other Xaml approaches – and HTML5 approaches.
When we introduce Styles in the model – these styles must work (do their thing) in both Xaml and Html clients. And it must be likely that they can work in future implementations of modernity that will surely come.
The inspiration on what should be possible to style is taken from Office apps like Word and Excel – color the background, set a border, change a text font and style.
Word is what it is and styles cannot really change based on rules – but in excel you have conditional styles – that turn on and off depending on data – and that is the functionality we want as well!
Nothing of this is new to MDriven really – you could and can add your own styles in either external CSS or external XAML resource dictionaries – but that is not ideal and a bit complicated. We want to make stuff easy!
The Schematics of a UI-widget is something like this:
We will want to target the parts individually in order or to not limit your possibilities.
We also have Grid/Table and they have different schematics:
What we did
In the ViewModelEditor we added a “SIM”-button, SIM stands for Styles-In-Model:
The SIM-button brings up this new dialog that will hold all the styles you have defined in the model:
Once we have defined the style we can make use of it :
After the ViewModelEditor is opened and closed we will even see the style in the preview.
When we run the WPF prototyper we will see the style:
And in turnkey-core or on deployed turnkey-app we will also see the style:
Now we see that there are subtle differences – in WPF we apparently treat the ComponentContent as transparent and in web it is the color white. If we think this is an issue we can easily now set the CompoentContent-target to a specific color instead of leaving it blank:
Let us true a Blueish color:
In WPF we get this:
And in html:
What was hard is now easy
To color a specific cell in a data grid depending on some rule used to be really hard. In WPF we needed Styles with DataTriggers for example.
But now it is easy to style YourCell by just adding an addtional column YourCell_Style – have that additional column return a name from your Styles-In-Model and you are done:
And we get this:
And for WPF:
What you need to do
In WPF you must merge the Generated Xaml style dictionary to your other styles:
if (stylesinmodelRD != null)
_rememberoldstylesinmodelRD = stylesinmodelRD;
In HTML you will find the generated css under this name:
For a turnkey application like this: https://hkscratch.azurewebsites.net/Turnkey/StylesInModelCss
2 thoughts on “Introducing Styles In Model”
Note: When using more than one included EcoPackage in an EcoSpace for a WPF application it seems GenerateResourceDictionaryFromStylesInModel only generates styles from whichever EcoPackage is listed first in the EcoSpace.Designer.cs file. Subsequent package styles are not included.