Creating associations between XPO data models in code using the XafTypesInfo API

Prerequisites:

See my About XAF Types Info Subsystem... blog post before reading.

What's New in this regard?

Just wanted to inform you guys that starting with v15.1.4, you can use the solution described in the eXpressApp Framework > Concepts > Business Model Design > Types Info Subsystem > Customize Business Object's Metadata > Create Associations in Code article for that purpose:

The following snippet illustrates how to declare an association between two class' properties when you have no access to these classes code and cannot apply the AssociationAttribute directly.

C#

ITypeInfo typeInfo1 = typesInfo.FindTypeInfo(typeof(DomainObject1)); ITypeInfo typeInfo2 = typesInfo.FindTypeInfo(typeof(DomainObject2)); IMemberInfo memberInfo1 = typeInfo1.FindMember("Object2"); IMemberInfo memberInfo2 = typeInfo2.FindMember("Object1s"); if(memberInfo1 == null) { memberInfo1 = typeInfo1.CreateMember("Object2",  typeof(DomainObject2) ); memberInfo1.AddAttribute( new DevExpress.Xpo.AssociationAttribute("A",  typeof(DomainObject2)), true ); } if(memberInfo2 == null) { memberInfo2 = typeInfo2.CreateMember("Object1s",  typeof(XPCollection<DomainObject1>) ); memberInfo2.AddAttribute( new DevExpress.Xpo.AssociationAttribute("A",  typeof(DomainObject1)), true ); memberInfo2.AddAttribute( new DevExpress.Xpo.AggregatedAttribute(), true ); } ((XafMemberInfo)memberInfo1).Refresh(); ((XafMemberInfo)memberInfo2).Refresh();

Question on the defaults when showing a DetailView from an external hyperlink in an XAF Web app - YOUR FEEDBACK IS NEEDED

If you use a solution from my recent Redirecting from an external hyperlink to a View in an XAF Web app with the ASP.NET Forms Authentication post, then you might notice that a DetailView is always being opened in readonly mode, even if the URL string might contain the mode=edit parameter in the end:

http://localhost:50292/Default.aspx#ShortcutViewID=Department_DetailView&ShortcutObjectKey=782f7cc7-123a-4145-be2d-5dd95f59f80f&ShortcutObjectClassName=MainDemo.Module.BusinessObjects.Department&Shortcutmode=Edit

This does not look logical to be honest, but this was and is the default behavior of XAF Web for more than 9 years already and it seems that nobody had problems with this minor inconsistency...

Until a few days ago...We had the first customer using this functionality and whose clients find it important for their business. So, I filled a ticket T259102 - Web - DetailView.ViewEditMode is not synchronized with the ViewShortcut's 'mode=edit' parameter in the XafApplication.ProcessShortcut method, which results in the read-only DetailView to be always opened from its URL, where we provided a possible solution for future XAF versions starting with v14.2.9 and v15.1.4.

Originally, we wanted to make this fix by default in the minor version, but decided to wait a bit, because a dozen of our functional tests, preserving the former behavior, failed. At first glance, it was nothing serious and the tests scripts can just be updated to reflect the new defaults, but we wanted to double-check with you guys whether changing these defaults ever matter to you and will not break anything. Hence, here is the poll for all concerned parties:

Poll question: How do you want this situation to be handled?

How to enable a right to left (RTL) layout in XAF WinForms and ASP.NET apps?

Starting with v15.1, certain WinForms controls support the right to left mode:
1. https://community.devexpress.com/blogs/thinking/archive/2015/05/20/what-39-s-right-is-right-and-what-39-s-left-is-left-coming-soon-in-v15-1.aspx
2. https://community.devexpress.com/blogs/thinking/archive/2015/06/23/winforms-right-to-left-support.aspx

