Reloading a property

Reloading a property

Old forum URL: forums.lhotka.net/forums/t/7505.aspx


rfcdejong posted on Monday, August 24, 2009

For us it's very common to reload a property (child list), we didn't find a clear way reloading a property. I couldn't find FieldManager.ClearField or FieldManager.ReloadField or FieldManager.DeleteField. Searching it into another corner: LoadProperty with null doesn't work and if it did it feels like an hack.

What we currently do is having lazy loaded property's and let them reload based on a private bool.

RockfordLhotka replied on Monday, August 24, 2009

Can you describe the scenario you are talking about, as I don't understand what you are trying to accomplish and why?

rfcdejong replied on Tuesday, August 25, 2009

RockfordLhotka:
Can you describe the scenario you are talking about, as I don't understand what you are trying to accomplish and why?

For example having an financial application where a customer is selecting the way he wants to pay:

In a field the customer has to select a type of payment, after selecting the paymenttype there is a "OnPropertyChange" event on the paymenttype property.
When it's a specific paymenttype value then another (lazy loaded property) named banklist (with child bankinfolist bo) has to be reloaded since the paymenttype changed and it's dependend on it.

We'll have alot of property dependent lists where the values of a combobox has to be reloaded after selecting another value in another combobox. Where the other combobox value will be passed as criteria.

It would be very nice if the FieldManager.ClearField / RemoveField or something comes available in a future version.

RockfordLhotka replied on Wednesday, August 26, 2009

I added this to the wish list

http://www.lhotka.net/cslabugs/edit_bug.aspx?id=540

rfcdejong replied on Tuesday, January 05, 2010

This is more and more becomming an hack for several of our developers. I might try to impliment this in our abstractionlayer but it'll require access to the fieldmanager's data. It would be alot easier to impliment this in csla, perhaps i'll modify csla code :)

But until now i focussed on not modifying csla code so we've a low level of risk in upgrading to a new version.

I see Issue ID 540 changed 49 days ago from priority "none" to priority "med". There are also several posts about refreshing on this forum, clearing a managed property so it can be reloaded is one step.

RockfordLhotka replied on Tuesday, January 05, 2010

I've been reviewing the backlog over the past few weeks - consolidating and reprioritizing as I plan for CSLA 4. That's why the priority changed to medium - this is basically on the short list of things to do in CSLA 4.

rfcdejong replied on Monday, November 12, 2012

Any update on this wish?
It has been awhile and we have still the wish to make it possible to remove a field so it will be forced into reloading.

JonnyBee replied on Monday, November 12, 2012

Hi,

I did look into this item and got into difficulties with the N-Level Undo - which requires access to the FieldInfo.

IE: The Undo would fail to reset the field if the Property backing field is null ==> so for all practical purposes - you could only be allowed to call ClearField/RemoveField when EditLevel is 0.

I believe this would probably not solve your issues which would be when the object is DataBound.

One could argue that the BusinessRules will now allow you to create rules (CsLA 4.2 and later)  that only runs on the client when the user edits/changes a value and that your app should rather look into a cache/run async call and set the appropriate list into the BO. This can be accomplished by setting :

This is (IMO) a better solution than having a rule call ClearField/RemoveField and then databinding makes a new async load.

The other solution would be to add a new property to the FieldInfo to indicate that this fieldvalue is now Empty (which I am hesitant to do as it will add more payload to transfers and memory usage).

rfcdejong replied on Monday, November 12, 2012

My colleagues are trying to avoid busines rules just to speed up or something, i don't know why. For such simple things it's often too easy just to define a private bool and read that bool in the getter if there is a refresh needed.

The idea of a generic rule might be worth a shot. I could create a client-only RefreshPropertyRule that executes the lazy loaded lambda assignment when CheckPropertyRules(MyListProperty) is being called. 


PS: Is it possible to execute a specific rule? Not just any rule defined on the property..
Something like ExecuteRule("MyRefreshRule") or ExecuteRule(r => r.Name == "MyRefreshRule")

JonnyBee replied on Monday, November 12, 2012

No, sorry.It really doesn't make any sense to the rule engine to offer that type of functionality. When a property is changed - all rules for that property must be rechecked in correct order (read Priority).

But as I wrote in the previous post - you can restrict rules from running in a certain context.

You should be able to write a general client side refresh rule with a lambda fetch assignment  (but I haven't tried to do that myself) so please post if you are successful.

rsbaker0 replied on Monday, August 24, 2009

I have a similar scenario and LoadProperty with null works fine, at least as long as the child property is an object versus a value type. FieldManager.FieldExists will still return true, but the actual property value will be null. We reload on the next property Get if either of these conditions is true.

JonnyBee replied on Monday, August 24, 2009

Hi,

We had the same requirement with a large customer object with lazy loaded properties (lists) that during a Save needs to remove/delete several managed field.

The purpose is to use only FieldManager.FieldExists(...) to determine whether field needs to lazyload or return existing object.

It would be nice to ha both
FieldManager.RemoveField(propertDesciptor)    and
FieldManager.RemoveAllFields()

( I ended up making the changes to FieldManager in our internal version of Csla)

/jonnybee





Copyright (c) Marimer LLC