eXpandFrameWork Bloggers

We are currently in the process of the 13.2 release planning, and I would love to get a more direct input you.
We'll use this information to better prioritize requests in our features backlog, in addition to the figures and stats we already have.
So, I highly appreciate your taking time to submit your feedback.

This first survey poll we will be fully devoted to the built-in extra modules.

QUESTION: What are the MOST used extra modules in your XAF solutions?

CAST YOUR VOTE: http://www.facebook.com/questions/486838281404899/

I would ask you to focus on the ones you use MOST of the time, e.g., from project to project, and not occasionally. You can find the list of XAF extra modules here, just in case you forgot their names:-)

Hopefully, many of you have Facebook accounts nowadays. I think that it is worth to continue this experiment if there will be a lot of different participants. I'll also keep in mind to test-drive our LinkedIn developers group (which is quite active recently) or other means, if the FB does not work well.

P.S.
Do not forget to like our official XAF/XPO page (it's quite new), if you happen to be on FaceBook and like our framework and its services:-)

332

332

From this page you can regularly receive latest news about our frameworks and also participate in various surveys and discussions with other XAF developers.

UPDATE:
See another poll from the eXpand Framework team:

Poll - Which of the following eXpand modules/features do you use most?

I would like to draw your attention to the recent documentation updates, because as you know, not only product features themselves are valuable, but also good documentation that details how to use them in practice, improving your skill set and making you more productive.

Concerning XPO, I suggest you checking this link as it will make you more fluent in using the ORM Data Model Wizard, OData and other design time features:

As for XAF, check out this update to learn about new elements which you might have not used in the past:

If you want to improve your mastery for other DevExpress products, check out the full list of recent documentation updates here.

We constantly update our documentation and examples, so do not forget to check the What's New documents from time to time, because it lists more than new product features and fixed bugs.

I'd like to repost this good news for people who want to become an XAF expert in a few days, literally.

"The next class is a European event: October 7-11 for XAF, in a new location in Germany. I will teach this myself, and the class will be in English language as usual - important to stress in Europe!

XAF Training Event (Europe)
This class covers the eXpressApp Framework as completely as possible in the timeframe. The target is to enable you to create your own XAF based applications, and to answer any questions you have. XAF is a large product that includes many modules and targets two different platforms - the one-week timeframe of the course is the only limit on the depth of coverage!"

Follow this link for XAF class details, syllabus and registration information.

http://www.devexpress.com/XAF - learn more on how XAF can help your business to build good-looking and powerful apps for both Windows and the Web in minutes:

When something gets very complex and there is no space for all the info on the screen (imagine a form with 300 text boxes and other controls on it - yes, I saw such forms in my life!) you can use various techniques to temporarily hide or completely remove certain info (probably rarely used) or allocate it in a way it will occupy less space.

Many container UI elements like tab controls, panels and our layout control are designed to help you with this task. Talking about XAF apps, the most popular way of accomplishing this I saw was putting unwanted fields behind the tab groups, which were activated by end-users on demand:

This approach does not involve any refactoring of your underlying data model, but just means re-layouting the default form in a way where most often used data appears on top while having less popular data hidden. It seems that this all comes from trying to mimic the behavior and look & feel of legacy apps or even papers, because many end-users might be accustomed to such a UI in the past.

Another, but less popular approach I saw was in refactoring a huge data model, which technically means aggregating similar data into a separate part, adding a reference to it from the main object and then showing a separate detail form on demand, e.g. via a button in the toolbar. A perfect example of this can be our ObjectPropertyEditor that can be used for an aggregated reference property and that displays a nice UI for editing its details:

Today, I would like to show you an alternative way of solving the problem of complex detail forms usability. I am double excited about this solution, because it comes from our XAF customer, Sergey Zaycev and his team from Galaktika, whom I recently blogged about.
These guys implemented a custom Property Editor - TabbedDetailPropertyEditor (check this help link to learn more on how it is possible to create such extensions yourself), which is essentially a tree-like navigation panel at the left side and a detail panel on the right. Each node in the tree represents a small portion of data, which is then displayed on the right side as user focuses it in the tree:

This hierarchy is fully customizable at runtime, thus allows you to meet the needs of a very demanding client right in front of his/her PC.

In my opinion, this is a very good alternative to the standard approaches described above. If you think about it, you may find the analogy with how the main application navigation works. Of course, this displaying a small portion of data at a time also works faster and thus is more usable.

I liked this idea very much, what about you?

If you liked this stuff, then I suggest you learn more on it as well as check out other XAFARI platform features at http://xafari.ru/

As promised in eXpand’s forums with next version of eXpand (13.1.5.8) you can enjoy anonymous authentication for your web applications!

The anonymous authentication functionality is embedded in Xpand.ExpressApp.Security.Web module. After installing this module you need to enable it and setup the anonymous username using XAF’s Application Model Editor.

It is possible and recommended to combine anonymous authentication with auto-authentication discussed in http://apobekiaris.blogspot.gr/2013/07/auto-authentication-rememberme-for-your.html. Note that the model of the previous post is refactored to allow each feature to work independently.

Next you need to configure XAF’s security system by setting up the Authentication and the LogonParameters as illustrated in the image bellow.

And finally you need to create the anonymous user and role in your ModuleUpdater.cs. For this and if your use XpandRole class I provided the next extensions methods (GetAnonymousRole, GetAnonymousUser).

voidCreateAnonymousSecurityObjects() {

var anonymousRole = ObjectSpace.GetAnonymousRole("Anonymous");

anonymousRole.GetAnonymousUser();

//add project specific permissions

anonymousRole.SetTypePermissions<Category>(SecurityOperations.ReadOnlyAccess, SecuritySystemModifier.Allow);

anonymousRole.SetTypePermissions<Topic>(SecurityOperations.Read, SecuritySystemModifier.Allow);

The GetAnonymousRole method will create a new XpandRole (if not exists) and will add two custom permissions the MyDetailsPermission that will hide MyDetails from anonymous role and the AnonymousLoginPermission. It is also possible to do the same using XAF’s UI as in the next image.

Moreover I want to mention that using XpandRole is not mandatory, I used it because of the built-in support for custom permissions. You may have your own implementation following for example How to: Implement Custom Permission, Role and User Objects so feel free to use them.

Together with the MyDetailsPermission I mentioned the AnonymousLoginPermission. This one is responsible for hiding the default XAF’s Logoff action and for providing a new LoginAnonymous action. So when someone visits your site and you use Xpand.ExpressApp.Security.Web with enabled anonymous access, by default XAF will authenticate the anonymous user you created in the ModuleUpdater, and with the LoginAnonymous action will allow authentication as provided by XAF.

That was it my friends! I hope you find this implementation easy to use and useful. For questions, feedback etc feel free to use eXpand forums.

Happy XAF’ing to all!

As you probably know, XAF Application Model is flexible enough to allow you to extend it to store own UI and behavior options (learn more...) for all users or individually. Today I would like to spent a few minutes to show you one of the possible approaches to provide default values for your custom options.

Scenario
Let's consider a real-life scenario, which I believe many of you deal with in XAF: you create a validation rule via the Model Editor and specify the TargetContextIDs property to tell XAF when to check it:

Technically, there is a string property declared in the IRuleBaseProperties interface:

[Required]
[Category("Behavior")]
[DXDescription("DevExpress.Persistent.Validation.RuleBaseProperties,TargetContextIDs")]
string TargetContextIDs { get; set; }

Our goal is to provide a drop down editor in the property inspector (instead of the plain text box) to be able to choose the predefined "Save" or "Delete" strings instead of typing them manually.

Solution:
One of the possible solutions is to use the standard .NET Framework TypeConverter mechanism. I should explicitly note that there are many other possible solutions for the same in XAF, and I just would like to describe this one because of its simplicity and popularity even outside of our framework.

Basically, I will perform the two simple steps:

1. Create a custom TypeConverter by descending from the standard StringConverter class and overriding a couple self-explanatory methods (learn more...):

public class DefaultValidationContextsConverter : StringConverter {
public override bool GetStandardValuesSupported(ITypeDescriptorContext context) {
return true;
}
public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context) {
return new StandardValuesCollection(Enum.GetNames(typeof(DefaultContexts)));
}
}

2. Mark the required model element property with the TypeConverterAttribute passing my custom converter as a parameter:

[TypeConverter(typeof(DefaultValidationContextsConverter))]
string TargetContextIDs { get; set; }

That's it.

Results
You can see what we are after in the screenshot below:

BTW, this small improvement will be available starting with in the next minor update (13.1.6), and it should improve usability for beginners in this scenario.

If you know about other scenarios in our framework where usability can be tuned, do not hesitate to let us know as we will be glad to see to it.

Alternative solutions
Depending on your business requirements it would be possible to achieve the same or similar effect using other techniques:
1. a custom UITypeEditor;
2. DataSourcePropertyAttribute/DataSourceCriteriaAttribute;
3. Domain Logic,
to name just a few. I hope to talk through them in the future when I have some time.

Our community project (www.eXpandframework.com)
is growing fast and thanks everybody for the contribution and trust! However in order to use our limited resources better and make some plans for the future I would to ask your participation in the following survey.
I would like to ask your input one more time in the following survey: Click here to take survey

Reminder: There is also a XAF related survey going on at http://dennisgaravsky.blogspot.ru/2013/06/we-are-currently-in-process-of-13.html.

Both are our tools to get direct feedback from all of you to improve our beloved XAF.

Thanks you all for your participation!

I would like to let you know about another usability improvement I have recently committed.

Starting with version 13.2, you will be able to configure the order of enumeration items in the Model Editor under the Localization | Enums | <Your Enumeration> node by setting the Index property as shown in the attached screenshot:

Previously, these values were sorted alphabetically by the caption, and it was only possible to customize this order in code by accessing the underlying editor and customizing its items collection. This had to be done differently for both Windows and the Web due to the differences between these platforms. So, I hope you can see how this small improvement can save your time since you will be able to enable it in platform-agnostic module.

I've recently refactored (for XAF 13.2) the WinPropertyEditor, DXPropertyEditor and a few descendants to provide a common code for updating the control's availability (technically the System.Windows.Forms.Control.Enabled property) and also added support for skipping tab stop if the control is disabled. Check out the video below to see how it works in action (take special note that the FullName property is readonly):

Unable to display content. Adobe Flash is required.

Just for this video, I temporarily enabled highlighting of the focused item in the layout control so that you could better see how the focus moves in the form.

This task is not yet finished, and I have a few questions for you:

1. Do you want to skip tab stop for readonly editors and columns by default in XAF?

2. Do you want to control this behavior via the Model Editor on the DetailView or application levels or may be controlling this in code would be sufficient)?

