XAF - New Grid List Editor, Survey on the Main Menu Toolbar and End-User Layout Designer in Blazor UI

XAF Team Blog
21 December 2021

New DxGridListEditor (CTP) - Try It Out in v21.2.4+

As you may already know, XAF's Blazor UI includes a new UI element - Grid List Editor (DxGridListEditor). This new UI element is built atop the new DevExpress Blazor Grid control. Like the new Blazor Data Grid, DxGridListEditor will be updated with new features every minor release and we plan to deliver much more in our v21.2.5+ minor update in late January 2022. XAF Blazor UI users will especially appreciate Conditional Appearance support, Server Mode support (yes, we may return to DataAccessMode = Server instead of Queryable, because it supports more features like runtime calculated fields), customization form support, and much more.

This post is just a gentle reminder for early adopters/testers to explicitly enable the new DxGridListEditor in their projects (since it is a preview) and share their feedback with our development team via the DevExpress Support Center. 

Main Menu Toolbar - Your Feedback Matters

At present, XAF's Blazor main menu toolbar hides commands based on record selection within the ListView. This behavior was introduced 1.5 years ago and it differs from XAF's WinForms & ASP.NET WebForms UI. We designed this menu in this manner because it is more suitable for smaller screens (on mobile web browsers), which XAF's Blazor UI also supports.

Menu Behavior 1


Menu Behavior 2

Throughout this year, many of you have asked us to restore our WinForms & ASP.NET WebForms UI implementation - menu commands are disabled based on record selection within the ListView. 

Question 1: Which default behavior do you prefer for XAF's Blazor UI (v22.1+)? Please add "Menu Behavior 1 or 2" and, optionally, describe your use-case/reasons in the comments section below.

If we do not have many votes for the new behavior (2), we will simply retain our existing implementation and focus on more important things for the majority of users. Thanks for your feedback in advance.

Teaser 1: Runtime Form Layout Customization for Your End-Users

For our v22.1 release in May 2022, we are researching the technical possibility to implement layout customizations in XAF's Blazor UI for end-users (just like its WinForms counterpart). You can get a taste of this below - our first spike (please ignore UI design issues - it is just a wireframe to demonstrate the main idea):

If you’ve used XAF's WinForms UI, you already know that rich runtime UI customization for both developers and end-users can be a time saver - your apps can address changing business requirements without the need for redeployment.

Question 2: Would you like us to continue our research and implementation? If so, please add "+1" or "-1" in the comments section below. If you have multiple XAF developers, you can certainly add "+10" or "-5"😀 and describe your other priorities.

This is a very serious and costly undertaking, so we want to be certain that we have sufficient support from registered customers. So - if this feature does not elicit a simple +1 comment, it is a sign that we should not pursue this feature.

Teaser 2: Custom Buttons for XAF's Blazor UI Lookup Editor Are Coming

XAF's Blazor Lookup Editor will display the "New" and "Open Related Record" buttons in v21.2.5 (January 2022).

Visual Studio 2022 Support for XAF and XPO

XPO's ORM Data Model Designer, XAF's Model Editor, and Solution Wizard support Visual Studio 2022 in v21.2.4 - please try these designers and let us know your thoughts.

Note that the Application and Module Designers for .NET Framework apps are not yet supported (track progress). As a workaround, edit the WxxApplication.xxx/WxxApplication.designer.xx and Module.xx/Module.designer.xx files in code (Add a Module in Code).

Dependency Injection Extensions for XAF Module Configuration Are Coming

As you may recall from our roadmap, we will NOT support Module and Application Designers in .NET 5+ apps (.NET Framework apps will be unaffected), because they mostly duplicate Solution Wizard functionality and are rarely used (occasional module or application configurations can be easily addressed with a few lines of code: example). To promote straightforward and consistent configurations for security and application modules across WinForms and Blazor in .NET+, XAF v22.1 will support Dependency Injection (DI) extensions like those found in ASP.NET Core Blazor Server apps.

Need Faster Support Replies?

Once you create a new XAF ticket in the DevExpress Support Center and select XAF under the Platform/Product field, please review the following help links displayed above the Submit button. These links describe how you can collect callstacks, logs and other important diagnostic information for any .NET error. Once you collect/compile this information, forward it to us along with your support ticket. This information will ensure faster and more accurate replies from support.

Krzysztof Kasprowicz
Krzysztof

