Sunday, May 30, 2010

What an Action can do

Actions can only do a couple of things.



The execute expression is an Eco-Action-Language expression that is rooted in some context.

For GlobalActions this context is null, so what you can do is limited to expressions that stem from a class of your model, like X.allinstances or X.Create. The EAL-editor is displayed by the button next to the expression:


If the Action is a ContextAction, you get access to the variables that the context define, these are named as vCurrent_TheViewModelClassName. So you can either act on classes as with GlobalActions or act on the current value of variables from the context. The variables follow the selections that the users do in ViewModel grids, so you can act on things the user has selected.

When you have an object context like this you can call methods that the objects class define:


And you can of course use all the attributes and navigate all the associations in as many steps as you need to get the desired effect.

If the action is a ClassAction the action is rooted in an object of that class, and you use the OCL identifier “self” to operate on this.


The EnableExpression is very similar to the ExecuteExpression, except it is not an EAL expression, it is an OCL Expression. As such it cannot have side effects (it cannot change anything in your domain of objects). And the EnableExpression must also evaluate to a boolean value of true or false.


Except from these differences the expression operate on the same context and can reach the same variables etc as described for the ExecuteExpression.

The EnableExpression is used to control when an action should be executable or not.

Consider that you have a state machine on the class X and you only want the Delete action to be enabled when X is in state Deletable : self.oclIsInState(#Deletable)

BringUpViewModel & ViewModelRootObjectExpression


An action can bring up a ViewModel defined UI, and when it does it will assign the Root object of the viewmodel the result of the ViewModelRootObjectExpression. If the ViewModel RootObject Expression is empty the Root object of the brought up ViewModel defined UI will be unassigned – and this might be perfectly fine for certain types of UI’s, like UI’s designed to seek persistent storage for example.

ViewModelIsModal & ExpressionAfterModalOk


If the action is set to bring up a ViewModel powered UI, you may also choose to bring that UI up as a Modal window (a dialog you need to Ok or Cancel to get away from). The WECPOF runtime will add an OK and Cancel button to the bottom of your window if this is set.

If the user clicks Cancel in such a window nothing else happens besides the fact that window is closed. But if the user clicks Ok the WECPOF runtime will execute the ExpressionAfterModalOk if you have defined it.

The ExpressionAfterModalOk is an EAL expression that works on the context exactly like the ExecuteExpression does, but the ExpressionAfterModalOk also bring the variables from the ViewModel UI that was modal and is now closing. This fact enables you to read values of the window about to close and to apply these values to your current context.

The variables taken from the window that is closing are prefixed with “vModalResult_” in order to avoid name collisions with the calling context.


This will enable you to create a Seek/Pick/Assign pattern in a WECPOF application.

Consider that you have a Car-rental-model, you a have a ViewModel that shows the rental contract and you now need to assign a Car to the Contract. The choice to use a ComboBox to scroll and find a car is no good because the number of possible Cars are 500+. So instead you add a ContextAction to the Rental contract ViewModel that brings up the Free-Car-Seeker-ViewModel, and you tick the ViewModelIsModal checkbox.

You also define the ExpressionAfterModalOk to be vCurrent_RentalContract.AssignedCar:=vModalResult_Current_PickedCar.

Framework Action

If you pick a framework action none of the other expressions will apply.


The Framework action is added to allow access to functions that operate on a different level then your model.

Save – saves the changed (created, deleted, updated) objects using the persistence mapper that you have used in your EcoSpace (Or in Gaffr).

Refresh – calls Refresh on your Persistence mapper if it supports Refresh (set up sync server to allow)

Undo/Redo – calls undo or redo on your ecospace. The current  WECPOF runtime uses a timer to create new undoblocks every other second if there are new changes.

Exit – quits the WECPOF application

Defining Main menu actions

Main menu actions are called GlobalActions.  We start by bringing up the Actions definition window:



We add some GlobalActions and give them names based on what we want them to do in the end:


If I run this as is in WECPOF I get this main menu:


But we want to organize the menu, so we create some Menu-Groups:



Now I can decide in what group my actions should be:

Declarative actions in a model driven environment


and then I get this result when running WECPOF:


To get the internal order and dividers into the menu I need to set Divider group for the items, if this differs between two actions they will be separated by a divider. If it is the same between two actions the actions will be sorted on the “Sort order in Group” value within the group.


This is what I get in WECPOF now:


If I want to organize the actions in sub menus I do this by declaring a new Menu group:


And I use that group on the actions I want in the submenu:


The strategy for creating context menus is exactly the same.

Context menus show up in Grid components, and in the header of WECPOF windows:


Monday, May 24, 2010

WECPOF, the icing on the Model Driven cake

I have been working hard for getting the WECPOF beta out so that you can start to give us your feedback.


Given any valid model WECPOF will allow for you to define declarative ViewModels for showing the information:


…and also declare declarative ViewModels to define search-UI and retrieve objects from persistent storage:


… this paired with the new way to define declarative Actions that can wake up a ViewModel powered UI:


… and the new way to view the executing model from within Visual studio or


… like this:


…will give you the WECPOF-runtime-window:


… and this is actually a fully functional WPF application with separate styling:


WECPOF comes as a separate distributable assembly so that you can deploy systems with it.

What is left on WECPOF?
- Reports
- Style as expression (let xaml style change based on an OCL expression – like in negative numbers should be red)

So what is the verdict from you? Comments please. Let me know if you need a beta – I would very much accept style files (xaml resource dictionaries) that we can use as what can be done with WECPOF.

Sunday, May 9, 2010

WECPOF – getting to the bottom of the Line of Business Application

Our research yields these results:

1. Applications have three kinds of forms

The seek form that from nothing can search objects in persistent storage and show them in a list

The document form that is designed for a specific use case and shows information based on a root object and its associations, in as many navigational steps as necessary

The Report form that differs from the document form by being non interactive, paginated and by expanding all combinations in master detail relationships at once (non cursored)

2. The seek form can be used in two different modes

The first mode is typically reached from the main menu as in a context-less seek operation restricted by any number of filtering parameters

The second mode we call “Seek and pick” and is a modal form that aims to seek out one or several objects for a specific reason; such as assignment to some association. The “Seek and pick” is commonly used to set a 0..1 association end when a combo box would not suffice due to too large data quantity

3. Applications has three kinds of actions

Actions that act on an object based on its class

Actions that act in a given context or use case; a document or seeker form

Actions that are global and acts on neither of the above context’s, like main menu actions

4. Actions can be organized in structures; like sub menus

5. Any action can either be enabled or disabled based on state from the context

6. When an action is executed to following things can happen

Some code is executed

A Form may be opened

The opened form gets assigned an optional root object by execution of some code

The opened form can be opened Modal or not and if Modal an optional piece of code will be executed when the Modal form closes with OK (like with seek and pick)

7. Forms have UI-Validations to communicate rule breaks in the current input

8. Objects follow business rules by implementing state machines with guards

This is what we want to offer with the WECPOF prototyping framework. Following this simple manifesto we will reach far in our quest for the fully declarative application.

Contact Us | Terms of Use | Privacy Statement © 2009 CapableObjects