Your feedback is needed!
Personally, I think that #1 can be the default behavior, because I believe this is what the majority of users expects, but still wanted to hear from you as your end-users may have different preferences.

As for #2, I am a bit hesitant about providing a new option in the Application Model for each DetailView node. I think that it can be globally disabled somewhere under the Options | LayoutManager, though.

Thanks for your input in this regard!

P.S.
This behavior already presents in ASP.NET apps by default, so that we do not need write any code for this.

You all know the powerful Application Model Editor with the embedded layout control that allows view creation without any technical knowledge. However the Model Editor is so powerful that may be dangerous to allow access to everybody. A few years now in eXpand we have the XpandViewVariants module that allowed end users to build views without the model editor. This modules is based in XAF’s built-in ViewVariants module and the XAF team is constantly improving it. However eXpand resources are not so huge so our module was a bit outdated.

Today things changed, because I spend some hours to refactor the ModifyVariantsController and now can do magic. if you using eXpand you only need to install XpandViewVariants module, if not and thanks to XAF’s MVC architecture just grab the controller for eXpand’s online repository http://goo.gl/mnFR7 or even follow its history http://goo.gl/CPx5A.

Now simply watch the next video to see that this controller can do for you.http://screencast.com/t/nrELagRJBhY

P.S.: We really appreciate your input in our latest surveys we run for both XAF and eXpand. If you haven’t participate yet please see this post

