This all works fine when multiple values are selected as the overload NodeById(list<int>) returning DynamicNodeList is used. But when the user only selectes one item the "Type Safety" feature (Bug) converts my value to a int, the overload function return only a DynamicNode is used, and the foreach loop fails.
Adding code to start testing for which types my value are, is a bad way doing this in razor templates as that adds overhead to really dont belong in a GUI.
The automatic Type Safety function is nice in some cases but very bad in other.
First of all, this problem is due to the duck typing that's being done, not type safety.
The problem with duck typing is that it can indeed be unreliable in cases like yours. The only workaround that I know, without having to do an if-else statement is just getting the string version and do your own Split on it:
var nav = startPage.GetProperty("supplementaryNavigation").Split(",");
The better solution to workaround this is building my own extensions, ie a function called NodesById that always return a dynamicnodelist.... The best would be if such solution already existed in the core.
But a huge problem is the duck typing. Not ever knowing what the object you have is for datatype depending on a user input, in a presentation layer, OUCH!
By the way, do check out uQuery, it has extension method that returns nodes as the types that you specify. UQL might also be interesting for you, though it's a lot more dynamic again.
Yeah, but doesnt anyone else than me see that this is a problem? I would have been very fine if the typing of properties and such would have been based on my datatype. Ie using a tetxstring datatype and stored in the db as nvarchar should always be a string, no like in this exampel:
In exampel, in Sweden we can write postal codes like this:
12345 = Truns into a int
123 45 = Turns into a decimal
SE12345 = Turns into a string
And this is all based on what a user that doesnt know a thing about coding, datatypes and such.
There is no good way to do typing based on the datatype as not all of the datatypes (especially the custom ones) have a certain type. Some store data in XML format OR in CSV format depending on the configuration. Some datatypes like True/False and the RTE do get typed this way, but it's not possible to do this for all of them.
Umbraco stores everything as a text string, so the workaround is to always use Model.GetProperty("yourAlias").Value to get the string value. From there you can cast it to whatever you know is the correct type.
Yes its a nice feature for booleans like in the example but opens up a can of worms for other types. If all properties are outputed as strings, its up to me as a developer to type it into some other datatype that I want, not something that happens randomly, this allows for better control. As converting from something you dont know vs converting from something you know to another datatype is imho a much better solution, as then its converted when I need it to, else it should be outputted from the razor template as strings.
Type safety problems
Scenario,
I have a doc type with a property using a UComponents multi picker datatype.
The user is allowed to chosse either zero, one or as many nodes as they want. Data is stored as a csv string.
Following code is used to render a supplementary navigation:
This all works fine when multiple values are selected as the overload NodeById(list<int>) returning DynamicNodeList is used. But when the user only selectes one item the "Type Safety" feature (Bug) converts my value to a int, the overload function return only a DynamicNode is used, and the foreach loop fails.
Adding code to start testing for which types my value are, is a bad way doing this in razor templates as that adds overhead to really dont belong in a GUI.
The automatic Type Safety function is nice in some cases but very bad in other.
First of all, this problem is due to the duck typing that's being done, not type safety.
The problem with duck typing is that it can indeed be unreliable in cases like yours. The only workaround that I know, without having to do an if-else statement is just getting the string version and do your own Split on it:
var nav = startPage.GetProperty("supplementaryNavigation").Split(",");The better solution to workaround this is building my own extensions, ie a function called NodesById that always return a dynamicnodelist.... The best would be if such solution already existed in the core.
But a huge problem is the duck typing. Not ever knowing what the object you have is for datatype depending on a user input, in a presentation layer, OUCH!
Haha, the joys of Dynamic programming! Like everything, with great power come great responsibility. :)
By the way, do check out uQuery, it has extension method that returns nodes as the types that you specify. UQL might also be interesting for you, though it's a lot more dynamic again.
Yeah, but doesnt anyone else than me see that this is a problem? I would have been very fine if the typing of properties and such would have been based on my datatype. Ie using a tetxstring datatype and stored in the db as nvarchar should always be a string, no like in this exampel:
In exampel, in Sweden we can write postal codes like this:
12345 = Truns into a int
123 45 = Turns into a decimal
SE12345 = Turns into a string
And this is all based on what a user that doesnt know a thing about coding, datatypes and such.
There is no good way to do typing based on the datatype as not all of the datatypes (especially the custom ones) have a certain type. Some store data in XML format OR in CSV format depending on the configuration. Some datatypes like True/False and the RTE do get typed this way, but it's not possible to do this for all of them.
Umbraco stores everything as a text string, so the workaround is to always use Model.GetProperty("yourAlias").Value to get the string value. From there you can cast it to whatever you know is the correct type.
Yeah basiclly thats what it should do when its duck typing, as Iproperty.Value is a string, but some how this value is then parsed into what ever it can using the data value. I would have suspected that the problems comes from the "Type Safety" thats explained on this page: http://umbraco.com/follow-us/blog-archive/2011/2/28/umbraco-razor-feature-walkthrough-–-part-3
Yes its a nice feature for booleans like in the example but opens up a can of worms for other types. If all properties are outputed as strings, its up to me as a developer to type it into some other datatype that I want, not something that happens randomly, this allows for better control. As converting from something you dont know vs converting from something you know to another datatype is imho a much better solution, as then its converted when I need it to, else it should be outputted from the razor template as strings.
Call me crazy :)
Certainly not crazy, just a difference of opinion I guess. :-)
I really like that you have the option of using either one of them, even though it's not your preferred notation ("GetProperty").
is working on a reply...