DevExpress XAF is a framework for .NET and Visual Studio developers who wants to create Office-like LOB apps for desktop, web and mobile faster and without hiring a large team.
Based on the number of occurrences in the Support Center I feel that not many of you know that with XAF it is possible to invoke a dialog window from a business object context and do so without using any controllers or methods of the XafApplication class (these solutions are based on configuring the ShowViewParameters object or a ViewShortcut).
The solution I would like to tell you is to create a method marked with the ActionAttribute and accept a non-persistent object as a parameter. XAF will recognize such a method and generate a PopupWindowShowAction for it in the UI.
When you execute this command, XAF will show a DetailView of a specified non-persistent object. Since XAF generates Views based on your data model, your can code your non-persistent object to contain required input fields. Of course, you achieve a more complex UI by providing custom editors, customizing layout, etc.
However, I believe that for such complex scenarios it is best to use a Controllers, which is not only more natural (normally, it is best practice for business objects not to be tied to a UI or deal with UI-related entities), but is aslo more flexible as you have full control over the UI and not limited to the business object scope.
Недавно выступал на встрече GETDEV.NET c кратким обзором нашей технологии Domain Components (DC). Вот небольшая аннотация к докладу:
"Задумывались ли вы когда-нибудь, что с переходом от SQL к DataSet, а затем и к ORM типа Entity Framework развитие технологий для доступа и управления данными приостановилось? Что еще нового можно придумать к уже привычному оперированию записями таблиц БД как объектами CRL и при этом поднять удобство разработчика на следующий уровень? На этот и другие вопросы попробует дать ответ доклад о технологии Domain Components (часть DevExpress eXpressApp Framework), которая облегчает создание повторно используемых бизнес моделей за счет легкого комбинирования путем использования интерфейсов вместо классов (это позволяет вам эмулировать "множественное наследование" в C# и VB.NET), а также свободы от особенностей конкретной ORM."
I am not sure if this will be helpful for many XPO customers, but there is definitely a number of scenarios where you may welcome the implemented behavior. Refer to the tickets below to learn more.
http://www.devexpress.com/Support/Center/p/Q489119.aspx - implemented in 13.1 where you can use the new XpoDefault.IsObjectModifiedOnNonPersistentPropertyChange and Session.IsObjectModifiedOnNonPersistentPropertyChange properties.
As you probably know, our functional testing framework - EasyTest, finds or identifies UI elements by their captions by default. This is natural and allows non-developers to easily create functional tests based on what they see on the screen.
However, sometimes there may be several elements with the same caption on the screen or their captions may be too long or inconvenient to use in the script. EasyTest also provides a solution for such scenarios and allows you to use the control's identifier instead of its caption right in the script! Let me demonstrate you how to use this hidden feature.
As you probably know, formatting property values in XAF is typically done in a platform and control-agnostic manner in the Application Model via the Model Editor (the same is of course possible in code). Now it is also possible to define formatting for a value type in a single place for all business class properties, thus saving your time.
For more details, I would like to quote myself from http://www.devexpress.com/issue=S31518:
"Starting with version 13.1, you will have a single place for setting the DisplayFormat and EditMask properties for a type, because the IModelRegisteredPropertyEditor interface has been extended with respective properties. This improvement is mainly supposed to reduce the duplicate work when providing default formatting for common types like System.DateTime, Decimal, Integer, Double, etc. As expected, these defaults will be automatically propagated to class members, ListView columns and DetailView editors, with the capability to provide custom values at these levels. Take special note that now PropertyEditors use the default formatting from the application model, or from the DevExpress.ExpressApp.Editors.FormattingProvider singleton if the model is not available. If you build a custom PropertyEditor that does not require any default formatting, you can empty the aforementioned properties in the application model for your business class property or apply ModelDefaultAttribute to it in code."
Hopefully, you will like this small usability improvement. Please let me know your thoughts in comments.
2. Use the Application Model For instance, you can implement a custom model extension that will hold the value and then create another element that will have a list of the first elements. Of course, the application model can be physically stored in the database, if required.
If you localize apps via the XAF's Localization Tool, you might face a need to skip certain captions, because they happened to be the same in your native language. For instance, the "Name" and "Navigation" are also "Name" and "Navigation" in German:-)
Althought it was already possible to do this by just copying the value manually into the column with translated values, starting with version 13.1 there is a better way of doing this. You can now just select required captions and update them at once via the new Mark As Translated command from the context menu:
It is especially helpful when you have lots of such matches.
Thanks to our loyal customers from France (Julien) and Germany (Christian) who pointed us to this small improvement. Refer to the following Support Center tickets to learn more about their stories and real-life experiences:
BTW, you may be interested to know that the standard ListViewAutoCommitController and DetailViewController classes were refactored into a single and more powerful ModificationsController one in version 13.1. Please add this ticket into your Support Center favorites to learn more about this feature.
Hopefully, you will find the demonstrated solution not only helpful for your project, but you will also recognize the popular pattern of extending the Application Model and try doing the same in your project to accomplish your custom tasks. In short, it is helpful when you want to control certain UI flow or settings at runtime, declaratively and without writing any code from project to project. For instance, once you implemented the model extension in your module, you can specify custom attributes via the Model Editor at both design and run time and then write code that will do something helpful (e.g., disable grid columns sorting and grouping capabilities) based on them.
P.S. Some of you (well, let's be honest, many of you:-) ) may ask: why are not these AllowSort or AllowGroup attributes available by default in the framework? Well, imagine that we added them, and then another customer asked for some other cool option. OK, we added it as well and so on. Eventually, will will end-up with a hundred of properties in the application model and the property grid with them will not be usable at all. In addition, the original idea of having generalized and independent from UI and controls abstractions for list and detail form, column, editor will evaporatelike smoke. You can find more interesting thoughts on this tough subject at http://community.devexpress.com/blogs/eaf/archive/2006/03/28/applying-styles-to-a-view.aspx (even though this blog post is quite old, the ideas shared in it are still valid nowadays).
So, I will use a similar approach in my XPO-based OData Service project (you can learn more on how to create it via the wizard here). Once I created the service, I will have to modify my XpoDataServiceV3 descendant as shown below:
1. I initialized the static serviceContext variable and provide the namespace of our auto-generated DC entities as the second parameter: "DevExpress.ExpressApp.DC.GeneratedClasses". It is important to avoid dealing with long-named entities like "DevExpress_ExpressApp_DC_GeneratedClasses_Survey" in our consumer applications.
2. I initialized the data layer that is used by my XpoContext descendant via the static CreateDataLayer method. There I used some XAF magic, which is required for DC, because domain logic methods accept the parameters of the IObjectSpace type. If I did not use DC, then I would not use the XAF classes in my data service and rather go using pure XPO stuff.
3. I overrode the GetSessionCore to use the Session created by the XAF's ObjectSpace, again for the correct work of domain logic methods. Take special note that this virtual method is available in version 12.2.8+ only (thanks to our XPO guys for implementing my request so quickly;-)). If you want to test it right away, I have included the latest version of the DevExpress.Xpo.v12.2.Extensions assembly into the demo project I posted here.
Finally, let me demonstrate why I created the OData service in the first place. Of course, I needed it for my mobile DXTREME application:
Originally when experimenting with this DC-based service I tried to reference the DcAssembly.dll into my data service project. This cache assembly is automatically generated by XAF when running the application with no debugger attached. So, to get it, I simply ran my XAF WinForms application, which used the same data model, and then copied the generated assembly from the Release/Bin folder into my data service project. Since this assembly contains regular persistent classes instead of DC interfaces (remember my recent talk about different types?), I hoped that this way it might be easier for you to understand and work with. Unfortunately, I had to stop using this undocumented approach later, because it required additional configuration from the application for the correct operation of the DC-based functionality: normally, when XAF loads this assembly internally it also calls the private void ProcessGeneratedAssembly(Assembly generatedAssembly) method of the XpoTypeInfoSource class. Another reason is that with the DcAssembly.dll approach it would also be more difficult to deploy and maintain the app due to the overhead on generating and copying the assembly...
I obsoleted the IModelListViewWin extension in 13.1 and moved its properties into the core IModelListView interface. Starting with that version the Web Grid and Pivot List Editors will also support setting the active filter functionality. Technically, that means that every List Editor that supports this will implement the following interface:
For instance, in the simplest case (ASPxGridView) the implementation can look like this:
bool ISupportFilter.FilterEnabled { get { return Grid.FilterEnabled; } set { Grid.FilterEnabled = value; ; } }
string ISupportFilter.Filter { get { return Grid.FilterExpression; } set { Grid.FilterExpression = value; } }
BTW, the IModelListViewWeb.FilterExpression property was obsoleted as well.
While the majority of you are unlikely touched any of those types and properties in your custom code and thus you, developers, will unlikely be affected by these changes, your end-users quite likely customized filters in your apps. Will they be affected? Hopefully, NOT!
Since we are good developers and think of our end-users, I of course ensured that their filter customizations are not lost with the new version. In order to do this, I followed the Convert Application Model Differences help article and implemented the IModelXmlConverter interface (honestly, it was already implemented there because there were already a few conversions related to templates) in our System Windows Forms and ASP.NET modules. For instance, this is how it looked in case of the Windows Forms module:
I am lucky enough that my real case was rather academical, but if you have a more complicated scenario, XAF also has a solution for you. You can learn more about it in the end of the aforementioned help article.
To sum this story up, it is always best practice to preserve your end-users settings as much as possible with the new version, because their data is one of the most important things and dealing with it carefully will ensure they will like your application in the end.