http://apobekiaris.blogspot.ru/2013/07/poll-which-of-following-expand.html.

Comments as always in eXpand forums Smile , here a related thread http://goo.gl/cQ05p.

Today I made the ASPxLookupPropertyEditor a bit more usable with regard to how it handles the tab stop (yes, again!). Thanks to the customer who drew my attention to this scenario.

If you are reading our docs from time to time:-), then you are probably well-aware that this Property Editor can render different controls based on whether the search functionality is required or not:

Let me quote the Built-in ASP.NET Property Editors help article for more details:

The ASPxLookupPropertyEditor creates either an ASPxLookupFindEdit or ASPxLookupDropDownEdit.
The ASPxLookupFindEdit is created when the Search functionality is required. This occurs in two cases. First, when the number of objects to be displayed exceeds the value of the IModelOptions.LookupSmallCollectionItemCount property of the Application Model's Options node. Second, when the LookupEditorMode property of the BOModel | Class | Member node or the corresponding Views | DetailView | Items | PropertyEditor node is set to AllItemsWithSearch or Search. For details on the Search functionality, refer to the How to: Add a Search Action to Lookup Property Editors and Link Pop-up Windows topic.
ASPxLookupDropDownEdit is created when the Search functionality is not required.

These controls are technically descendants of the standard System.Web.UI.WebControls.Table class with a few nested controls inside (buttons and the actual editors: text box or combo box).

