I have read and tested a simple case using the v12 documentation. This works fine for extending a class directly and having the custom property available in the view, but it does not seem to be available if the model is inherited by something else.
This could just be Friday brain, but I can't seem to find anything that works.
Scenario:
You have a bunch of block elements with individual Settings, 80% of which inherit the same couple compositions.
You extend the model for the compositions with MyNewProperty to clean up some repeat code.
MyNewProperty is not available for any of the Settings Models which inherit that composition.
What is the appropriate way to accomplish something simple like the example in the documentation, but have it inherited by models that share the same IInterface?
With fresh Monday morning brain I at least realized when writing up the View I could just cast the Model.Settings as the IInterface instead of the actual Settings model and be able to access the custom property... But obviously that's not perfect when the component Settings could have its own properties or other compositions to access.
Still puzzling over the proper way to go about accessing the custom property inherited from compositions. Or achieve the end goal in another way that is appropriate. Would love any random ideas <3
Edit:
My current solution is just having multiple casts of the settings each pointed toward the required IInterface extended classes so that I can access the composed custom properties. Having re-read the documentation I think I misinterpreted the initial 'bad practice' example with model inheritance and thought it was bad bad bad to have multiple model casts.
Example:
(extension class)
public partial interface IBackground
{
public string TestProp
{
get
{
// computed/transformed value
}
}
}
(in view)
if (Model.Settings is not ComponentSettings settings) { return; }
var bgSettings = Model.Settings as IBackground;
...
// then can reference the TestProp in the view as strongly typed
// and save myself writing repeat snippets in a dozen places
I found some stack exchange talk about having to use Route Hijacking for this. That seems overkill for such simple value transformations like the documentation example.
Extend Model of a Composition so those that inherit it, inherit the CustomProperty
I have read and tested a simple case using the v12 documentation. This works fine for extending a class directly and having the custom property available in the view, but it does not seem to be available if the model is inherited by something else.
This could just be Friday brain, but I can't seem to find anything that works.
Scenario: You have a bunch of block elements with individual Settings, 80% of which inherit the same couple compositions.
You extend the model for the compositions with MyNewProperty to clean up some repeat code.
MyNewProperty is not available for any of the Settings Models which inherit that composition.
What is the appropriate way to accomplish something simple like the example in the documentation, but have it inherited by models that share the same IInterface?
With fresh Monday morning brain I at least realized when writing up the View I could just cast the Model.Settings as the IInterface instead of the actual Settings model and be able to access the custom property... But obviously that's not perfect when the component Settings could have its own properties or other compositions to access.
Still puzzling over the proper way to go about accessing the custom property inherited from compositions. Or achieve the end goal in another way that is appropriate. Would love any random ideas <3
Edit:
My current solution is just having multiple casts of the settings each pointed toward the required IInterface extended classes so that I can access the composed custom properties. Having re-read the documentation I think I misinterpreted the initial 'bad practice' example with model inheritance and thought it was bad bad bad to have multiple model casts.
Example:
(extension class)
(in view)
I found some stack exchange talk about having to use Route Hijacking for this. That seems overkill for such simple value transformations like the documentation example.
is working on a reply...