Menu Behavior 2 I think it's less confuse for users.


21 December 2021
Julio
Julio
+1
21 December 2021
Martin Praxmarer - DevExpress MVP
Martin Praxmarer - DevExpress MVP

Not sure what is the best option - ideally having both and change it based on the requirement - i think Menu Behviour 1 makes sense on Mobile Layouts - where space is limited - but Behaviour 2 would make sense on Desktop where more space is available. Also - like discussed on the Ticket - we need to have Actions available with SelectionDependancy Independant - even if an record is selected.

Detail Form Layout Customization - +N ;) ;) - this looks pretty amazing!!

21 December 2021
Krzysztof Kasprowicz
Krzysztof
+1
21 December 2021
Emanuele
Emanuele

Question 1: both, if it possible

Question 2: +1

21 December 2021
Evgeniy Meyke
Evgeniy Meyke

+1

Menu Behavior: 1, and  allow option to switch

21 December 2021
Ivan Montes
Ivan Montes

Q1: Both, if it's possible

Q2: +1

21 December 2021
JeePee [NL]
JeePee [NL]

Q1: Both

Q2: +5

21 December 2021
Gustavo Marzioni
Gustavo Marzioni

 Menu behaviour : "we need to have Actions available with SelectionDependancy Independant - even if an record is selected. " +1


Detail Form Layout customization +1

 

21 December 2021
Joche Ojeda
Jose Javier Columbie

Q1: Menu Behavior 1 

Q2: +15

21 December 2021
CRM-d4912f15-de1a-4da6-8cba-55637e0e77c3
Abdul

Both Menu Behaviour will be nice if less efforts required

Form Layout customization is most wanted features and it should be implemented I think

New & Open related record is long waiting features and finally it's a great news

21 December 2021
Pawel Botwina
Pawel Botwina
Q1: Both
21 December 2021
Kartal TURGUT
Kartal TURGUT

Q1: both, if it possible. if not possible 1 is work perfect.

Q2: +10 :)

21 December 2021
TimKh
TimKh

Question 1: Behavior 2. I just had a meeting with clients showing some new features in an application and overwhelming response was: how we know that functionality is there if we do not see it until we do something like select an item to see what we can do with it. Also it seems to be confusing to users when buttons change.


Question 2: It really depends how it works. I have number of requests from users that want to remove fields that do not use and have to use conditional appearance to show/hide properties based on user preferences. Having user customize views to their liking improves performance and less work for me but

Are we able to lock it out or user always can change a view?

Do the changes apply on application scale or user specific and each user has to make their own change?

If the changes apply to application, how it affect multitenant applications?

Can a view to be reset back to original state?

+2 if we can control what user can and cannot do with the views.


21 December 2021
Tomaz Cebasek
Tomaz Cebasek

q1: behaviour 2

q2: +1 (if per user control as TimKh comment)

21 December 2021
kirsten greed
kirsten greed

Menu 2 - less end user training and less confusion being different to Winforms.


21 December 2021
Dave Hesketh (Llamachant Technology)
Dave Hesketh (Llamachant Technology) / DX MVP
I actually really like Option 1 now but I'd be just fine with Option 2 by default.
21 December 2021
CRM-ca8c8c53-0bd0-4e59-98ae-06b1ecacce65
Customer224526
Q1: both
21 December 2021
Martin Brekhof 2
Martin Brekhof

Q1: 1

Q2: +1

21 December 2021
Marc Greiner (DevExpress MVP)
Marc Greiner (DevExpress MVP)

Q1: Behavior 2
There are situations when all or most actions are active.
The spared screen estate of behavior 1 is not worth the potential user trouble.

Q2: DetailView layout customization: +1
This is a very useful tool, for administrators.
It should be possible to prevent end users from using it.
The administrator should be able to store the layout changes in the SharedModelDifferences.


21 December 2021
Bassam Abdelaal
Bassam Abdelaal

Q1 : Menu Behavior 2 , less confusing + no way for user to know what actions are available unless first select a row , so 2 is much better and clear


Q2 : +3 , very nice and much useful for admins and developers who can then store changes in model



21 December 2021
CRM-7a7cc1d6-5ee5-409a-b05c-acef24352bf3
Paul PS

Q1: option1 is better when we have many actions in a screen. please provide both options and let me choose it on each screen. of not possible  just keep the current approach


Q2: there is a major drawback for layout customization by end users that they may play around, mess up the layout, swap the sequence of input incorrectly and it will cause the bad ux and unnecessary issues caused by an impropriate ui. furthermore it will be more difficult to support by phone because we dont see the same ui. this option is not practical for business or enterprise application my idea is there are many things pending such as multicolumn treeview, draggable pivotgrid, pivotchart, etc. i vote -1 for this.

21 December 2021
Sergej Derjabkin
Sergej Derjabkin
Behavior 2, +1
21 December 2021
Dennis (DevExpress)
Dennis (DevExpress)

@TimKh and Paul PS: You can certainly disable this customization globally or per-View using the following options in the Model Editor: Options | LayoutManagerOptions | CustomizationEnabled or DetailView | CustomizationEnabled - such things are always controllable in XAF for different requirements, including yours. You can also disable this customization in code, per user or for all users (thanks to How to: Store the Application Model Differences in the Database). 

I also think that many power users of enterprise apps will disagree with you - this is one of the favorite XAF features among our customers.

We do not plan to support this layout customization for mobile phones. Finally, the "Reset Layout" command is also available.

21 December 2021
Felipe Cruz
RC

Q1: Primarily prefer #2 because of user confusion, but like all, would of course like to have both options. I mean, ideally I would like to have it responsive to screen size perhaps, or force it to be behavior 1 or 2. 


Q2: I would love that, BUT to me it's a low priority compared to bringing other basic existing controls/property editors into XAF Blazor

21 December 2021
Dennis (DevExpress)
Dennis (DevExpress)
@RC: What is on your list (except for the built-in CriteriaPropertyEditor with the visual tab and TreeListEditor)?
21 December 2021
Jacek Kosiński
Jacek Kosiński

I agree with Maritin , the best have both and allow to select prefered.

In my projects the most important is edit in place in data grid


21 December 2021
Yahya
Yahya

Runtime Detail Form Layout Customization is not high priority. Probably best to leave it for a future release.


21 December 2021
Yahya
Yahya

Compared to cosmetic changes, Web API is a much more important game changing feature. Finalising Web API should be a priority.

21 December 2021
aladin lebcir
aladin

Q1: both if possible , and I like to add customisation by user (exemple add layout , field by user and will add automatically in bdd ) 

Q2:+1 

what’s roadmap of XAF for 2022 🤤

21 December 2021
Achmad Mulyadi
Achmad Mulyadi

Q1: Both

Q2: +1 (I wish I can have +100 here)

21 December 2021
CRM-485d2797-a1e9-45d5-93f9-9b63d0659b41
-bitman

Q1: Behavior 2
It would be easier for end-users to see all available actions from the toolbar and will be enabled/disabled based on usage.  As opposed to just figuring it out after pressing the check box from the list.  Less confusing from the get go.


Q2: +1

21 December 2021
Thomas O Loughlin 1
Thomas O Loughlin

Q1: Both if possible - option 1 is great for small screens but can confuse users

Q2 : +1 This is definitely one of the selling points for XAF from an end user perspective 

21 December 2021
Daniel Kmínek
Daniel Kmínek
Q2: +3
21 December 2021
Daniel Kmínek
Daniel Kmínek
what’s roadmap of XAF for 2022 ?
21 December 2021
CRM-47ee9a49-133e-4ce5-8491-07faf9bf6961
Customer107399

Q1:  I prefer Option 2 because the user needs to have all possible actions visible (even if disabled) before using them. As for option 1, the user will not know what actions are there before selecting a row.

Q2: -1. I don't find it a must have feature compared to WEB API feature that leverage XAF into an enterprise level performance.

21 December 2021
Customer65491
Adryan

Question 1: Both. But I prefer option 1

Question 2: +1

21 December 2021
Akin GUNES
Akin GUNES

Menu Behavior 2 and with option to switch 1, if possible set an option based on view from model. 

+ ∞  :) for Runtime Form Customization


 

22 December 2021
CRM-5e796492-b772-42c7-bff6-0df977d7582e
Ivan K

Q1: Both. But what will be with single selection Action if user select many rows?

Q2: It's pretty good for admins to change layout in runtime with saving model differences. But it's not critical feature.

Most waited improvements in 2022:

1. Search with yellow highlight (like in current ASP .NET Grid):

2. Context menu or toolbar analog (preffered) with functions: Column Chooser, Search panel, Group panel, Filter row, Filter builder, Footer like in ASP .NET:


22 December 2021
Alex Miller
Alex Miller

Q1:  Both, if possible. Otherwise behavior #2 to be consistent with the other platforms.

Q2: -1. As long as we can disable it completely I do not mind, but I think DX development time should be spent elsewhere.

22 December 2021
Reinhold Erlacher
Reinhold Erlacher
+1 Runtime Layout Support
22 December 2021
Thomas Vetterling
Thomas Vetterling

Q1:

Please let the developer decide which menu behaviour has to be selected for a ListView


Q2:

+1 :-)

22 December 2021
Merlin
Merlin

Q1 both if possible as menu 1 suits mobile and menu 2 suits desktop.

Q2 +1

22 December 2021
CRM-ca8c8c53-0bd0-4e59-98ae-06b1ecacce65
Customer224526
Q2 => -1
22 December 2021
behdad khoshbin
behdad khoshbin

Both toolbar options

+4

For Blazor UI Lookup Editor, also a find button for large datasets(open the listview screen to search and find item)

23 December 2021
Michael Köster 1
Michael Köster 1

Menu Behavior 2 or both

+1

23 December 2021
Dave Hesketh (Llamachant Technology)
Dave Hesketh (Llamachant Technology) / DX MVP

As Martin mentioned:

"we need to have Actions available with SelectionDependancy Independant - even if an record is selected."

We just ran into this issue as well.

23 December 2021
Demertzian
Demertzian
Q2 seems great. Will this be also supported on Blazor standalone controls?
24 December 2021
Akin GUNES
Akin GUNES
LookupEditor's New and Open Related Record actions were most related features. I juat prefer to control Open Related Record action's target window. Open in Popup windows  or Open in new tab. It would be perfect if we can have 2 action with ability to hide both or any of them. 
24 December 2021
Akin GUNES
Akin GUNES

Ohh, i found a bug in support center :))). My comment is duplicated because i thought that i couldn't click the "Post comment" action and clicked it again before the operation completed. You can delete the duplicate comment.

For the solution;

1. Post Comment action can be disabled when it is clicked.

2. On the server side (and probably at database level) a validation can be work to check duplicates. 


24 December 2021
Stanislaw.Tristan
Stanislaw.Tristan

Q1: Both

Q2: not needed currently

25 December 2021
behdad khoshbin
behdad khoshbin
Blazor TreeView ,Maps and Scheduler are also essential modules
26 December 2021
Bert Stomphorst
Bert Stomphorst

Question 1: doesn't matter for me. Current behavior is mostly ok.
Only when you look at i.e. https://demos.devexpress.com/XAF/BlazorDemo/Employee_ListView_Varied, it's confusing that the filter-actions are hidden when selecting an item in the list.

Question 2: for me it does not add any value. I (and my end-users) prefer consistancy in layout. Personally I think the need of this shows some shortcomings in development to create right UX for relevant scenario's.


More relevant for my usage is XAF Blazor Scheduler. This will make it possible to move some WebForms-projects over to Blazor.

28 December 2021
Andrey_Kucher
Andrey_Kucher

Q1: 2 or both with selection for every view and set default in app settings

Q2: not needed. Really need is listView fields customization: column chooser.

Thanks

28 December 2021
Andrey_Kucher
Andrey_Kucher

Q1: 2 or both with selection for every view and set default in app settings

Q2: not needed. Really need is listView fields customization: column chooser.

Thanks

28 December 2021
Andrey_Kucher
Andrey_Kucher
It is also valuable to support really independency for SelectionIndependentType.Independent. For now I forced to create two actions for no selection and any selection.
28 December 2021
Oliver Gröger
Oliver Gröger

Q1: 2

Q2: +1

28 December 2021
Randy Jean
Randy Jean

Menu behavior = 2 (but 1 option might be good for mobile)

+1 for UI design but very low priority compared to other features/feature parity items

28 December 2021
CRM-5f54cf9c-d8a3-45de-a6cb-8572a6bf8949
Customer151284

Menu behavior = 2

+1 for UI design

28 December 2021
Dennis (DevExpress)
Dennis (DevExpress)

@Everyone: Thank you for your comments - it is very helpful. 

Happy holidays!

29 December 2021
AlexanderCPunkt
Alexander C. (Co-Orga GmbH)

Question 1: both, if it possible

Question 2: +4

Open Details in New tab instead of popup is usefull in some cases


