Thursday, November 8, 2012

XAF has a great security system which can be used to protect our data either at client or server side. There is also great support for modifying the Security behavior at runtime using a permission matrix. However we need to provide initial before distributing our application. In this post we are going to discuss a way connecting methods that describe permission policies with our domain objects using metadata (Attributes).

For supplying initial data XAF provides a well documented approach through ModuleUpdaters. We can use them and write methods that create initial permissions. There are also many extension methods that can help us write faster code,

Full permission policy

This policy can be applied to any role and give full permission for the related objects. To connect a domain object with a method we need to do the following:

Define a FullPermissionAttribute as,

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]

publicclassFullPermissionAttribute : Attribute {

}

Decorate all related objects

[FullPermission]

publicclassMovieArtist : VideoRentalBaseObject {

[FullPermission]

publicclassArtist : VideoPerson {

With the use of XAF’s sub types info metadata API write an abstract algorithm that will enumerate all domain objects and assign full permission to them for a certain role

A common policy for an application is a “settings” policy. Which really means that for certain roles like the employee role there should be limited access to objects that store “settings” data. To implement this we can follow the follow steps

Define an attribute to decorate our objects as in previous step. This time we do not know the policy name (settings) so we design this as an Enum parameter in the ctor.

In this post we created reusable algorithms from any XAF projects to help us speeding up the configuration of the initial permissions. When of course talking about code reusability we talk about money saving!

P.S. In a real world application the above coding will be converted to a permission matrix UI representation like,

We would appreciate your feedback on this post. Has it been useful to you? Feel free to contact us with any further questions

Wednesday, November 7, 2012

DashboardView is a type of XAFView that is used to display several Views side-by-side. However XAF by default does not provide any connection between these Views. In this post, with the help of XAF model, we will discuss a few abstract connection mechanisms and possible uses of dashboards.

Cascading ListViews

In a dashboard, in order to connect the ListViews we need first to connect their models. This can be done using the following interfaces,

This design allows us to use Model Editor to connect our views. In the following image we see that the selected objects of the Customer_ListView_Calendar are going to filter the Calendar list view on the Receipt.Customer field.

Next we see this dashboard view in action, a SchedulerListEditor on the right is filtered by a GridListEditor,

Following we see this technic applied to 3 ListViews. The selected pie section of the left View filters the pivot which in its turn filters a LayoutListEditor!

Cascading views are as well useful for filtering reports, so by selecting objects on the left View we create a report on the right view and everything is inside a Tabbed MDI environment!

Of course we haven’ wrote the code yet but this is the easy part. XAF’s API is so rich and so well designed that is like we speak our native language! The great thing when XAFing is that our code is fully reusable from any project since it has no knowledge of our domain objects.

Let try to form our requirement in English first: For each ListView in a Dashboard we need to filter another View when the selection is changed

Cascading views are really powerful and soon we will have the need to hide an intermediate view in the chain but being able to filter other views upon it. Therefore we need to add a Visibility property in our model and handle it from our code.

publicinterfaceIModelDashboardViewItemEx : IModelDashboardViewItem {

[DefaultValue(ViewItemVisibility.Show)]

ViewItemVisibilityVisibility { get; set; }

and in a reusable from all projects controller implement the required logic.

A DashboardView does not have direct dependency with our domain objects. Therefore we can easily use it, even at runtime, to display static text view items and other controls (ControlDetailItem) or images (StaticImage).

XAF has great support for HTML Formatting so a Static Text like “<u><b>Hello</b></u>” will render the following:

Simulating View inheritance

XAF does not support View inheritance however we can extend our model and support it. Lets take the case that we have a very complex listview and we want to display it in both in MasterDetail and ListViewOnly modes without the need to support two View versions. For this we have to extend again the model, this time by a MasterDetailMode property and implement the logic in a ViewController.

Since XAF has a great modularization system the core classes/implementations of the above ideas are included in this zip file. However we will not update the contents of the zip file. For locating up to date versions each file in the zip has an OnlineRepoLocation attribute that points to eXpandFramework’s Github repository.

This post adds a few more tools in our development library that can leverage the XAF power using the Model. When we “model” there are three basic advantages:

We can use these model tools at runtime. For this XAF already provides a runtime time Model Editor.

We create robust unbreakable code and since we model instead of developing we mostly have no bugs only wrong configuration!

Implementations are reusable from all our projects!

Next post we will boost our R&D times even further and discuss a bit about Security system policies.

Tuesday, November 6, 2012

To improve development time and achieve better results we need to use frameworks like XAF. Moreover with XAF it’s really easy to create applications that are maintainable at runtime! After designing a domain model in VS we are almost ready to go. At this point, however we need a smart and flexible importing mechanism for feeding our domain models with initial data. Customers are impressed when they see real world data! So lets build together this mechanism proving once more the XAF power.

Requirements

Domain model agnostic.

This really means that our importing algorithms should depend only on object types. Therefore we can implement this as an attribute and decorate our domain objects.

For this we are going to create the an XPO dictionary on the fly. Querying our domain object attributes we can map this dictionary correctly.

Inheritance mapping configuration

Take as example an Artist, Customer both inheriting a Person object. The attribute should allow to map different the properties of Person when Artist and when Customer.

Examples

The following example imports all members that belong to MovieArtist from a table with same name columns (AllOwnMembers=true). In addition it maps the oid column in the table of the importing data store to the Oid property of VideoRentalBaseObject (BaseNMembers=”oid|Oid”). Finally it does lookup data in a data store in a table named vMovieArtist (Name=”vMovieArtist”).

The next one imports from a table named CompanyType only the column named Name (AllOwnMembers=false, BaseMembers=null, only Name property is decorated)

[InitialData()]

publicclassCompanyType : VideoRentalBaseObject {

[InitialData]

publicstringName {

get { return_name; }

set { SetPropertyValue("Name", ref_name, value); }

}

By default all object relations are auto imported unless the related object is not included in the configuration. Then only the key value is imported. It is also possible to control the mapping in many to many relations as

This is an initial data import mechanism. For such operations XAF provides the ModuleUpdater. We need the XafApplication’s IObjectSpace and one UnitOfWork that connects to an external data source so we can simply design an extension method like,

Using XAF’s rich reflection API we can enumerate all our domain objects, search for the InitialData attribute and create an XPO dictionary on the fly! This is rather easy as XPO follows a similar to .NET structure, so we have to create XPClassInfo for Classses and XPMemberInfo for members. A great sample exists in our code central so we can get a fast start with this API (E269). Following are the 2 main methods that implement the import mapping.

A complete and up to date version can be found in expandframework’s github repository.

In this post we improved the already rapid XAF development, by creating the import mechanism from almost any type of data into our domain model. In the next one we will visit another great tool offered by XAF the dashboard views.

We would appreciate your feedback on this post. Has it been useful to you? Feel free to contact us with any further questions.

Welcome to my Blog

My name is Apostolis Bekiaris and I am working for DevExpress as a technical evangelist for the frameworks team, .Net is my passion and at this blog you will find a lot of my work using DevExpress Xaf framework and many others. If you want to contact me you can use the link bellow