A customer wanted to disable tab stop for the lookup editor and this typical task can be accomplished in ASP.NET by setting the standard WebControl.TabIndex property.

While testing this simple solution I found that the focus still goes to the editor's buttons, which requires more work from the developer to access these buttons and set the TabIndex property for them.
Since I am a bit "lazy" developer (like any XAFer out there;-)), I decided to improve usability in this common scenario by modifying the ASPxLookupFindEdit or ASPxLookupDropDownEdi classes in the following manner:

public override short TabIndex {
get {
return base.TabIndex;
}
set {
base.TabIndex = dropDown.TabIndex = newButton.TabIndex = clearButton.TabIndex = value;
}
}

As you can see, the container control now more cares about its children to help you write less code in this scenario:

if(propertyEditor.FindEdit != null) {
propertyEditor.FindEdit.TabIndex = -1;
}
if (propertyEditor.DropDownEdit != null){
propertyEditor.DropDownEdit.TabIndex = -1;
}

It is a small improvement, but hopefully you will like it. BTW, I also exposed public properties to access the editor's New, Find and Clear buttons, which may be helpful for you as well.
After writing the unit test, I tested how this works in the MainDemo app, and I must admit that it become more usable, because you do not need to skip tab over several buttons.

This improvement will be available with the version 13.1.6 and higher.

I like to introduce a little Framework about mapping/decorating XPO/EntityFramework classes in XAF using the typesystem XAF provided without having to 'pollute' your model-assembly with DevExpress.ExpressApp assemblies:

Para.FluentModelBuilder

In the readme.md you can explore what we've build so far :)

Happy coding, and hoping for feedback from the great XAF-Community Greetz Manuel

Yes, you are right, and let's be honest that it was quite easy to guess:-)
I am referring to the Validation - Warn end-users about mistakes/inconsistencies without preventing them from saving changes request, which we are currently working on, and hope to include a solution into the standard XAF delivery in 13.2 (no exact promises, as always!)

I want to pay your attention to this Support Center ticket, because here I was involved in memory profiling with my colleague, and also because I remember that some time ago somebody from the XAF community asked to elaborate more on the memory profiling process.

I doubt this info will be interesting for experienced developers, but we should not forget that there is a large number of people who are using XAF and who love it because it helps them to care less about the underlying technology and what happens behind the scenes.

Hence, my colleague and I wrote a detailed explanation of how we profiled a case when a report preview window is opened and then closed. So, let me quote us from that ticket:

"In fact, it is not guaranteed that the CG will be called automatically after a period of time.
During the normal application life cycle, GC may not be called at all, unless its garbage collection is forced by the CLR.
You can learn more on how the GC works at http://msdn.microsoft.com/en-us/library/ee787088.aspx#conditions_for_a_garbage_collection.

Now please let me elaborate on how we find memory leaks in .NET apps internally.
For example, you may want to check for memory leaks when a report preview is shown.

Here are the steps you would perform:

1) Run the application under the profiler and open the report preview;
2) Close the report preview;
3) Now we will make a single snapshot. Take note that we did not make a snapshot before the report preview was closed, because at this stage not all static variables and other resources can be loaded and properly initialized;
4) Open the report preview once again;
5) Close the report preview;
6) Make the second snapshot.

You can learn more about these steps in the documentation of your preferred memory profiler. For instance, we can also use the .NET Memory Profiler:
http://memprofiler.com/OnlineDocs/default.htm?turl=findmemoryleaks.htm.

At this stage we can analyze the difference between these two snapshots to see whether there are any memory leaks.
In particular, we are looking at the following columns:
1) Column Live bytes / Delta
2) Column Live instances / Delta
Refer to the http://memprofiler.com/OnlineDocs/default.htm?turl=overviewpage.htmhelp article for more details.

