If this is the case it really should be labeled as a breaking change since it will potentially break a lot of sites when doing a patch upgrade.
Also, I actually found the fact that you didn't need to add parameters to macros a plus point of Razor, as it removes one tedious step and makes develoment much more instantaneous.
It may have been unintentional, but it was actually something I really liked as it may developing macros with razor much more dynamic and reactive (which is surely a good thing, no?). The only reason I can see to actually add parameters to a macro would be if it's used in the editor.
Given there wasn't really much documentation about Razor (at least when it was first introduced) it's not suprising that people assumed this was a feature rather than an "unexpected side-effect". I know I've taken advantage of it on a number of sites, and didn't realise these would all break when doing a patch-upgrade to 4.7.1.1 - this will make it a major headache upgrading them. I think it's important if behaviour like this is changed then it is clearly listed as a "breaking change" and documented (EDIT: Which you have now done - thank you!)
@Dan: We had no idea that it would break anything as we didn't know that people worked around a bug like that (not even unit tests would catch it). There's no difference in the macro wrapper between how razor, xslt or .net controls work, so for us nothing was changed. It's just unfortunate that it's been picked up by a few as a practice and of course leading to a frustration by those who do.
Fair enough, Neils :) I guess in future you just need to be aware that the Umbraco community are a creative lot and if we find a way of doing something easier than we will do it :D
Note to anyone new to Umbraco / Razor who reads this:
You don't have to pass document type properties of the current page as parameters. They're properties of the Model object, so you might not need any parameters or need to create a macro in the Developer section. You can call the Razor script in the template like this:
Dynamic parameters not working on version 4.7.1.1
Hi guys,
I have the following macro:
And getting the CssParameter from the razor file:
@inherits umbraco.MacroEngines.DynamicNodeContext @{ // This parameters is empty var cssPaths = Parameter.CssPaths; }This was working ok in version 4.7.1 but it seems to be broken in 4.7.1.1. Do you guys know why is this happening?
Thanks
Jorge
I seems that I also need to set them in the backend
Solved :)
Yes thanks Jorge I've just found exactly the same thing. Perhaps ought to be documented as a breaking change?
If this is the case it really should be labeled as a breaking change since it will potentially break a lot of sites when doing a patch upgrade.
Also, I actually found the fact that you didn't need to add parameters to macros a plus point of Razor, as it removes one tedious step and makes develoment much more instantaneous.
@james @dan Yes, I believe we should report it as a breaking change. Do you guys know where we can do that?
Thanks,
J
@Jorge You can report issues using the Issue Tracker at Codeplex - http://umbraco.codeplex.com/workitem/list/basic
Whilst some may claim this isn't a bug, I think it should be reported as it may or may not have been an intentional decision to change the behaviour.
It's not a bug, quite the contrary - it was a unexpected side-effect that it even worked that way before (a bug!).
I've added it as a breaking change in the upgrading info on the Codeplex page.
Thanks Niels!
It may have been unintentional, but it was actually something I really liked as it may developing macros with razor much more dynamic and reactive (which is surely a good thing, no?). The only reason I can see to actually add parameters to a macro would be if it's used in the editor.
Given there wasn't really much documentation about Razor (at least when it was first introduced) it's not suprising that people assumed this was a feature rather than an "unexpected side-effect". I know I've taken advantage of it on a number of sites, and didn't realise these would all break when doing a patch-upgrade to 4.7.1.1 - this will make it a major headache upgrading them. I think it's important if behaviour like this is changed then it is clearly listed as a "breaking change" and documented (EDIT: Which you have now done - thank you!)
@Dan: We had no idea that it would break anything as we didn't know that people worked around a bug like that (not even unit tests would catch it). There's no difference in the macro wrapper between how razor, xslt or .net controls work, so for us nothing was changed. It's just unfortunate that it's been picked up by a few as a practice and of course leading to a frustration by those who do.
Fair enough, Neils :) I guess in future you just need to be aware that the Umbraco community are a creative lot and if we find a way of doing something easier than we will do it :D
@niels thanks a lot
Note to anyone new to Umbraco / Razor who reads this:
You don't have to pass document type properties of the current page as parameters. They're properties of the Model object, so you might not need any parameters or need to create a macro in the Developer section. You can call the Razor script in the template like this:
<umbraco:Macro FileLocation="~/macroScripts/myRazorScript.cshtml" runat="server" />
is working on a reply...