I'm all new to Umbraco and still discovering and learning it. For me, the strongest point of Umbraco is its customization ability... but for that you either need to know Xslt or C# (as far as I've understood you can create macros with both technologies).
I learned some Xslt basics long, long time ago, and have never fancied xml like stuff. So with my starting site, everything I develop I intend to do it in C#. So my questions are:
- Is there something that can be achieved with Xslt that can't be done with C# and viceversa?
- Are there any reasons/cases why using Xslt over C# is more convenient?
Thanks a lot for the tip, I'll keep it in mind, but I mainly started the thread to discuss the "whys". Why should I use Xslt and not C# when displaying data and viceversa?
What are the drawbacks of programming in C# the displaying of data?
My two cents 50 öre; I have learned to like xslt a lot (after much struggle with it and many many hours spent/lost on learning and debugging it). The main reason for me to choose xslt now is it's closeness to xhtml - I always have full control over the produced markup and also that I code most of my transformations faster with xslt/xpath than I would have with c#. I agree with Ismails rule of thumb, and choose c# for inputs, but for some sites I found myself using xslt for that as well - when the project team has setup xhtml validation rules that webforms and asp-controls are next to impossible to validate with.
My five pence worth, once we get onto 4.5 i will be using linq2umbraco and doing inline c# in usercontrol macros and moving away from xslt. I have loved the flexiblity of xslt but i can achieve similar with linq2umbraco but thats one of the great things about umbraco more than one way to skin a cat :-}
By the moment I'm sticking with XSLT till I have the site I'm preparing up. Once I get there, I'll evaluate again as it seems Lin1Umbraco closes the gap between XSLT vs C# disadvantages, while leaving all of what C# gives intact (or even better as it'll be simpler with Linq).
But as Imsail said, the good thing is that we can have the opportunity to choose what feels better to us.
One point to rember is that you can edit the XSLT through the admin interface, whereas the custom .NET will sit compiled and require republishing to your production box.
There has been a couple of times in the past were we have made production patches which has just required updating an XSLT rather than redeploying/recycling the whole app.
Agree. And dont forget the source code administration. Thats nothing that comes automatically with Visual Studio nor Umbraco. Without the source you're pretty much lost (at least you will spend lots of hours recreating stuff) if you need to edit something in an old project in c#. But with Xslt the source is at your fingertips always, even if your network administrator (or the project guy at the former office, or you...) lost the place for the source.
Macros: Xslt VS C#
Hello all,
I'm all new to Umbraco and still discovering and learning it. For me, the strongest point of Umbraco is its customization ability... but for that you either need to know Xslt or C# (as far as I've understood you can create macros with both technologies).
I learned some Xslt basics long, long time ago, and have never fancied xml like stuff. So with my starting site, everything I develop I intend to do it in C#. So my questions are:
- Is there something that can be achieved with Xslt that can't be done with C# and viceversa?
- Are there any reasons/cases why using Xslt over C# is more convenient?
The most interesting related topic I've found is this one: http://our.umbraco.org/forum/developers/xslt/6508-VB-or-C#-within-xslt-%28xslt-only-used-for-the-call%29-bad-practice
It seems that since the introduction of App_Code there's no reason not to do all the work in C#. Am I missing something?
Thanks a lot!
Jacobo,
As a good rule of thumb, if you are displaying data use xslt. If you are taking input use .net.
Regards
Ismail
Hi Ismail!
Thanks a lot for the tip, I'll keep it in mind, but I mainly started the thread to discuss the "whys". Why should I use Xslt and not C# when displaying data and viceversa?
What are the drawbacks of programming in C# the displaying of data?
Thanks! Cheers!
Jacobo,
Take a look at comprehensive post by Slace at http://farmcode.org/post/2010/07/13/TheFARMe28099s-guide-to-Macros.aspx
Regards
Ismail
Thanks a lot Ismail, that post was pretty good.
Seems like I'll have to revamp my XSLT knowledge, ough...
Cheers!
My two cents 50 öre; I have learned to like xslt a lot (after much struggle with it and many many hours spent/lost on learning and debugging it). The main reason for me to choose xslt now is it's closeness to xhtml - I always have full control over the produced markup and also that I code most of my transformations faster with xslt/xpath than I would have with c#. I agree with Ismails rule of thumb, and choose c# for inputs, but for some sites I found myself using xslt for that as well - when the project team has setup xhtml validation rules that webforms and asp-controls are next to impossible to validate with.
Regards / Jonas
My five pence worth, once we get onto 4.5 i will be using linq2umbraco and doing inline c# in usercontrol macros and moving away from xslt. I have loved the flexiblity of xslt but i can achieve similar with linq2umbraco but thats one of the great things about umbraco more than one way to skin a cat :-}
Regards
Ismail
I almost forgot about this thread!
After reading the previous article I understood the rule ofthumb. Now, after Ismail's last comment and this article http://legacy.aaron-powell.com/blog/november-2009/why-i%27m-not-a-fan-of-xslt.aspx from the craetor of Linq2Umbraco, something in the back of my head tells me to give C# a go for everything...
By the moment I'm sticking with XSLT till I have the site I'm preparing up. Once I get there, I'll evaluate again as it seems Lin1Umbraco closes the gap between XSLT vs C# disadvantages, while leaving all of what C# gives intact (or even better as it'll be simpler with Linq).
But as Imsail said, the good thing is that we can have the opportunity to choose what feels better to us.
Cheers!
Hi,
One point to rember is that you can edit the XSLT through the admin interface, whereas the custom .NET will sit compiled and require republishing to your production box.
There has been a couple of times in the past were we have made production patches which has just required updating an XSLT rather than redeploying/recycling the whole app.
Thanks,
Chris.
Agree. And dont forget the source code administration. Thats nothing that comes automatically with Visual Studio nor Umbraco. Without the source you're pretty much lost (at least you will spend lots of hours recreating stuff) if you need to edit something in an old project in c#. But with Xslt the source is at your fingertips always, even if your network administrator (or the project guy at the former office, or you...) lost the place for the source.
is working on a reply...