As for the Real-Time Page, it only provides auxiliary or supporting information, and does not allow you to determine a memory leak:
http://memprofiler.com/OnlineDocs/default.htm?turl=realtimepage.htm."

Of course, tools like .NET Memory Profiler are themselves extremely helpful as they guide you through the process. For instance, take a look at the Tasks window in this tool:

Quite good documentation on where to look for leaking bytes and various hints in the UI are also at your service.

You probably saw my recent post about the feature we are developing for 13.2. This nice addition to the framework was welcomed by the XAF community and there were some questions from customers which I would like to answer here. So, let's do it!

Q1: Chris G. RoyleIt's difficult to see from the screenshots how you've implemented Dennis. If you've used the snippet that Tolis posted recently in a blog,
A1: No, we have not used the eXpand Framework implementation.
Take special note that a validation warning rule is declared as follows:

[RuleCriteria("RuleWarning", DefaultContexts.Save, @"IsWarning = false", SkipNullOrEmptyValues = false, ResultType=ValidationResultType.Warning)]

You can learn more about our implementation from these short videos:

Winforms: Unable to display content. Adobe Flash is required.

ASP.NET: http://www.screencast.com/t/HmxcBrqo

Q2: Chris G. RoyleAlso, how does this affect validation called in code (not at a PC) ?
A2: Currently, broken validation warning rules are treated the same way as regular broken validation error rules.
Technically, that means that if I use the following code:

var obj = ObjectSpace.FindObject<ValidationErrorsAndWarningsFeatureObject>(CriteriaOperator.Parse("!IsError && IsWarning"));
RuleSetValidationResult result = Validator.RuleSet.ValidateTarget(ObjectSpace, obj, "Save");
System.Diagnostics.Contracts.Contract.Assert(result.State == ValidationState.Invalid);

The result.State will be Invalid. Refer to this video for more details on this. I feel that this is something you may want to customize to achieve a different behavior (e.g., have something like ResultType to know whether it is an error or warning). So, I wanted to hear from you on this as well.

Q3:Chris G. Royle it'd be useful to implement information items as well, which would be consistent with idxerrorprovider (iirc).
A3: Yes, we considered this as well, but have not yet included this functionality into the standard delivery, because we had some questions concerning the default behavior. For instance, the validation information rule can be declared as follows:

[RuleCriteria("RuleInformation", DefaultContexts.Save, @"IsInformation = false", SkipNullOrEmptyValues = false, ResultType=ValidationResultType.Information)]

That's all clear, but it is not clear how this should be rendered in the UI (I am not talking about the information icon near the editor). Currently, warning messages are listed in the dialog with other errors and you can skip by pressing the Ignore button in the dialog.

Do you want exactly the same behavior for information messages?

I appreciate your feedback in this regard. Also, let me know if you have other suggestions and considerations.

In next version of eXpandFramework 13.1.5.13 it will be possible to create associations between business objects. Let’s see in details how this will work.

1. Installation – Prerequisites

The runtime members can be found in the eXpand.ExpressApp assembly, therefore you need to install the XpandSystemModule. However because this assembly has platform specific versions you will not find it in the toolbox and you have to go for its win or web version which is XpandSystemWindowsFormsModule or XpandSystemAspNetModule. To see how easy it is to install the XpandSystemWindowsFormsModule watch the next video. Note that it is also possible to create object relationship for the web.

2. Simple association

In the next video you can see how we can create a relationship between two entities at runtime. To be more specific I will create a relationship between the TopicIcon and The Category business objects. I already have a sample application and logged in as the Admin user so the relationship I will create it will be stored in Admin’s user model.

3. Creating the many part of the relation

In the next video instead of working with XAF’s default model editor, we will use the ModelDifference module. XAF’s Application Model is by design multi layered and the ModelDifference module exposes this functionality in a more business oriented approach. It is also faster to work with it because as you can watch in the video I only execute the save action without even reloading the model! Even if the ModeDifference module introduces the concept of application models, I am going to use again Admin’s model and I will create an Icons collection for the Category object and I will link the reference TopicIcon Category property I created in previous video. Note to install the ModelDifference module you need to go through the exact steps of step one but this time for the ModelDifferenceWindowsFormsModule.

4. Creating an Orphaned Collection

