Hi,
I am looking a the clsa framework and am wondering what expereience folks have had using csla with the dev express suite. we have committed to using dev express suite for our reports, web development and windows development...
any feedback on you expereience would be appreciated..
Dennis
We are using this combination, with some success (and some quirks).
We find with the DevExpress XtraGrid, the act of moving from the parent row to a child row (e.g. in a master-detail list setup) that it calls ApplyEdit on the parent, which presents a problem with respect to CSLA and N-level undo, but otherwise it seems to work OK.
Another minor (non-CSLA) beef is that the programming model for the DevExpress web controls is entirely different from the WinForms side. Of course, they have to work differently, but it's like they are products from two different companies.
FatPigeon:
I am interested in your use of DevExpress XtraGrid and the problem that is calls an ApplyEdit on moving from a parent to a child row. There is a similar problem with the WinForms DataGridView.What do you do about this? What is bound to the parent - an EditableRootListBase or a BusinessListBase?
In our case, the "master" list bound to the grid itself is EditableRootListBase, and the child detail view is BusinessListBase.
When you click from the master row to one of the child detail rows, the parent is saved and then you aren't even editing any more (e.g. editlevel is zero). Ugh.
My current "solution" is that I don't allow editing of the details -- not optimal by any means. I keep hoping for a fix somewhere.
Maybe Rocky will wade in with his opinion on this issue.
In our case, the "master" list bound to the grid itself is EditableRootListBase, and the child detail view is BusinessListBase.
When you click from the master row to one of the child detail rows, the parent is saved and then you aren't even editing any more (e.g. editlevel is zero). Ugh.
My current "solution" is that I don't allow editing of the details -- not optimal by any means. I keep hoping for a fix somewhere.
Maybe Rocky will wade in with his opinion on this issue.
I designed ERLB for one very narrow scenario: editing a list of root objects in a grid, where the data binding events trigger immediate insert/update/delete operations. That is the only scenario ERLB is designed to support.
The fact that data binding triggers an insert/update when focus changes out of the grid control is outside my control. For better or worse, ERLB is acting exactly as it is designed in that scenario, because it is doing exactly what data binding has told it to do (namely to save the data).
If you can find a way by which ERLB could be enhanced to somehow know to ignore the data binding events in the case that they were sent because focus changed to a child grid, and then react (presumably) to the events from the child grid to indicate that the user moved off that grid to somewhere else (one would assume thus committing the changes?) I am happy to consider such alterations.
I don't see any clear way by which that can be done, short of writing your own grid - ha! :)
The only alternative I could see that would work in reality, is to allow ERLB to totally ignore data binding. In that case you'd have to write code in the UI to handle the various bindingsource and/or grid events so you could manually tell ERLB when to add a new item, insert/update the existing item or remove the exising item.
Essentially you'd have to develop your own replacement data binding protocol for interaction between the UI and ERLB.
If that sounds practical to you, I suggest you prototype it by overriding the SaveItem() method to make it do nothing unless you call it explicitly. That'll allow data binding to still "work", but it will never trigger an automatic insert/update/delete - you'll have to do that from your UI code manually.
...The fact that data binding triggers an insert/update when focus changes out of the grid control is outside my control. For better or worse, ERLB is acting exactly as it is designed in that scenario, because it is doing exactly what data binding has told it to do (namely to save the data).
...
I'm not sure if this is exacltly the problem.
The XtraGrid supports a hierarchical mode where (+) signs are displayed next to rows for objects that have a public IList property. When you click on the +, the grid expands the children inline as indented rows underneath the parent row.
At this point, there has been no focus change (and no ApplyEdit). However, as soon as you move the selection from the parent row to one of it's children, it saves the parent just as if it had moved to another parent row.
I can look at this again, but I'm pretty sure that BeginEdit/ApplyEdit are being called on the child object, but since the grid as already assumed you've left the object responsible for actually doing the saving (e.g. the root), I'm not sure how to make use of this.
Anyway, with regard to the original post, the grid works great for editing as long as you don't use the hierachical mode. Objects are automatically saved as you move from row to row, and DevExpress has an IDXDataErrorInfo interface you can implement so that broken rules display right next to the responsible cells.
At this point, there has been no focus change (and no ApplyEdit). However, as soon as you move the selection from the parent row to one of it's children, it saves the parent just as if it had moved to another parent row.
I can look at this again, but I'm pretty sure that BeginEdit/ApplyEdit are being called on the child object, but since the grid as already assumed you've left the object responsible for actually doing the saving (e.g. the root), I'm not sure how to make use of this.
This is what I am saying. When the user moves to the detail area, the grid control is sending the data binding signal that indicates the user has left the parent row. That data binding signal is what ERLB uses to know that it should commit the changes to the row.
Since there are no other data binding signals, that's all I have to work with.
I don't know that it is a bug with the grid - it is almost certainly a design choice on their part - but it obviously precludes using ERLB, at least in an automated manner, because there's not some higher level data binding signal for them or me to use.
All ERLB can do is respond to signals from data binding. I don't know what else it could do?
And if data binding only has limited signals (user left row, user deleted row), then that's all I can respond to.
And if the grid control insists on sending the 'user left row' signal when the user moves to the detail level, I don't see what ERLB would do differently? Essentially the grid is lying - saying the user left the row when they didn't really - but this behavior most closely matches a parent-child grid setup with the DataGrid, and so I'm sure it is a concious choice on their part to get similarity between the two types of grid.
So the only real answer is what I said before - override SaveItem() so the 'user left row' signal can be ignored. Then in the UI, hook some event on the grid control that really does indicate the user left the row and manually call a method on ERLB to do the save.
Thanks for the insight. I'd been toying with the idea of disabling IEditableObject, but taking over the SaveItem() processing is a good idea also.
I already have one or two other use cases where I had turned SaveItem() into a nop and was doing the transaction processing elsewhere, so this will fit right in.
Copyright (c) Marimer LLC