An XAF WinForms application is a regular .NET WinForms app that uses DevExpress WinForms controls. Thus, RTL will automatically work for supported controls in XAF. To enable this mode in an XAF WinForms application, handle the XafApplication.CustomizeTemplate event in Program.xx (or override the corresponding virtual method in the WinApplication.xx file) and set the corresponding System.Windows.Forms.Form object properties. You can also additionally override the CreateModelEditorForm method.

Implementing cascading lookup editors with the @This parameter

It is quite common to filter one combo box data source based on the value selected in another drop down editor. For instance, imagine a Country/City scenario, demonstrated in our ASP.NET demos here (remember the amount of code lines for this demo). 

eXpressApp Framework (XAF) allows you to write less code for such common scenarios with the help of various data annotation attributes, configurable application UI metadata, built-in modules and their Controllers. Specially for this particular scenario in XAF we have the Current Object Parameter (@This) feature, which can be used in the criteria set for the lookup's data source via DataSourceCriteriaAttribute. For instance, if there is an Order class with the Product and Accessory reference properties, you can implement the latter property as shown below (just a single line) to have it filtered by the selected product (assuming that the Accessory class has a back reference to the Product class):

    [DataSourceCriteria("Product.Oid = '@This.Product.Oid'")]
    public Accessory Accessory { ... }

Here the '@This.Product.Oid' part refers to the properties of the Order object opened in the DetailView. So, this functionality is available only in the context of the View with an object in it and is technically provided through patching the criteria string and replacing the @This part with the actual value.

How to: Hide the 'Protected Content' Columns in List Views and Property Editors in Detail Views

I wanted to share a link to the new documentation article describing how to completely remove 'protected content' editors from the layout:

This approach is not new and is based on the ConditionalAppearance module, which is already used for similar tasks. So, you can use it in both v15.1 and earlier versions. Let me know in comments if this something you would like to implement in your app (we had more than a dozen similar requests from our customers in this regard).

How to assign a default security role to a new application user when Windows authentication is enabled

I want to talk about a typical scenario where AuthenticationActiveDirectory and SecurityStrategyComplex/SecurityComplex/SecuritySimple strategies are involved. Currently, when the AuthenticationActiveDirectory.CreateUserAutomatically option is set to True (the default value), a new Windows user opening such an application gets full administrative privileges.  While it can be good in certain scenarios, in others it is best to restrict this new user by assigning some limiting access permissions, e.g. to be able to view some records only.

There are several ways to accomplish this task in XAF:

1. You can create a user object manually and assign a custom role to it via the AuthenticationActiveDirectory.CustomCreateUser event. To subscribe to the CustomCreateUser event, run the Application Designer and focus the AuthenticationActiveDirectory component. Then, in the Properties window, switch to Events and double click CustomCreateUser in the property grid.

Redirecting from an external hyperlink to a View in an XAF Web app with the ASP.NET Forms Authentication - YOUR FEEDBACK IS NEEDED

I wanted to ask the XAF community members interested in this functionality to test a simpler solution to the problem described in this thread. Long story short, you have a hyperlink to an XAF Web application form like this: 

http://localhost:50292/Default.aspx#ShortcutViewID=Department_DetailView&ShortcutObjectKey=782f7cc7-123a-4145-be2d-5dd95f59f80f&ShortcutObjectClassName=MainDemo.Module.BusinessObjects.Department&Shortcutmode=View

and want to include it in an email and send it to a user so that he or she is able to navigate to that view on your web site (e.g., open a user profile or changed order details). If that app has a security system  with a logon form enabled, then the URL fragment after # is cut after a successful authentication, which makes navigation to the required app screen not possible by default. Instead, the URL fragment before the hash symbol is opened (see similar threads on StackOverFlow for more details: one, two, three).

There was a tricky solution to work around the default ASP.NET request processing mechanism in the original Support Center thread, but today I wanted to share a simpler solution for our users.

Here it comes:

1. In the Solution Explorer, right-click the YourSolutionName.Web/Login.aspx file and invoke the View Markup command from the context menu.

2. Paste the <script/> element with the JavaScript code below before the </body> element, as follows: