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.
I added this to the wish list
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.
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).
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")
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.
Copyright (c) Marimer LLC