I have a situation where I would like to remove or invalidate objects from the FieldManager. I'm not aware how people handle this but I am open to the best solution :).
public Diagnosi DiagnosiMemberByPrincipalDiagnosisID
The user may change the PrincipalDiagnosisID to point to a different record. In this case, the FieldManager Object needs to be marked as dirty so it can be reloaded. I'm thinking the best place for this would be in the Child_Update.
// Update foreign keys values. This code will update the values passed in from the parent only if no errors occurred after executing the query.
if (patient != null && patient.PatientID != this.PatientID)
//Mark DiagnosiMemberByPrincipalDiagnosisID As Dirty via FieldManager....
I am interested too in how people refresh the child member collection, or how to invalidate the member.
Thanks in advance.
At this time CSLA can do a rollback (CancelEdit) to a null value. It doesn't track other object reference changes for single child objects.
The simplest solution is to use a BLB child, because BLB does track reference changes (moving older ones to DeletedList for deletion), and restoring those objects in the case of a CancelEdit.
Do you have an example of this for both a BLB child and a BB Child?
Example of what Blake?
A BLB does what it does - it is a self-tracking entity.
If your parent object has a child property (BLB or BB) and you change the reference it holds, that isn't subject to rollback - there's no list maintained of previous values - with the exception of null.
The behavior is very consistent.
If you want more complex undo tracking, store your child objects inside a BLB and keep the parent's reference to that BLB consistent.
I think u want the same as i want. There is already an issue for this, but it's not in progress yet.
See my post: http://forums.lhotka.net/forums/p/7505/35738.aspx#35738
or the issue directly: http://www.lhotka.net/cslabugs/edit_bug.aspx?id=540
Raymond de Jong
I looked into this issue for CSLA4 this spring but eventually gave up. I got some weird exceptions in the Undo mechanism when a field had been reset (ie null) and I was not able to debug/fix it within the timeframe I could use on this issue.
Thanks guys, that is exactly what I am trying to do. @JonnyBee, I spent 2-3 hours trying to figure this out and its a real pita... Any ETA on this feature or who wants to work on it?
That's true, this is non-trivial.
Consider what we're talking about.
A FieldData subclass that does everything BLB does. So when a reference changes, the old value is marked for deletion and put into a DeletedList.
This means inventing a few new things:
I'd hoped to get this into CSLA 4, but we ran out of time.
I sure won't do this in a point release (like 4.0.x) because the changes here are major, and the odds of them having some effect on existing behaviors is quite high. So the earliest this could happen is 4.1.
I have a test case for this that I would be willing to help test this in the future.
Copyright (c) Marimer LLC