Good Job!

29 December 2021
Engº Bruno Marques
Bruno Marques

Question 1: both, if it possible

Question 2: +1

30 December 2021
Xian
Xian
Question 1: Menu Behavior 2 - a constant layout is extremley important for the UX
Question 2: Not necessary - you can skip this features and use the time for more important things like column chooser, better filter for columns, etc.
31 December 2021
Rubén Duarte
Rubén Duarte

Q1: Option2

Q2: +1


1 January 2022
behdad khoshbin
behdad khoshbin
For windows deployment , single file bundle is also essential , but it doesn't work currently
2 January 2022
Andreas Fasching
Andreas Fasching

I hope my voice still counts :-)

Q1: I hear my customers yell: I don't have a delete button! So slight preference for 2.

Q2: -2

It's a "cool" feature but nobody will use it here. It would only lead to very different screen layouts or broken screen layouts we have to fix. So I would turn this off.

What my users would benefit from immediately is inline batch edit, column customization, footer / summary customization, context menu on table header and footer to customize the grid completely as we have it currently. The ASP.NET and Winforms Devexpress Grids are the swiss army knife to data. This really stands out. The Blazor grid is nothing like that currently. As soon as we have that again go ahead and implement detail view customization.

6 January 2022
Andreas Fasching
Andreas Fasching

To add another aspect to my previous post: I started a XAF Blazor project because that's the future direction but I'm quite certain that I would return to classic ASP.NET XAF again if a new project comes along my way mainly because of the missing customer features in the grid.

I think, some of the features are much cheaper to implement than detail view customization.

6 January 2022
Dennis (DevExpress)
Dennis (DevExpress)
@Andreas Fasching: Notwithstanding the importance of DevExpress Blazor Grid features (produced by a separate team, not the XAF team), I am primarily talking about the features of DevExpress XAF (produced by the XAF team). I hope it is clearer now.
6 January 2022
Chris Royle (LOB)
Chris Royle (LOBS)

@dennis 

Q1. Both would be useful with the ability to switch - perhaps by user/role or by platform - or by customer. 

Q2. I think at this point we could live without this - we'd use Win for our 'power' users and the web for simpler browsing / light editing. 


More important to us, and our users is to be able to add/change/reorganise list views. 


Going back to Q2, I think collapsible groups will be useful to us in Web - but we'd only make use of them if the collapse/expand was data driven/appearance rule driven - i.e. if a field within a group was non-standard we'd want the group expanded. I think we've discussed this before. 


7 January 2022
Andreas Fasching
Andreas Fasching
@Dennis: Thanks for pointing that out! Makes a difference.
8 January 2022
Fernando Ramos Tier2
Fernando Ramos Tier2
Q2: +1 and all points described by Ivan K (very important features to migrate from asp.net webforms and winapp to xaf blazor)
10 January 2022
Peter Majzik
Peter Majzik

No. 1. Menu Behavior 1

first version would be good. our users don't like it when something is greyed out and not enabled, they usually complain why we don't let them click on it. if it's not there, there's nothing to complain about.
of course the best solution is to be able to change the settings of this behaviour.

No.2. 

modifying the user interface on the client side runtime, is a very attractive and appealing feature. but in our experience, in the long run, this is just a problem.
I also advocate that the developers should do something else. e.g. expand the gridview capabilities of blazor

thank you

Peter

15 January 2022
Mario Blatarić
Mario Blatarić

Q1: As Martin said, definitely Behaviour 2 for larger screens (desktop) and Menu Behaviour 1 for smaller screens. 

Problem is, most customers do not perceive nor care about technology change (Blazor in browser instead of desktop app), they will expect same behaviour as before, however - changing device - there you can have different behaviour. 

On desktop, I am certain I will be getting a lot of calls like "Where is my New button?!?" - because they will forget and leave some row checked. 

Q2: +1

My app would benefit a lot from this because different customers have slightly different requirements for data entry forms so we use runtime customisations a lot. 

However, this is not a deal breaker, it is more of cosmetic nature, because different layout or extra fields do not break application, just takes more skipping, so I would not mark this as high priority for me. 

18 January 2022
CRM-c70a1315-0921-450c-b9a3-dbf59f9cfb8a
Alex
kanban board would be great! +1
20 January 2022
Chengwei  Dai
Chengwei Dai

Q1: Both

Q2: +1

20 January 2022

Please login or register to post comments.