You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should add a new attached property FormControls.Enabled which could be applied to any HTML element, and all form controls could be disabled using this property, so it could be very easy to disable the whole form at once.
If both FormControls.Enabled and the Enabled property on the controls is set, the Enabled takes the precendence, because we may need to disable the whole form except of one field which should be enabled all the time.
We should review all form controls because now there will be a difference between not setting the Enabled property (which means take the default from FormControls.Enabled) and setting it to true, false or a binding, which will have the priority.
Also, maybe we could support this on a DotvvmProperty level, because this is basically an extended behavior of the default value - we are saying "if this property is not set, use this second property to determine the value (which wil be set, or will have its own default value)".
Maybe it would be just enough to check whether the defeultValue is not a dependency property, and if so, just call GetValue on it.
The text was updated successfully, but these errors were encountered:
tomasherceg
changed the title
FormControls.Enabled attached property should allow inheritance
FormControls.Enabled attached property with inheritance to allow disabling the whole form at once
Jan 1, 2017
It is actually "supported" by DotvvmProperty, you can quite easily extend it and override GetValue and IsSet methods ;)
The main problem IMHO is, that bindings are not very well supported in inherited properties. When you set a binding to property that will be used in different DataContext, it will be incorrect. I will try to address this issue in rewrite of binding translation.
I don't want to rewrite the GetValue, I'd like some easier way.
I quite like the idea of setting DefaultValue which is object to another DotvvmProperty.
Because it would require only a very tiny change in the controls which currently have the Enabled property, and we can make use of the mechanism on many places in the framework.
Would it be difficult to reflect this in the binding translator?
I just wanted to demonstrate that it is pretty easy to do for the DotvvmProperty part :), I'd also put this logic inside core DotvvmProperty, it can be quite useful in other places.
The problem with bindings is that they are compiler for fixed DataContext so they can't be transfered to different control. It is one of the things I'm trying to solve in bindingSystemRefactoring branch - it will allow you to replace the knockout $context parameter with $parentContexts (I forgot to put issue for that on github, working on it now, sorry).
We should add a new attached property
FormControls.Enabled
which could be applied to any HTML element, and all form controls could be disabled using this property, so it could be very easy to disable the whole form at once.If both
FormControls.Enabled
and theEnabled
property on the controls is set, theEnabled
takes the precendence, because we may need to disable the whole form except of one field which should be enabled all the time.We should review all form controls because now there will be a difference between not setting the
Enabled
property (which means take the default fromFormControls.Enabled
) and setting it totrue
,false
or a binding, which will have the priority.Also, maybe we could support this on a DotvvmProperty level, because this is basically an extended behavior of the default value - we are saying "if this property is not set, use this second property to determine the value (which wil be set, or will have its own default value)".
Maybe it would be just enough to check whether the defeultValue is not a dependency property, and if so, just call
GetValue
on it.The text was updated successfully, but these errors were encountered: