You will want to allow and disallow user groups to execute actions.

This could be done as enable expressions on the Actions – but that would not be very nice since it would kidnap the use of enable from the normal things we use enable for (check data state). Also if a user is never allowed to execute “TheAdminInterface” it might be best to hide that action from view all together.

To facilitate this Modlr has a new concept called AccessGroups:

Clicking up the AccessGroup dialog shows you this:

Here you can add groups and define the EnableExpression and VisibleExpression for the AccessGroups.

An AccessGroup the contain actions and you can add and remove the association here.

If an action is a member of multiple AccessGroups the result will be : (Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnable

And for visible the result is (Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext

The main problem with deletion is the what business rules that deletion should adhere to. The technical rules the deletion adheres to are covered by aggregation and the deleteaction as described earlier here.

We have now also added the IBusinessDeleteService that works like this; on every associationend you can set one of four values: NotDecided, MustBeEmpty, NeedNotBeEmptyButWarn, NeedNotBeEmptyNoWarning. The default value is NotDecided.

Now – what you should do with this meta information is up to you. You are free to implement your own flavor of the IBusinessDeleteService or you can just implement the IBusinessDeleteService.OnInformTheUser event  on the standard implementation.

WECPOF implements this event and shows a dialog to the user.

When you have the BusinessDeleteRule set to NeedNotBeEmptyButWarn you will get messages like these:

If you have BusinessDeleteRule set to NotDecided you get a message like this:

If you have the BusinessDeleteRule set to MustBeEmpty you get this:

Delete constraints

Further more you may have explicit business rules that controls if it is ok to delete an object or not – you can now handle these as normal class constraints. Constraints has been extended with an attribute IsDeleteConstraint – if this is set the default implementation of the IBusinessDeleteService will call the OnInformUser event with the message constraint as a parameter. WECPOF uses this to show a dialog to the user and stopping the delete until the constraint-break is fixed.

This new service helps you to feel in control and good about deletion. It will not automatically solve all your delete issues – but we believe that it will enable you to easily solve them all as they are needed. Agile so to speak.

As you do you might want to pick up information stored in the TaggedValues of the model.

You can do that like this:

G.allinstances->first.oclType.TaggedValue(‘Eco.PresentationUnit’)

But this approach will not let you get to TaggedValues on features like attributes or association ends.

For this purpose we added TaggedValueOnFeature. Use it like this:

G.allinstances->first.oclType.TaggedValueOnFeature(‘Eco.PresentationUnit’,'SomeAttribute’)

The desired effect is to get loading, saving and any other potentially time consuming logic to run in the non-UI-thread, also called the AsyncThread, and to keep the UI-thread free from EVERYTHING except responding to UI events – like user input or view redraw refresh.

The goal of this separation is to get an application as responsive as possible for the user.

There are other scenarios when you want to use multiple threads with ECO. But the scenario that the IAsyncSupportService solves is the one of “creating responsive applications”.

WECPOF use IAsyncSupportService internally – so when using WECPOF you need not think a lot about the workings of the IAsyncSupportService.

When you do not use WECPOF you should follow these rules:

1. Do all your business logic in the async thread (all persistence server communication will be in this thread)
2. If you address UI components directly like bring up windows, change the value of a textbox by addressing the textbox directly rather than by databind, compile reports etc – when you do these kind of things – always use the UI-thread.

So – simple enough rules –  but how do you follow them?

This is one way to make logic execute in the Async thread

       IAsyncSupportService asyn=_RootHandle.EcoSpace.GetEcoService<IAsyncSupportService>();
       asyn.PerformTaskNowIfInAsyncThread(() =>
       {

         // Things here will always be done in the async thread

       }

    But is not uncommon that you want to do business logic, then update the textbox or what have you:

       IAsyncSupportService asyn=_RootHandle.EcoSpace.GetEcoService<IAsyncSupportService>();
       asyn.PerformTaskAsync(() =>
       {

         // Things here will always be done in the async thread

         asyn.DispatchTaskToMainThread(() =>
         {
            // Things here will always be done in the UI/Main thread

         });

       }

If you code like this whenever you invoke business logic from the UI-thread (like when you click a button or menu) then your app will be responsive and never lock up – even if there is a network delay for loading a lot of data.

If you turn the IAsyncSupportService off – then the PerformTaskAsync and the DispatchTaskToMainThread will fall thru directly and execute directly  – so code written like this will work either way – IAsyncSupportService on or off.

Turning it on or off:

public interface IAsyncSupportService
{
    /// <summary>
    /// For Silverlight with Persistence AsyncService MUST BE ON
    /// We recommend leaving it on for other NEW WPF and WinForms applications - and executing business logic in AsyncTasks.
    /// For ASP.NET the AsyncHandling should be turned off (default off).
    /// </summary>
    void TurnOnAsyncHandling();
    /// <summary>
    /// We recommend leaving it on for other NEW WPF and WinForms applications - and executing business logic in AsyncTasks.
    /// For ASP.NET the AsyncHandling should be turned off.
    /// </summary>
    void TurnOffAsyncHandling();
   …

Staying informed

When you have an application that does a lot of stuff in the async thread – it is nice and good style to indicate that work is going on to the user – because even if the app never locks up – the UI might still be needing more data – data that will show up once all the work is done if the user can be bothered to wait for it.

The IAsyncServiceHelper expose some events for this purpose. Use these to show an animation or what you need. WECPOF use these to light up a “loading” animation, and an “Error” icon when appropriate.

/// <summary>
/// Implement this event to inform yourself about exceptions in the AsyncThread
/// </summary>
event EventHandler AsyncExceptionsEvent;
/// <summary>
/// Implement this event to Start a busy animation
/// </summary>
event EventHandler AsyncQueueHasFormedEvent;
/// <summary>
/// Implement this event to Stop a busy animation
/// </summary>
event EventHandler AsyncQueueDissolvedEvent;
/// <summary>
/// Implement this event to tick a progress indicator
/// </summary>
event EventHandler AsyncQueueTickEvent;

The reason for the two different properties are that the ActionName is important to modlr itself – it is used for presentation of the action and as reference name of the action. The presentation is however the text we use when presenting the action in a contextmenu or in the WECPOF leftside action column.

Since the Presentation often resembles the Name we have introduced the following shorthand/activecontent:

The context object is of course the object that the actions is acting on. So it is intended to be used with “Class actions”.

Constraints descriptions

As we introduced the above mentioned shorthand we also made the <AsString:attributeX> part available in the constraints Description texts. This way your constraints descriptions can get context info. If you have the need for a complex expression, like navigation for pulling attributes from neighbor classes you are advised to create the expression as a derived attribute that you then can reference from your constraint description text.

So suppose you find some data somewhere.

And you have model that should hold it:

And that you can create a view model that explains how to receive the data

Now click up the system prototyper:

Start the system and click up the debugger:

Switch to the “Import tab separated” tab, enter the ViewModel that you want to control the import, press “Get headers from viewmodel” to the names in columns – in this case Code and Name:

Paste in your tab separated data and press GO:

Now you have created objects – switch to the “Dirty Objects” to save them…

The “UseKey” flag

The UseKey instructs the logic to pick the first column, and try to look up this value with <ClassFromViewModel>.allinstances->select(keyname=’valueinfirstcolumn’). If an object is returned it will be used for update – if none is returned a new will be created. This will give one such evaluation per imported row.

Setting links

Often you will want to assign a link when importing your data. This is done by designing a ViewModel that has PickLists. This is powerful since the lookup will be made on the result of the expression of the Associated viewModel Class. The lookup will be done in memory in dictionaries and will be very fast.

Creating link objects

Link objects can be created the same way. You will need to provide the two keys needed for the association in the first 2 columns.

This is good for things you always want to show or as a scratchpad where you can drag objects (see article about DragDropActions).

The second special name is “DefaultBackgroundViewModel” and that viewmodel is added here:

And this will show whenever you do not have any tabs open. This is good for information you want to present to the user when they start the application. Like maybe you want an easy navigation screen, or a message from SysAdmin about something, or a list of things with broken constraints.

We made an effort to solve this issue in a generic way. We call the solution GridAction.

Example

Given this model

And this view model

You can get this WECPOF UI

Now we can very well require that the user first press the action “Create Class1” and then navigate to the new row and enters Attribut1.

But by adding an Action to the Nesting in Viewmodel that the Grid displays we get another way of doing it – the GridAction way:

By doing this – WECPOF adds a null row at the bottom of the lines in our grid:

The null row has the Action name on it – written in italic to separate it from normal rows (representing Class1 objects in this case).

User can write into the GridActionRow, and when user press enter or otherwise submit the edit this will happen:

1. A ViewModel context variable called vGridActionArgument will be assigned the text you wrote

2. The action will execute

So consider this implementation of the GridAction_NewClass1 action:

let x=Class1.Create in
(
  x.Attribute1:=vGridActionArgument
)

This will create a new Class1 object and assign the Attribute1 to the value entered in the GridActionRow:

The user experience is a lot better!

In the Class2 grid – that in this ViewModelView is a detail of the Class1 master – the GridAction expression looks like this:

let x=Class2.Create in
(
  x.Name:=vGridActionArgument;
  x.Class1:=vCurrent_AllInstances
)

So it both gets the new name and assigns to the correct Class1 owner – and the user just typed the name in the last row and pressed enter.

Further more…

If you make use of multi variable seekers – it is desirable to let the GridActionArgument in some grid act as the search expression.

So if you have a UI that enables you to add tenants to houses:

You want to user to be able to search and add in one blow – add a GridAction that is defined as this:

And the Search UI:

Now – when the user types and press enter this will happen:

1. vGridActionArgument gets the typed value

2. The action is executed

3. The action is defined to bring up the Seeker for Person

4. The vSeekParam that is used as filter will be set by the actions OnShow expression

5. WECPOF MAGIC will detect that this is a seeker and press enter – thus starting the search

6. If the result of the search is 1 exactly 1 then WECPOF MAGIC will recognize this as a good result and execute the After Modal Ok expression and thus closing the search UI and also assigning the tenant.

7. If the search result was different than 1 (zero or many but not 1) the search UI will stay open – so that the user can find some other criteria

Search result:

So the result was 2 rows – the search stays open…

Only 1 hit so everything is done for me:

The used search expression is deduced from the rules explained here: http://www.new.capableobjects.com/2011/02/27/the-multi-variable-seeker/

But having that is all fine – we need a way to tell the user what to expect from the search – ie it is often so that one search expression is associated with a specific column in search result and users have indicated that it is important to understand what the search logic has done.

So we added a tagged value on the SearchExpressions:  Eco.HiliteGridColumn , and you are supposed to set this to the value NameOfViewModelClassThatIsTheSearchResult.NameOfTheColumnToHiliteWhenThisParticularSearchExpressionIsInEffect.

If you do it may look like this:

SearchExpression TaggedValue Eco.HiliteGridColumn=SearchResultGrid.Efternamn

SearchExpression2 TaggedValue Eco.HiliteGridColumn=SearchResultGrid.Förnamn

And when you search in WECPOF:

And another click (that moves the search to the other expression):

The BoringPredictableServer has a declarative way to explain what you export and import at the modeling level so that you always are fully documented and never lose grip of what you have.

This solution – as so many others we have in borpred – make use of the ViewModels. Since the ViewModel constitutes a declarative way to transform your model it is very well suited for the job to explain the transformations from your model to a export file, and from an import file to your model.

Excel

Excel is a well known and easy to work with – so we assume your files will be in or transformable to Excel.

An Example

Defining a model to hold some data and a ViewModel that use some of that data.

I also define a small UI-ViewModel so that we enter some test data:

I tell BorPred to execute this model in slot A0:

I start WECPOF to enter some data:

I Visit the BorPredServer:

I export allinstances of the specific class in the specific format defined by the viewmodel:

I get the result as an open document spreadsheet:

I change the data a little:

I save this as Text – tab-separated , an then go back to borpredserver:

I point out the ViewModel to use when importing and also the file to use:

I then hit Refresh in the WECPOF app to view the imported data:

If I would like to update existing objects instead of creating new ones I need to supply the attribute we will use as key and make sure that this is the first column in the import file. Like this:

The excel import and export can be accessed as webservices thru the borpredserver:

Summary

So this was another little boring and predictable function that we added to BorPred.  You should switch your EcoPersistenceServer to BorPred now – you might not jump with joy because of the switch but you remove a lot of boring and predictable tasks that you would otherwise need to spend time on.