An orphaned collection does not participate in a relationship however it is possible to be filters. In step three I linked a TopicIcon with a Category and also added a TopicIcon to the same Category instance. Both TopicIcons were of Type Idea. Now I will create an Orphaned collection of all TopicIcons with Type Idea and I will add it to the Category_DetailView.

5. Distributing the Application Model

We already created our relationships in the Admin’s model. However, this means that they can be used only for the Admin user. To confirm this in the next video I will give Edit Model permissions to a normal user and I will login to explore his model. Then I will switch back to the Admin which has permissions to modify ModelDifference module objects. Next I will create a Role model by cloning one of the existing models. Finally I will associate the Role model with the users Role, I will merge it with the Admin’s model and switch back to the User to confirm that he also can see the same as the admin.

Forgot to mention that runtime member creation is now very fast thanks to Sandrowelter (see this thread in eXpand forums).

Happy XAF’ing to all!

Let me quote myself from the Core - Introduce an ability to have two or more classes with one and the same name, but declared within different assemblies thread:

"After receiving customers feedback, we decided to change our original implementation (it exists in versions 13.1.3-13.1.5 only) to completely avoid a breaking change here for existing customers (optionally refer to the Core - Make it possible to find a View node by its short identifier ticket for more details on the consequences of the previous change and conflict resolution options).

So, starting with version 13.1.6 the generation mechanism will stay unchanged (short identifiers like Customer_ListView will be used), while having the capability to resolve a name conflict in advanced scenarios (see the updated description of this thread).

According to all our estimates (tickets in the Support Center and other stats), the number of people migrated to version 13.1 and who already started using long identifiers should be small.
If you already migrated your app to 13.1, it will be required to change long identifiers to short ones after 13.1.6 is out and ONLY in places where you compared View.Id == "MyObject_ListView" in code (the rest should be automatically resolved!). We do not think that it should affect many developers (we only had a single customer call as of now), because the previous conflict resolution options we introduced should cover 95% of cases.

If you are upgrading your app to version 13.1.6 directly, no changes will be required from you at all. In any event, if you experience any difficulties with this upgrade, our Support Team will be happy to help you resolve all problems.

I want to thank you all customers who provided their great feedback during this time and also want to apologize for all the inconvenience here."

Here is what you can do if you encounter such a naming conflict in your app:

"Starting with version 13.1.6, you can use classes with the same short name but different full names in the same XAF application (e.g., you have your own YourSolutionName.Module.Customer class and also want to use the Customer class declared in a third-party module).

To register classes with a name conflict, use the static DevExpress.ExpressApp.Model.NodeGenerators.ModelNodesGeneratorSettings.SetIdPrefix(Type type, string prefix) method.
This method affects two types of identifiers: - Views identifier (e.g., prefix_ListView);
- Identifiers of Actions defined via the ActionAttribute (e.g., prefix.MethodName).Take special note that you need to use this option very carefully if you have existing Application Model differences declared for conflicting classes. These model differences will have to be updated according to the specified prefix."

Short Summary
Our original solution used long identifiers everywhere and this new algorithm did not require changes in your code, except for a single scenario: when you compare View identifiers in code like View.Id == "MyObject_ListView" directly in your code.

We come to the conclusion that it may be inconvenient for our customers to modify their code to use the automatic conflict resolution options we introduced, even though this was quite rare scenario and code changes could be done automatically using the Visual Studio Replace dialog facilities (via regular expressions).

So, starting with version 13.1.6 there will be no change at all required = short identifiers like Customer_ListView will be used as before.

You can download the 13.1 hotfix with the described changes from here: http://downloads.devexpress.com/Share/DXP/130730/DevExpressNETProducts-13.1.5.13211.exe
The official 13.1.6 update should be available in a few weeks (I cannot promise the exact release date at the moment).

You are probably aware that we have a very popular feature request for our XAF Reports module:

Reports - Make it possible to easily use XtraReports designed in Visual Studio.

It is primarily about allowing you to easily reuse regular XtraReports created in Visual Studio in an XAF application

I must say that nothing has already prevented you from displaying regular reports in XAF in exactly the same way as you would do in a non-XAF app, but of course the XAF reporting is not only about that: our built-in module also integrates reports into the application navigation and menu systems, enabling end-users to create reports at runtime and store them in the database, adds the Show In Report command to list and detail forms, as well as adding many other features requested by our customers.

I wanted to inform you that the aforementioned request is planned for version 13.2, and we are currently working on it.

