Refer to the How to prevent a DetailView from being shown when a User double clicks or presses the Enter key on a record in a ListView example for a solution that uses the ListViewProcessCurrentObjectController.CustomProcessSelectedItem event.
Proposed Solution:
Provide a new ShowDetailView attribute in the ListView node schema
or make the DetailViewID attribute of the ListView node calculable and make it possible not to show DetailView if the DetailViewID attribute is empty.
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hello guys,
I would ask your feedback on the functionality described in this request.
While it seems that everyone wants to have a built-in property on the ListView (e.g., ShowDetailView or even ShowDetailViewCriteria), it is not quite clear whether it should be overridden by end-users or only by developers.
For instance, when you plan to limit your end-users to editing data through the ListView only, are the primary reasons behind this providing security (e.g., hiding unwanted application features or sensitive data)? I am asking these questions because having set a property in the application model is not that safe (e.g., a user can change this via the Model Editor or edit the XAFML markup directly, unless all the model settings are not in the database), while the opposite is true when enforcing the same rule in a controller or using the security module.
I am trying to learn more about your common business requirements and so I would appreciate answers to the following questions:
Thank you for all your feedback in advance.
I can only answer to question 1.
There are sometimes situations where i want to show the end user a list of businessobjects in readonly ListView(for instance fo selection purposes). But the end user shouldnt be able to see 'more' detail information on that businessobject. (Imagine a CRM project, wher users should see all 'invoices' but shouldnt see or open the 'invoice').
So for me it is a 'security' feature.
Yours Thomas
Thanks for the info, Thomas. Then, as I mentioned above, it is best not to use this approach to accomplish your task, because end-users can bypass such a "security". Instead, please use the Security module to prevent access to certain data types or members.
Sometimes, I just want the user to edit data in a grid rather than a detail view. This happens quite often. I set the Editable property of the listview to true and it works perfectly. I don't even bother creating a detail view for my object as I know it will always be edited in the grid.
So I don't want the user to be able to open the detail view, I just want him to edit data in the listview.
Anyway, as I can imagine the use of a ShowDetailViewCriteria, I've never met such a scenario. But this could be usefull if some of the item in the list are more complex than other and need to be edited in a detail view. But in this case, I guess that the simple objects could also be edited in the detail view … So for me, the ShowDetailView property is enough. And I can always create a controller to enable or disable the detail view for certain lines.
In the same time, should also make it easier with the Web Detail view.
Point #1 -Currently, if you want - in the XAF Web - to open the DetailView in Edit Mode, you can achieve it only with controller code.
Point #2 Currently, if you want to have the XAF Web DetailView show the One2Many (you have to write special code (((ShowViewStrategy)base.ShowViewStrategy).CollectionsEditMode =ViewEditMode.Edit;). see http://documentation.devexpress.com/#xaf/CustomDocument3230
Those are common options. it is a good idea to have simple attributes for these TRIVIAL staff !
The most common situation in which I do not want a detail view opened is when the list view is already in ListViewAndDetailView mode and the embedded detail view is editable. Most of the time this means I am already providing the user with the ability to edit what they need to edit and opening a detail view is just confusing.
For me the same - most common scenarios are
a) View is ListViewAndDetailview, and I want to ensure edit & new can only be done in embedded detail view
b) Open a complete custom view, based on some property of the selected object (see Q331738)
c) Editing only in ListView
Thanks for the feedback, guys. As far as I understand from your answers, there is no real problem to accomplish all those tasks using the solution I highlighted in my question #2, right?
I would prefer attribute in listview. This way the detailview can ne easily opened from another listview.
I use this a lot in PopupWindowActions. It was opening detail views where instead it should have just selected the items for some reason so that's where I prevent it.
@Reinhold: what about the security aspect of preventing this via the application model I described above? Also, are there any problems with the CustomProcessSelectedItem event (see my questions #1-2 for more details)?
IMO if someone wants to prevent a user to see particular fields, this should be done via SecuritySystem. Else you need to block Columnchooser, Report and so on. This is not a good concept
@Reinhold: Exactly! That's why I am so sceptical about the attribute in the application model. People will start using it inappropriately for tasks that ideally should be solved by the security system.
ah now I get, what you wanted to say. Hm, you maybe right. But in the cases I use this Feature, i just want to prevent user to open a separate detailview, when listview.mode is Master/Detail. Because this mode is much faster, when program is used in WAN.
Nice sulution. Thanks Dennis!
Ist not always about security Dennis - i use this often in nonpersistent listviews - or in editable listview - because usually users double click on the row and so an detailview opens which i want to prevent…
Yes, I think this common scenarios should work out of the box. On the other side I understand you don't want to clutter the app-model with to much noise. But what about making an extra modul for this kind of request (there are more topics similar to this)?
@Dennis wrote: "Exactly! That's why I am so sceptical about the attribute in the application model. People will start using it inappropriately for tasks that ideally should be solved by the security system."
That is true, but it is not an argument per se, Conditional Appearance can also be abused for security purposes…
I still would prefer your proposed solution #2:
Make the DetailViewID attribute of the ListView node calculable and make it possible not to show DetailView if the DetailViewID attribute is empty.
Thanks for the feedback, Robert. We also think that #2 would be a golden mean here.
Oh yeah, I also use this a lot for nonpersistent objects like Martin does. Never for security.
> Make the DetailViewID attribute of the ListView node calculable and make it possible not to show DetailView if the DetailViewID attribute is empty.
@Dennis: Is this implemented now or not?
@Robert: No, this ticket is still marked as Active.
Hi
vote for this:)
I vote for an attribute for this, too (or some switch in the model editor). There are times where I want a read-only or editable grid and don't want to just "switch off" the detail option without implementing via security. Or can't we just select "none" for the DetailView on the ListView itself?