I have been asked this many times, my answer is this, intellisense vs conciseness.
If you use Visual Studio (or even WebMatrix) for writing your Razor then Typed probably suits you for intellisense and debugging, if you use the browser based editor in the Umbraco UI then Dynamic is more concise.
There is a bit more about this in my session from umbOktoberFest 2014 which you can download here.
I actually like strongtyped even when using Umbraco UI backend. Dont know why. Might be because I try to use only one approach. I dont think dynamic is that much more concise (though the pluralizer is awesome).
Sidenode - I really think that having both ways strong/dynamic is source to some confusion for many (including me). The "converters" from XSLT and other non devs dont really care about strong/dynamic and they see many different ways of doing the same. So when finding examples they are doing both making it difficult to combine them. So my wish is keep it simpler :D
Plus 1 for your sidenode Jesper - It's the same feeling I have been having a long time but somehow have not been able to express clearly enough. It's a bit confusing that there is more than one way of doing it and why would one choose one over the other? I think it can be hard to maintain the codebase if you're working on a project with more developers on/off and if people just use what they feel like instead of agreeing on one approach to keep things simple and maintainable in the future and easier for others to take over their work as well.
There are some interesting discussions to have in the future about continued support for dynamics.
One of the major advantages of dynamics currently is the ability to do CurrentPage.MyProperty. However this can now be done with Strongly Typed also by using ZbuModelBuilder!
You can use Stephans model builder even if you use only the Umbraco UI, this means you can access properties like Model.MyProperty. Of course there are some other nice features of the dynamics approach such as the plurazier but there are helpers such as the OfTypes extension which provide a similar simple approach.
We will see where this goes and if Model Builder becomes part of core......
Yes indeed - I think the CurrentPage approach is nice and the pluralizer as well. But it's just confusing that there are two ways of achieving the same thing. It used to be easy for frontend developers to make Umbraco websites without that much backend knowledge in order to render content etc. - But fortunately things have improved a lot last 2 years and I'm positive about the future :)
I'm going to take the contrary position and say strongly typed is over-hyped by people who have visual studio and don't use the Umbraco UI for coding.
The back office editor has zero help in the form of any kind of intellisense and probably never will. Pity, because the people who would most benefit from it are those who are NOT programmers and/or are not proficient with razor. Strongly-typed is a nightmare without such aids.
There was a long discussion about how to get away from using the very geek term 'Model'. Primarily this debated topic centered around if it should be done. And if another name should be used, should it be called Current or CurrentPage? In the end it was decided to use CurrentPage because that makes sense and 'Model' doesn't. For the same reason, we call them templates rather than Views in the back office. To the uninitiated the terms Model and View just don't make sense and they were always translating them into CurrentPage and Template in their minds anyway. So we call them what they are, not what they are under the hood.
Naturally this becomes blurred when we get to Controllers, but that's proper C# and api stuff and you're expected to know real mvc at that point. And at that point it's reasonable and prudent to use strongly typed. And easier than dynamic razor, too, since you have VS with intellisense and debugging at your command. For people who typically code in VS anyway and are into mvc, they'll call the templates 'views' and having gotten the benefit of intellisense with strongly-typed code they'll naturally write their razor that way too. No harm in that. As ever with Umbraco, you aren't forced one way or the other but have the freedom of two excellent choices.
For 'Level 1' people --if I can put it like that-- strongly-typed is overkill and makes the even simple tasks more difficult and error-prone; particularly in the back office editors where they will do all/the bulk of their coding. Suggesting strongly-typed be the de facto (and only) way to write razor isn't the experience anyone would want... not for new users, and definitely not for people who are used to VS and then try to code something (even something simple) with strongly-typed code in the back office editors.
There have been improvements in 7.2 for backoffice code editors though. With the new syntax of 7.2, there's no need to use the magical pluralizer (honestly, who can tell me the plural of doctype named 'News'? Hint: it is 'Newses'). Nor to have to contend with knowing when and why to use .First() in your selection queries in some places but not others. Now that 7.2 has the Query Builder (hooray! what a great time saver and learning tool!) we have CurrentPage.FirstChild("News Area").Children("News Item").Where("Visible"). Clear, simple, succinct, obvious.
We've even done away with the need for .AncestorOrSelf(1) to get to the top node of your site. Now you can use .Site(). I suppose some may say that .AncestorOrSelf(1) is very obvious and descriptive. Perhaps it is, once you know it and understand what it is really doing and why you need the OrSelf bit, and how it is totally different than .AncestorsOrSelf(1). But I'll argue that just as we used to always write code such as if (xyz.Count() > 0) and thought that made plenty of sense, the modern way of doing it is more semantic and meaningful... if (xyz.Any())
In summary... in the old days you could write xslt or .net user controls. You picked what was best for your needs and your personal preferences. If you were the kind of person who has VS open if you're awake then just do everything in c#. If you liked the benefits of fast but uncompiled xslt you could use that. I see the choice of strongly-typed razor (or not) as exactly the same. Code to your preferences and your needs, but please don't impose your preference on others. We, our clients, and our projects are are unique and will require different solutions.
-- shameless plug for more improvements --
Now, if we could finally put buttons on the back office template/ partial view / partial view macro file toolbars for inserting a partial view, sections, renderbody, rendersection, links to stylesheets and js files, even if-then and foreach snippets we'd greatly reduce the burden on users. All of those would be hugely helpful (and most were in v3-6 so this isn't something new, just missing in v7). Please vote it up http://issues.umbraco.org/issue/U4-4911.
Actually I think what you are saying fits. There is a technical issue and user confusion of supporting both dynamic and typed models and it would be more straight forward if there was only one model to maintain sometime in the future.
Everything we built in the query builder and the sample you referenced above can work under the hood with the single model.
The idea to have a single model shouldn't be imposing anything on anyone and I agree that CurrentPage or whatever is more friendly than Model and I'm sure that both could be supported in a single supported system.
For example, in a Umbraco vSomthing where under the hood there is only a strongly typed model (with model generation) the below would still work as there is nothing dynamic in there.
With the Roslyn runtime compiler being used for the model generation already and the other online tools MS is releasing, it's not inconceivable that intellisense will one day exist in the browser template editor!
Great discussion!
Jeavon
p.s. So happy to hear all that hard work we put in the Core at #cgrt14 is being used and making the learning curve easier for newbies!
Obviously, I'm biased and use Visual Studio + strongly-typed models for all my sites.
That being said, for a simple site / beginner dev, it's a pain. It takes me time to setup a new site. I've tried to figure out ways to "auto-generate" models entirely transparently, but at the moment, due to the way ASP.NET works, I cannot get it to work. So there are few steps to follow, and buttons to click, and stuff to install - more than what you want for a simple site maybe. Hey, I guess that "you have to generate models" is already too much in some cases.
So I guess, really, it's good that there are different solutions and the key is to be able to figure out what rendering solution you want depending on the life-cycle of the website, it size, the number and profile of devs, etc. Could be a very interesting CG session: considering that there will not be an ideal & unique solution, how should I pick one for my site?
Yeah, I like that things are flexible for sure. But I'm still getting my head around this Razor thing. It's not until now that I have begun to look at it since I could achieve my goals using XSLT until v6. With v7 it's become a little harder and I'm willing to give the Razor approach a try. So I'm still a bit of a newbie and perhaps I have missed a lot of good documentation.
And I'm not at all against having more ways - It can just get really confusing sometimes when people talk about Razor and whether one should use the dynamic approach or the model approach. The more flexible the better as long as it's not becoming hard for anyone to maintain or understand etc.
If the scenario Jeavon describes is achievable I think that would be a win - But I don't have enough technical insight to know whether or not it is. But one approach with more options (You can choose whether you're referencing model or CurrentPage etc. etc.) would be good I think.
Perhaps it's also more a matter of defining some "Good to know / Best practices" or "Pros'n'Cons" when having to choose one approach over the other perhaps? Sorry if such information already exists...but then perhaps it needs more highlightning :)
It's confusing enough to learn one new way. One of the major struggles is that examples is disgussed in more than one language. Imagine the our forum where in english and german :) Half of the examples in another language :) I like having choices but to me it seems the two coexist because both has their pro's and con's and neither is ideal. I avoid dynamics because they lack intellisence and seems to cause me more trouble. I'm not fond of Strongtyped for the complicated syntax.
Maybe there's a third option. My vote goes to the strong typed approach that has the syntax of the dynamics. So generated classes might be the solution. Something that works directly in Umbraco.
A great example is Zbu.ModelsBuilder. Works. Class models are simple.
Strong typed vs. dynamic (implementation planning)d
Hi all,
I'm just about to begin adding a sh*itload of razor partial views. I want the solution to use one approach as much as possible.
I like the Strong typed best:
And not so much the dynamic:
Which do you prefer?
Any reasons not to use strong typed?
best
Jesper
Best
Jesper
Hi Jesper,
I have been asked this many times, my answer is this, intellisense vs conciseness.
If you use Visual Studio (or even WebMatrix) for writing your Razor then Typed probably suits you for intellisense and debugging, if you use the browser based editor in the Umbraco UI then Dynamic is more concise.
There is a bit more about this in my session from umbOktoberFest 2014 which you can download here.
Jeavon
Thanks Jeavon,
I actually like strongtyped even when using Umbraco UI backend. Dont know why. Might be because I try to use only one approach. I dont think dynamic is that much more concise (though the pluralizer is awesome).
Sidenode - I really think that having both ways strong/dynamic is source to some confusion for many (including me). The "converters" from XSLT and other non devs dont really care about strong/dynamic and they see many different ways of doing the same. So when finding examples they are doing both making it difficult to combine them. So my wish is keep it simpler :D
Thanks for the slide. Lots of goodies.
best
Jesper
Plus 1 for your sidenode Jesper - It's the same feeling I have been having a long time but somehow have not been able to express clearly enough. It's a bit confusing that there is more than one way of doing it and why would one choose one over the other? I think it can be hard to maintain the codebase if you're working on a project with more developers on/off and if people just use what they feel like instead of agreeing on one approach to keep things simple and maintainable in the future and easier for others to take over their work as well.
Just my 2 cents :)
/Jan
There are some interesting discussions to have in the future about continued support for dynamics.
One of the major advantages of dynamics currently is the ability to do
CurrentPage.MyProperty. However this can now be done with Strongly Typed also by using ZbuModelBuilder!You can use Stephans model builder even if you use only the Umbraco UI, this means you can access properties like
Model.MyProperty. Of course there are some other nice features of the dynamics approach such as the plurazier but there are helpers such as the OfTypes extension which provide a similar simple approach.We will see where this goes and if Model Builder becomes part of core......
Yes indeed - I think the CurrentPage approach is nice and the pluralizer as well. But it's just confusing that there are two ways of achieving the same thing. It used to be easy for frontend developers to make Umbraco websites without that much backend knowledge in order to render content etc. - But fortunately things have improved a lot last 2 years and I'm positive about the future :)
/Jan
Indeed it has, most of what I've contributed over the last 2 years has been to simplify the overhead for frontenders beginning templating with Razor!
So what would you think if in Umbraco v99 we had only the option of
Model.MyPropertyandModel.Children.OfTypes("MyType")....?V99? I don't think I'm alive THAT long :D - But in v9 I think it would be nice to have it cooked down to this indeed.
/Jan
I'm going to take the contrary position and say strongly typed is over-hyped by people who have visual studio and don't use the Umbraco UI for coding.
The back office editor has zero help in the form of any kind of intellisense and probably never will. Pity, because the people who would most benefit from it are those who are NOT programmers and/or are not proficient with razor. Strongly-typed is a nightmare without such aids.
There was a long discussion about how to get away from using the very geek term 'Model'. Primarily this debated topic centered around if it should be done. And if another name should be used, should it be called Current or CurrentPage? In the end it was decided to use CurrentPage because that makes sense and 'Model' doesn't. For the same reason, we call them templates rather than Views in the back office. To the uninitiated the terms Model and View just don't make sense and they were always translating them into CurrentPage and Template in their minds anyway. So we call them what they are, not what they are under the hood.
Naturally this becomes blurred when we get to Controllers, but that's proper C# and api stuff and you're expected to know real mvc at that point. And at that point it's reasonable and prudent to use strongly typed. And easier than dynamic razor, too, since you have VS with intellisense and debugging at your command. For people who typically code in VS anyway and are into mvc, they'll call the templates 'views' and having gotten the benefit of intellisense with strongly-typed code they'll naturally write their razor that way too. No harm in that. As ever with Umbraco, you aren't forced one way or the other but have the freedom of two excellent choices.
For 'Level 1' people --if I can put it like that-- strongly-typed is overkill and makes the even simple tasks more difficult and error-prone; particularly in the back office editors where they will do all/the bulk of their coding. Suggesting strongly-typed be the de facto (and only) way to write razor isn't the experience anyone would want... not for new users, and definitely not for people who are used to VS and then try to code something (even something simple) with strongly-typed code in the back office editors.
There have been improvements in 7.2 for backoffice code editors though. With the new syntax of 7.2, there's no need to use the magical pluralizer (honestly, who can tell me the plural of doctype named 'News'? Hint: it is 'Newses'). Nor to have to contend with knowing when and why to use
.First()in your selection queries in some places but not others. Now that 7.2 has the Query Builder (hooray! what a great time saver and learning tool!) we haveCurrentPage.FirstChild("News Area").Children("News Item").Where("Visible"). Clear, simple, succinct, obvious.We've even done away with the need for
.AncestorOrSelf(1)to get to the top node of your site. Now you can use.Site(). I suppose some may say that.AncestorOrSelf(1)is very obvious and descriptive. Perhaps it is, once you know it and understand what it is really doing and why you need theOrSelfbit, and how it is totally different than.AncestorsOrSelf(1). But I'll argue that just as we used to always write code such asif (xyz.Count() > 0)and thought that made plenty of sense, the modern way of doing it is more semantic and meaningful...if (xyz.Any())In summary... in the old days you could write xslt or .net user controls. You picked what was best for your needs and your personal preferences. If you were the kind of person who has VS open if you're awake then just do everything in c#. If you liked the benefits of fast but uncompiled xslt you could use that. I see the choice of strongly-typed razor (or not) as exactly the same. Code to your preferences and your needs, but please don't impose your preference on others. We, our clients, and our projects are are unique and will require different solutions.
-- shameless plug for more improvements --
Now, if we could finally put buttons on the back office template/ partial view / partial view macro file toolbars for inserting a partial view, sections, renderbody, rendersection, links to stylesheets and js files, even if-then and foreach snippets we'd greatly reduce the burden on users. All of those would be hugely helpful (and most were in v3-6 so this isn't something new, just missing in v7). Please vote it up http://issues.umbraco.org/issue/U4-4911.
-- end shameless plug --
cheers,
doug.
Hi Doug,
Actually I think what you are saying fits. There is a technical issue and user confusion of supporting both dynamic and typed models and it would be more straight forward if there was only one model to maintain sometime in the future.
Everything we built in the query builder and the sample you referenced above can work under the hood with the single model.
The idea to have a single model shouldn't be imposing anything on anyone and I agree that CurrentPage or whatever is more friendly than Model and I'm sure that both could be supported in a single supported system.
For example, in a Umbraco vSomthing where under the hood there is only a strongly typed model (with model generation) the below would still work as there is nothing dynamic in there.
And so could
What wouldn't be possible is
With the Roslyn runtime compiler being used for the model generation already and the other online tools MS is releasing, it's not inconceivable that intellisense will one day exist in the browser template editor!
Great discussion!
Jeavon
p.s. So happy to hear all that hard work we put in the Core at #cgrt14 is being used and making the learning curve easier for newbies!
Obviously, I'm biased and use Visual Studio + strongly-typed models for all my sites.
That being said, for a simple site / beginner dev, it's a pain. It takes me time to setup a new site. I've tried to figure out ways to "auto-generate" models entirely transparently, but at the moment, due to the way ASP.NET works, I cannot get it to work. So there are few steps to follow, and buttons to click, and stuff to install - more than what you want for a simple site maybe. Hey, I guess that "you have to generate models" is already too much in some cases.
So I guess, really, it's good that there are different solutions and the key is to be able to figure out what rendering solution you want depending on the life-cycle of the website, it size, the number and profile of devs, etc. Could be a very interesting CG session: considering that there will not be an ideal & unique solution, how should I pick one for my site?
Hi guys
Yeah, I like that things are flexible for sure. But I'm still getting my head around this Razor thing. It's not until now that I have begun to look at it since I could achieve my goals using XSLT until v6. With v7 it's become a little harder and I'm willing to give the Razor approach a try. So I'm still a bit of a newbie and perhaps I have missed a lot of good documentation.
And I'm not at all against having more ways - It can just get really confusing sometimes when people talk about Razor and whether one should use the dynamic approach or the model approach. The more flexible the better as long as it's not becoming hard for anyone to maintain or understand etc.
If the scenario Jeavon describes is achievable I think that would be a win - But I don't have enough technical insight to know whether or not it is. But one approach with more options (You can choose whether you're referencing model or CurrentPage etc. etc.) would be good I think.
Perhaps it's also more a matter of defining some "Good to know / Best practices" or "Pros'n'Cons" when having to choose one approach over the other perhaps? Sorry if such information already exists...but then perhaps it needs more highlightning :)
Just my 2 cents.
Love, Jan
It's confusing enough to learn one new way. One of the major struggles is that examples is disgussed in more than one language. Imagine the our forum where in english and german :) Half of the examples in another language :) I like having choices but to me it seems the two coexist because both has their pro's and con's and neither is ideal. I avoid dynamics because they lack intellisence and seems to cause me more trouble. I'm not fond of Strongtyped for the complicated syntax.
Maybe there's a third option. My vote goes to the strong typed approach that has the syntax of the dynamics. So generated classes might be the solution. Something that works directly in Umbraco.
A great example is Zbu.ModelsBuilder. Works. Class models are simple.
best
Jesper
is working on a reply...