Variables are options with fallbacks. Save me from this if else hell.
Hello everyone,
We have several macros where we have to account for people forgetting & not settings certain parameters for macros so in the end we end up with some ridiculous Ternary Operators . Is there a better way? How do you handle these?
@Parameter.xxx is from the macro that's being inserted into the page template (always returns a string).
@node.xxx is from a page parameter (will return the datatype e.g. if its a tickbox will be bool).
Page parameters are for the user to access to give them more control over how to display a widget e.g. a list can be aggregated or order this list by release dates. Macro parameters are what the "developer" uses for initial setup these will get overwritten by the page parameters.
On a tickbox, it must be a property field, on that property field on the docType there is a mandatory field, if you make that mandatory and the editor forgets to check it, then he will be unable to proceed, until it is checked, handled by Umbraco back-end.
If that reduces some of the if-else then its a step in the right direction, if there are any others it may reduce more.
You may then only need to check that a test field hasValue.
My hthought was to first reduce the amount of logic required, then see what remains.
Hope it helps
G
am out and about but will try to reply if you need.
Variables are options with fallbacks. Save me from this if else hell.
Hello everyone,
We have several macros where we have to account for people forgetting & not settings certain parameters for macros so in the end we end up with some ridiculous Ternary Operators . Is there a better way? How do you handle these?
Example:
bool aggregated = node.HasValue("aggregated") ? node.GetPropertyValue("aggregated").Equals("1") ? true : @Parameter.aggregated != null ? int.Parse(@Parameter.aggregated) != 0 ? true : false : false : false;As you can see, we need to set a variable called aggregated and need to go through a bunch of checks to try find out what the user wants us to do.
none ternary version of it
if(node.HasValue("aggregated")){ if(node.GetPropertyValue("aggregated").Equals("1")){ aggregated = true; }else{ if(@Parameter.aggregated != null){ if(int.Parse(@Parameter.aggregated) != 0){ aggregated = true; }else{ aggregated = false; } }else{ aggregated = false; } } }else{ aggregated = false; }You can see this is a friggin pain in the ass. Anyone got any suggestions?
Hi Brett
was going to suggest changing aggregated for agrovated. . . .
How are you setting parameter? Can you use validation? Or make it Mandatory.
If you are using a dropdown or similar, put on the field?
ie let Umbraco handle it?
Without seeing more it is the best I can suggest.
Hope it helps
G
Hi Gary,
@Parameter.xxx is from the macro that's being inserted into the page template (always returns a string).
@node.xxx is from a page parameter (will return the datatype e.g. if its a tickbox will be bool).
Page parameters are for the user to access to give them more control over how to display a widget e.g. a list can be aggregated or order this list by release dates.
Macro parameters are what the "developer" uses for initial setup these will get overwritten by the page parameters.
Example of some other ternary operations we use
bool hideDate = node.HasValue("hideDate") ? node.hideDate : @Parameter.hideDate != null ? int.Parse(@Parameter.hideDate) != 0 ? true : false : false;bool ascending = node.HasValue("ascending") ? node.ascending : !String.IsNullOrWhiteSpace(@Parameter.ascending) ? int.Parse(@Parameter.ascending) != 0 ? true : false : false;Hope that clears up what I'm using them for.
Hi Brett
was trying to read on my phone which wasn't easy.
Ok, if we come up a couple of levels -
On a tickbox, it must be a property field, on that property field on the docType there is a mandatory field, if you make that mandatory and the editor forgets to check it, then he will be unable to proceed, until it is checked, handled by Umbraco back-end.
If that reduces some of the if-else then its a step in the right direction, if there are any others it may reduce more.
You may then only need to check that a test field hasValue.
My hthought was to first reduce the amount of logic required, then see what remains.
Hope it helps
G
am out and about but will try to reply if you need.
is working on a reply...