IPropertyEditorValueConverter vs IRazorDataTypeModel

Sett 186 ganger
Hopp til første uleste melding

Lee Kelleher

ulest,
8. nov. 2012, 05:46:5208.11.2012
til umbra...@googlegroups.com
(Guess these questions are targeted at Shannon) :-)

Recently found out about the new "IPropertyEditorValueConverter" interface for v4.10 - wondering if there is any overlap with the existing "IRazorDataTypeModel"?

I assume that "IPropertyEditorValueConverter" is for use with the new (MVC) View engine, whereas "IRazorDataTypeModel" is for the Razor macros?

I haven't digged deep into the 4.10 code (yet) ... wondering if there was a way to reuse existing "IRazorDataTypeModel" converters? (e.g. uComponents has a bunch of them already)


As an aside, should we include a native converter for the core's MNTP? (we already have one for uComponents which can be ported over)

Thanks,
- Lee

Shannon Deminick

ulest,
8. nov. 2012, 18:41:0308.11.2012
til umbra...@googlegroups.com
Hey lee, you are correct in seeing that these two things are similar (and yes, one is for MVC and one is for razor data types) however they are not the same. There are 2 things in razor macros that should be one: IRazorDataTypeModels and RazorDataTypeModelStaticMapping. There should also be zero reason why we have RazorDataTypeModelStaticMapping as a configuration section and after discussing this with Gareth he also agrees. This is why we have a new IPropertyEditorValueConverter which is structured correctly.

On to the next issue... IPropertyEditorValueConverter exists in the Core project because it is a Core type (not necessarily a web type). The razor macros assembly can reference Core but not vise versa. The other issue is that IPropertyEditorValueConverter is not the same as IRazorDataTypeModel's its the same as the combination of IRazorDataTypeModels + RazorDataTypeModelStaticMappings. Eventually one day far far away we'll be obsoleting the entire razor macros assembly, we'll create a new razor macro with a new engine that has all of the same syntax, classes, etc... that we use in MVC. 

We also need to get the IPropertyEditorValueConverters to work in the non-dynamic access way when using the GetPropertyValue methods when using the strongly typed syntax in MVC.

So to answer your question, I'm not really sure of any way that you would be able to create a wrapper because RazorDataTypeModelStaticMapping relies on config, the other reason is that the IPropertyEditorValueConverter doesn't support targetting things by the 'CurrentNodeId'... because there should be zero reason to have to do this, the conversion should always be based solely on a PropertyEditor, however just to be ultra flexible we are still supporting docTypeAlias and propertyTypeAlias targeting but I highly highly doubt anyone would or should use these. If someone wants to change the value of a PropertyEditor's result based on a CurrentNodeId, then IMO it should be manually changed on that template, not at a higher abstracted level that is very hidden.

Lee Kelleher

ulest,
9. nov. 2012, 05:28:1209.11.2012
til umbra...@googlegroups.com
Thanks Shannon!

So it's safe to say IPropertyEditorValueConverter supersedes (IRazorDataTypeModels + RazorDataTypeModelStaticMapping)?  Ace!

My concern was that if package devs (yep, wearing my uComponents hat again) were to also support IPropertyEditorValueConverter, would that be the "best practice"? (or is that too soon to say?)

Cheers,
- Lee



--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To post to this group, send email to umbra...@googlegroups.com.
To unsubscribe from this group, send email to umbraco-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/umbraco-dev/-/abSDOMZWjIoJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Shannon Deminick

ulest,
9. nov. 2012, 09:25:5209.11.2012
til umbra...@googlegroups.com
You can easily support both an IPropertyEditorValueConverter and an IRazorDataType, you just need to implement both interfaces. The static mapping stuff is a different story all together and requires config changes which shouldn't have been necessary, this is another reason they will be phased out.

jbr...@gmail.com

ulest,
12. nov. 2012, 09:06:5912.11.2012
til umbra...@googlegroups.com
If you need an example I created 2 versions for DAMP: http://our.umbraco.org/projects/backoffice-extensions/damp-razor-model. I tested both versions in 1 install and it works without any problems. So you can have IPropertyEditorValueConverter for the "new" Razor and IRazorDataType for the "old" Razor.
Svar alle
Svar til forfatter
Videresend
0 nye meldinger