Search This Blog

Tuesday, March 17, 2015

Corrected Save & Close Action behavior on the Web in v15.1

I wanted to inform you of a small improvement we made last week in response to this customer's request in the Support Center:
This was requested by more than a dozen of users who previously had to implement a custom ViewController like the one from this tutorial. The reason for this change was that end-users sometimes got confused after a command that was supposed to close the editing form, actually navigated you to a readonly form instead...
Technically, this legacy behavior remained from the old times when it was not possible to show collection properties in the Edit mode of the DetailView. At that time, the Save & Close Action intentionally switched to the View (readonly) mode by default and this switching was required right after adding a new object, because you could only customize these collections in the View mode. Since displaying collection properties in the Edit mode of the DetailView is now the default behavior of new projects created using the XAF solution wizard, the older behavior no longer makes sense.



Let me restate the behavior of the Save & Close Action in v15.1 and ask you opinion on it:


1. If the DetailView was invoked from a nested ListView, Save & Close will save the changes and close that DetailView.

2. If the DetailView was first opened in the View mode from a root ListView, then switched to the Edit mode by an end-user via the Edit Action, then Save & Close will save the changes and return you back to the View mode instead of closing and showing the source ListView.
3. If the DetailView was opened for the newly created object, then Save & Close will save the changes and 

    3.1. Close the DetailView if CollectionsEditMode == Edit (default)
OR 
    3.2. Return you back to the View mode instead of closing if if CollectionsEditMode == View.

I am eagerly looking forward to hearing your opinions on this change, especially on point #2, which you may want to change (= close the DetailView in this case as well).

9 comments:

  1. Hello,

    About point #2. I think the DetailView must be closed no matter how it was invoked.
    If not, it's not an improvment for me at all.

    ReplyDelete
    Replies
    1. Thanks for your feedback, pbot84. We will take it into account. The improvement for you now is that the new version will close the DetailView when a new object is created.

      Delete
    2. "The improvement for you now is that the new version will close the DetailView when a new object is created."
      Im my previous what I wanted to say that scenario in point #2 it's not improvement :)

      Delete
  2. Thanks for your update. We have not touched #2 and this behavior is inherited from the current version. #3 is what was improved here.

    ReplyDelete
    Replies
    1. The point #2 is important for me. Please consider closing the DetailView.

      P.S.
      Why such posts are not in DX blogs to hit a larger community?
      https://community.devexpress.com/blogs/

      Delete
  3. I appreciate your feedback, thanks.

    P.S.
    I started my personal blog for more often and informal posting of anynews related to our frameworks, while our official team blog is used for larger announcements like What's New in the next major release or other things like that.
    Taking into account that this blog is re-translated into our developers groups in social networks, I do not think we have any problems with hitting the community.Also, it is important to remember that there are other DevExpress users who are not using XAF and they may be not very happy seeing only XAF news in their blogs feed.

    ReplyDelete
  4. Looking at the screenshots, I guess we shouldn't expect a revolutionary html 5 version of the XAF Web UI in 15.1 then Dennis ?

    ReplyDelete
    Replies
    1. Chris: I used the latest 14.2 version to make these screenshots just to demonstrate the Action I was talking about.

      Delete