XAF Customer Satisfaction and Product Usage Survey - YOUR FEEDBACK IS NEEDED!!!

https://www.devexpress.com/go/XAF_Future_Survey_2017_Dec.aspx (~5 min)

Your feedback will help us ensure that the tools we deliver to market meet your expectations better. Thanks for your help in advance!

(special thanks to a small group of users who has already helped to test and refine these questions)

Implementing State Machines at the Business Object vs Controller levels - YOUR FEEDBACK IS NEEDED!!!

I wanted to seriously question the current approach for declaring state machines in code using the StateMachine<T> class and IState/IStateMachineProvider interfaces (Predefined State Transitions Created in Code) and hear what you think of it in general. The main reasons behind this interest are the limitations this originally implemented approach has compared to other available solutions and hence associated support costs.

"Yet Another Controller"© 

In fact, in certain scenarios, creating a custom Controller with the SingleChoiceAction Action or a set of SimpleAction Actions can be simpler and more straightforward than defining a coded State Machine at a domain level. To give you a concrete example of such an alternative solution, check out this Controller that eventually does the same thing as the code in the original documentation article above, but with old-good SimpleAction objects manipulated on View and other suitable events. You can find another example with a SingleChoiceAction in this test project (it's from this SC ticket, so process it with the Project Converter tool first). Even though the alternative Controller-based approach requires more code, it allows you to provide a more granular control over created states and their visual representations. It is cleaner and easier to understand/extend for other business requirements, because it is your own code that uses only the basic XAF APIs.

Implications of using the questioned approach
Contrary to that, the questioned approach is really a bit shorter with the help of 'state', 'transition' and 'state appearance' abstractions defined near your business class, but everything has its own trade offs.

Simplifying customization of Action controls - YOUR FEEDBACK IS NEEDED!

As you know, XAF provides abstractions for common UI elements like list and detail forms, their editors, main and navigation menus, etc. that enable XAF developers to accomplish common tasks for several supported platforms with less effort. Today I want to take a moment of your time and focus on popular customization tasks related to Actions - typically abstract UI elements that allow you to perform specific operations in response to end-user manipulations.

For instance, the ActionBase class, which is the super class for all Action types provides many useful members like Caption, ToolTip, Shortcut, PaintStyle, Enabled, Active, etc. that help you care less of technical implementation details for each specific platform or situation, at least for the popular tasks these members were designed for. It is also super easy to manage these properties and events in code or via the visual designers like the Visual Studio component designer for Controller or our own Model Editor.

Current approaches for customizing Action controls

The above looks very well (and many XAFers expressed this is one of the things they love the product for) and we have always been trying to keep this promise when designing our framework:
common and simple tasks can be done easily, while any specific or complex tasks are technically possible. 

But what about the second part of this promise with regard to Actions in practice? To answer this, it is best to evaluate it yourself for various tasks. Our documentation and support knowledge base contains many code examples for customizing Action controls in various places of an XAF application, and I grouped them below for your review.