UmbracoProperties prefix reuse with a similar base class
Hi folks,
I've gone through a number of iterations with this problem and can't seem to find an agreeable solution.
I have a really simply basic class I'm using in a lot of different places with the content being altered by the UmbracoPropertiesAttribute with prefix.
My interface
public interface IBasicContentViewModel {
public string Title { get; set; }
public HtmlString Content { get; set; }
public bool HasContent { get; }
}
My basic implementation
public class BasicContentViewModel : IBasicContentViewModel {
[UmbracoProperty(AltPropertyAlias = "Name")]
public string Title { get; set; }
[UmbracoProperty]
public HtmlString Content { get; set; }
[DittoIgnore]
public bool HasContent { get { return Content != null && string.IsNullOrWhiteSpace(Content.ToString()) == false; } }
}
This is then inherited by specific use viewmodel.
[UmbracoProperties(Prefix = "signUpComplete_")]
public class SignUpCompleteContentViewModel : BasicContentViewModel {
}
Or...
[UmbracoProperties(Prefix = "signUpForm_")]
public class SignUpFormContentViewModel : BasicContentViewModel {
}
The content all belongs to the same page separated by tabs (hence the prefix) then an Controller action (Alt Template) will the Dittofy the right view model.
The reason this doesn't work is the property which is getting value resolved by UmbracoPropertyAttribute is on the BasicContentViewModel not the actual class being Dittofied. So when the UmbracoPropertyAttribute looks for a prefix it won't find the UmbracoPropertiesAttribute and therefore won't find the value. I've done some tests with a basic ValueResolver and sure enough the UmbracoPropertiesAttribute is null.
This doesn't seem like a problem that's easy to resolve as doing a watch the Context from that test at no point does the property mention the actual calling type just the type of the class which the property belongs too.
My original solution was to use an interface on every class where I'd want a prefix and then implement the UmbracoPropertyAttributes but that led to a lot of repetition. I basically need a situation where
I'm trying to be as DRY as possible here but it seems I might not be successful.
Hi Lee,
This is definitely the case. The line you're looking for are these ones (edit: just discovered multiline highlighting by URL in GitHub!).
this.Context.PropertyDescriptor.ComponentType
Resolves to BasicContentViewModel rather than SignUpCompleteContentViewModel because the property being resolved is on BasicContentViewModel.
Yes, I've heard you're all about the unit tests these days. That's great news :)
Also, to make this more challenging I'd require a solution which works with the vanilla conversion method (model.Content.As<T>()) as I'm using DitFlo, which is for the most part is totally ace.
I've written a unit-test and can reproduce the exact same scenario. You're spot on with the cause of this issue. I'm not sure exactly how to fix it yet.
We somehow need to get the this.Context.PropertyDescriptor to be that of the derived type (SignUpFormContentViewModel) rather than BasicContentViewModel.
I'll have a think.
Can you do me a favour and post this up on the GitHub issues... doesn't need a big description, just a link to this forum post is cool.
UmbracoProperties prefix reuse with a similar base class
Hi folks,
I've gone through a number of iterations with this problem and can't seem to find an agreeable solution.
I have a really simply basic class I'm using in a lot of different places with the content being altered by the
UmbracoPropertiesAttribute
withprefix
.My interface
My basic implementation
This is then inherited by specific use viewmodel.
Or...
The content all belongs to the same page separated by tabs (hence the prefix) then an Controller action (Alt Template) will the Dittofy the right view model.
The reason this doesn't work is the property which is getting value resolved by
UmbracoPropertyAttribute
is on theBasicContentViewModel
not the actual class being Dittofied. So when theUmbracoPropertyAttribute
looks for a prefix it won't find theUmbracoPropertiesAttribute
and therefore won't find the value. I've done some tests with a basic ValueResolver and sure enough the UmbracoPropertiesAttribute is null.This doesn't seem like a problem that's easy to resolve as doing a watch the Context from that test at no point does the property mention the actual calling type just the type of the class which the property belongs too.
My original solution was to use an interface on every class where I'd want a prefix and then implement the
UmbracoPropertyAttribute
s but that led to a lot of repetition. I basically need a situation whereI'm trying to be as DRY as possible here but it seems I might not be successful.
Thanks,
Jamie
Hi Jamie,
I've read over this, just trying to digest the idea.
So on your DocType you have these properties...?
signUpForm_title
(and/orsignUpForm_name
)signUpForm_content
signUpComplete_title
(and/orsignUpComplete_name
)signUpComplete_content
Then when you do...
... the properties aren't being mapped?
With the
UmbracoPropertiesAttribute
being null, I'd need to check that code again.I think it'd be good to have a unit-test (in Ditto) for this scenario, (I'm all about the unit-tests these days!) ;-)
Cheers,
- Lee
Hi Lee,
This is definitely the case. The line you're looking for are these ones (edit: just discovered multiline highlighting by URL in GitHub!).
Resolves to
BasicContentViewModel
rather thanSignUpCompleteContentViewModel
because the property being resolved is onBasicContentViewModel
.Yes, I've heard you're all about the unit tests these days. That's great news :)
Also, to make this more challenging I'd require a solution which works with the vanilla conversion method (
model.Content.As<T>()
) as I'm using DitFlo, which is for the most part is totally ace.Thanks,
Jamie
I'll take a look.
re: unit tests ... still feels like I have no idea what I'm doing... keep on hacking away until all the lights are green! ;-)
Hey Jamie,
I've written a unit-test and can reproduce the exact same scenario. You're spot on with the cause of this issue. I'm not sure exactly how to fix it yet.
We somehow need to get the
this.Context.PropertyDescriptor
to be that of the derived type (SignUpFormContentViewModel
) rather thanBasicContentViewModel
.I'll have a think.
Can you do me a favour and post this up on the GitHub issues... doesn't need a big description, just a link to this forum post is cool.
Thanks,
- Lee
Issue created! I'll leave this open until we have a resolution. For now I've resorted to the not so DRY option of an interface.
is working on a reply...