Overview
Here is a very short overview of the new features:

1. You can create a regular XtraReport in Visual Studio and connect it to a special XAF reports data source dragged from the Toolbox;
2. There are two main XAF report data source types: CollectionDataSource and ViewDataSource.
The CollectionDataSource is very similar to an XPCollection, while you can think of ViewDataSource as an XPView component, allowing you to specify and load only required data properties or aggregated calculations instead of the whole objects hierarchy. The latter part is new for XAF reporting and is also something that was requested in the past by many customers, because it can help you achieve a better performance and less memory consumption for large and complex data models.
3. You can configure data type, sorting and filtering options for these data sources at design time and XAF will connect it to the corresponding data from your app at runtime.

We decided to create a new module to avoid breaking changes for existing customers, which means that existing XafReports will work as expected in the new version and can coexist in the same application with the new reports:

Feedback is needed!
Please let me know whether you like these features. Also, which features you want to see in the new module?

Let me quote myself from the

Layout.Web - provide the capability to manage the display of detail collections, not on the global application level but, for each DetailView separately feature request, which we have just implemented in 13.2, while working on a bigger feature:

"Starting with the version 13.2, you will be able to control this behavior vis-a-vis the DetailView via the CollectionsEditMode property exposed in the Model Editor for Web projects:


[XML]

<Views>
<DetailViewId="Contact_DetailView"CollectionsEditMode="View"></DetailView>
</Views>

The above setting in the XAFML file will enable the View mode only for the Contact DetailView, while the rest application will use the default mode or the one specified in code:


[C#]

protectedoverridevoidOnLoggedOn(LogonEventArgsargs){
base.OnLoggedOn(args);
ShowViewStrategy.CollectionsEditMode=ViewEditMode.Edit;
}

Personally, I love when working on something big small things like this one get attention and are resolved. I hope you like this too:-)

I just would like to remind you about a feature that currently exists only in XAF Web UI, but which is for some reason is rarely used by customers (at least from what I see in the Support Center while helping other customers). Please refer to the attached screenshot:

Does it look familiar to you?
If not, then please refer to the XAF documentation to learn more about the IModelNavigationItem.QuickAccessItem property. You can set it via the Model Editor for a required navigation item while configuring the navigation system under the NavigationItems node.
Technically, these items are rendered by the QuickAccessNavigationActionContainer class placed within the default web page template.

Hope, I will see this small feature more often in your apps from now. As for the Win UI, you may be interested in tracking the Navigation - Allow end-users to mark certain navigation items as favorite ticket, which is a more general request.

BLOG by Dennis Garavsky: What are the MOST used extra modules in your XAF solutions?

Poll - Which of the following eXpand modules/features do you use most?

BLOG by Dennis Garavsky: What's New In DevExpress Documentation? (PING!)

BLOG by Dennis Garavsky: DevExpress XAF Training class in Germany (October 7-11)

BLOG by Dennis Garavsky: A possible way to improve the ergonomics of a large and complex detail form

BLOG by Apostolis Bekiaris: Anonymous authentication for XAF aps.net applications

BLOG by Dennis Garavsky: Providing predefined values in the property inspector for a custom application model attribute

BLOG by Apostolis Bekiaris: Poll - Which of the following eXpand modules/features do you use most?

BLOG by Dennis Garavsky: Reordering enumeration values by setting the Index property under the Localization | Enums node

BLOG by Dennis Garavsky: Skipping tab stop for disabled/readonly editors and columns

BLOG by Apostolis Bekiaris: Runtime views created from business users

BLOG by Dennis Garavsky: Improving ASPxLookupPropertyEditor tab stop behavior

BLOG by Manuel Grundner: Introducing Para.FluentModelBuilder

BLOG by Dennis Garavsky: Guess the feature by screenshots;-)

BLOG by Dennis Garavsky: About profiling memory leaks...

BLOG by Dennis Garavsky: Developing the validation warnings feature - Feedback is needed!

BLOG by Apostolis Bekiaris: Creating object relationships using the application model

BLOG by Dennis Garavsky: Short vs Long View identifiers in version 13.1 (MUST READ)

BLOG by Dennis Garavsky: Developing the new Reports module

BLOG by Dennis Garavsky: The CollectionsEditMode option gets more flexible

BLOG by Dennis Garavsky: Quick Access Navigation on the Web