Me! :P

But we've been using LINQ with Umbrace at TheFARM for ages - http://www.farmcode.org/post/2009/02/24/Linq-to-Umbraco.aspx

All our sites have some level of LINQ with Umbraco in them. Nothing overly exciting though, just standard selects/ wheres/ etc.

But a bit of interesting code I've done:

IEnumerable<XElement> nodes = UmbXmlLinqExtensions.GetNodeByXpath(...);
IEnumerable<IUmbracoPage> pages = from n in nodes select (IUmbracoPage)(UmbracoPage)n;

See if you can work out how that would work ;)

I will use it for sure, I think the LINQ-syntax is very conveniant. But I do not see it as a replacement of XSLT?  I see it as a complement to other ways of addressing content in vb / c#-code. If / when we can edit our app_code-files online for some of the functionality we take care of in XSLT today at least I know I will be a (much) more productive Umbraco-coder. http://our.umbraco.org/forum/developers/xslt/6508-VB-or-C#-within-xslt-(xslt-only-used-for-the-call)-bad-practice

Having editable .NET code files on a live server isn't a good idea.

1. It poses a security risk, anyone who has CMS access can go in and modify the functionality
2. You take a decent performance hit as the assembly has to be constantly compiled on-the-fly by the ASP.NET runtime
3. It's a lot easier for people to steal your code

I do agree with you about it was not a very good idea. But mostly for the fact (?) that editing app_code-files live would kill the app_pool and giving users that are online at the moment a hard time. Also because it opens up for a more sloppyish way of coding, leaving the good VS-tools at home.

However;

About the risks, don't we already face them allowing templates and xslt-macros with <script and <msxml:script? And performance hit would be only after editing and if the app_pool recycles / needs to start, no?

I don't like server script inside templates any more than I like code in the App_Code folder, if you're using a compiled language it should be compiled.

I also don't like XSLT on principle, and the last week after having taken over a site which is full of XSLT I'm liking it even less.
That's why I wrote LINQ to Umbraco :P

I've just downloaded all your screencasts Aaron, I'll try and watch them this afternoon :)   Also just watched the first episode here

http://tekpub.com/view/linq/1

Hopefully should have my head round LINQ in about a year (j/k)... :P  Actually I'm going to start playing with it at the weekend and see what's what

I haven't tried LINQ to Umbraco, as I haven't needed (or wanted) to yet.  I do think simplifying the data access in Umbraco, is a super-duper-total-awesome idea, and really glad that it's going to ship in the next version (v4.1)!

Just for me, I don't have the need for it ... XSLT has been able to do everything I need, (as a templating language), so I have no reason to move away from it.

I do think this shouldn't be about LINQ to Umbraco versus XSLT - they both can (and will) co-exist. In the same way that Python is still lingering around in the core, (I'd love to see 'real world' uses of it).

My concern with LINQ (in general, or more specifically with LINQ to SQL), is that some of the Microsoft Evangelists came it to be obsolete - intended as a stop-gap for the Entity Framework release (which I haven't used either yet - seen demos last year, looked awesome!)  So is it worth investing time learning a new approach, when the next version of ASP.NET might reinvent the way we develop?

But with that said, by not using LINQ, I'm still developing with a ASP.NET 2.0 mind-set; so why should ASP.NET 4.0 influence my decisions?!

Cheers, Lee.

Aaron, you're making me think! Why? ;-)

Anyways, we will probably start using linq on the first 4.1 project we launch, but it's been a while since I looked at it. Last I saw it, it took a while to get the results for the first hit, but I can't remember if it was because it was getting data directly from the DB back then.

Am I correct in thinking that is is now running on the published xml? And is there still a performance hit on the first query (if so, how big)?

Lee, the Linq2SQL is only an implementation that lets you query SQL using linq.

Linq in itself is just a query language that can be used on many types of objects, such as generic List<T> and so on. So Linq in itself is not going anywhere. Only the Ling2Sql implementation (which will be replaces by Entity Framework from a microsoft point of view).

I built my first big umbraco site with lots of xslt, stubborn to learn it and use it for every bit I could. Now I wonder if that was so wise to be so stubborn, I sure could do much of the templating functionality much quicker if I used more c# and nodefactory from the beginning. LINQ also is just a syntax, under the hood it's just iterating items the way we do using for each.

Still can't believe no one has solved my riddle. It's not even LINQ related really, it's actually a .NET language feature :P.

But Morten hit the nail on the head, LINQ is just a pattern for evaluating expressions against a collection, either in memory, via language translation, or something completely different.

Morten - what you're probably thinking of the Umbraco Interaction Layer which I did put LINQ functionality into. It was really an afterthought and LINQ to Umbraco is a different design from the ground up.
But yes, it did interact with the Document API, as it was designed for creating/ editing and deleting of strongly typed Umbraco objects. It was really just a layer in front of the Document object.

I'd like to take a step back (and possibly to the side and slightly off topic) and ask what are the goals for Umbraco? If one goal is to allow non .NET developers to develop CMS systems then I'm not sure LINQ offers much advantages over XSLT.

There are 2 distinct uses for LINQ:

1. Within the core and also packages

I think LINQ is great for developers and should be considered if developing packages/extensions to Umbraco. (Although there are also questions about the expected life of LINQ)

2. As a replacement for XSLT for users of Umbraco

I just don't see the systax is that much clearer than XSLT, especially to a novice.

Personally I'd like to be able write statements like:

[code]foreach (var product in site.Pages.Where(p => p.DocumentProperty.showInMenu == true))
{}
[/code]

You could do this using a product such as lightspeed (the first lightspeed developer is now working for MS on their entity framework).

And if you combined it with NHaml it becomes very readable even to beginners...

[code]
%h2= site.currentPage.Tttle
%ul
  - foreach (var product in site.Pages.Where(p => p.DocumentProperty.showInMenu == true))
    %li
      = Html.ActionLink(page.title, page.URL)

[/code]

Compare that to the XSLT equivalent:
[code]
<ul>
<xsl:for-each select="$currentPage/ancestor-or-self::node [@level=$level]/node [string(data [@alias='umbracoNaviHide']) != '1']">
    <li>
        <a href="{umbraco.library:NiceUrl(@id)}">
            <xsl:value-of select="@nodeName"/>
        </a>
    </li>
</xsl:for-each>
</ul>
[/code]


I've been playing with Ruby on Rails a fair bit lately so i'm definetly biased towards that kind of syntax.
Paul

well it's not at all readable if it don't get formatted properly :( Once more for good luck...

NHAML + lightspeed

%h2= site.currentPage.Tttle
%ul
  - foreach (var product in site.Pages.Where(p => p.DocumentProperty.showInMenu == true))
    %li
      = Html.ActionLink(page.title, page.URL)

XSLT equivalent

<ul>
<xsl:for-each select="$currentPage/ancestor-or-self::node [@level=$level]/node [string(data [@alias='umbracoNaviHide']) != '1']">
    <li>
        <a href="{umbraco.library:NiceUrl(@id)}">
            <xsl:value-of select="@nodeName"/>
        </a>
    </li>
</xsl:for-each>
</ul>

Personnally.. Out of your two examples Paul I still prefer the XSLT ;-)

If you pulled the select in your for-each loop out into a variable and then used the variable on the for-each loop it would look even more understandable to a novice. I agree the XPATH statement is a nightmare to get your head around when you start working with XSLT, but once you "get it" it's actually very easy to write. IMHO.

Cheers,

Chris

Finally I did some homework and read http://our.umbraco.org/wiki/reference/api-cheatsheet/linq-to-umbraco/overview

I must say it's more into Linq to Umbraco than I thought, and I really look forward to dig deeper into it. However I still don't fully understand the xslt versus linq question.

For me l2u it seems to be a great api-improvement, where xslt still is a great / the best way of bringing the xml-data nicely to html-presentation. And: xslt can be / often are edited in the ui. Linq will never be coded there (as I understand)?

I agree with Jonas and it's not completely clear to me why it's xslt versus linq. This used to be xslt versus usercontrols, but when you use linq don't you still use a usercontrol to display the actual data (or you can use an xslt extension). Linq to Umbraco isn't a new way to render data like xslt and usercontrols are right?

Well no, LINQ and XSLT have different goals. LINQ is a data tool, where XSLT is a presentation tool

My problem/ argument is that XSLT too often becomes a data tool, I've seen huge XSLT files which encompass business logic, data manipulation and even writing the the database (cringe).

And then because of this you often have similar (or identical) functionality replicated across many XSLT files.

When XSLT is being used as a presentation layer I don't have a (major) problem with it, but when it's used as a business logic layer I get saddened :P

Thanks for that clarification Slace!

One thing I would like very much is to have more fancy tools in the XSLT-editor. Like point-and-click your way to a code-template with <ul><li> from a given node with a given document type (and perhaps even with the possibility to add a pager).

And also a way to add functions / templates for oneself (and for the community if they could be of common use). Are there btw a way I can add more static XSLT-templates (the ones that show up when creating new XSLT-files)?

(I love the XSLT-visualizer btw, and even better when it will have line numbers and syntax highlight)

I can certainly see good uses for LINQ in Umbraco, as some have said - it's especially needed when extending umbraco, since the API as far as I know seriously lacks easy node filtering.

I don't see any major advantages in LINQ if you're only presenting data from the published node data, other than it enables presenting data directly from master pages. But here I'd rather see a simple method allowing rendering xslt files via an umbraco:renderxslt tag or something like that.

Also I'm wondering what will happen to the excellent (and almost automatic) handling of output caching. Caching is extremely easy to configure with umbraco, if we're using LINQ and native asp.net data controls, I assume we'll have to code cache handling ourselves?

Regards
Jesper Hauge

Caching within LINQ to Umbraco is at a per-DataProvider level (see this session - http://www.aaron-powell.com/blog/october-2009/a-developers-guide-to-linq-to-umbraco---session-3---delving-into-the-umbracodatacontext.aspx for more info on what I mean by DataProvider).

The 'standard' provider is the NodeDataProvider, which works with the Umbraco XML cache, but it also internally caches the objects which are created.

I look more into caching in this session - http://www.aaron-powell.com/blog/october-2009/a-developers-guide-to-linq-to-umbraco---session-4---performance-and-caching.aspx

@slace:

I agree with you that the xslt should not be used as the business logic layer. Looking at you comment you dont have a (major) problem with xslt as a presentation layer, but you still don't seem to like it. What do you use as a prensentation layer? Do you create a lot of usercontrols for this? I prefer usercontrols over xslt, but I'd like to hear other people their opinion.

really interesting thread. 

Paul mentioned, NHAML. I'm wondering are many of you using view engines with Umbraco. Are there many implications.  I've heard good things about spark. Obviously it's wise to keep up with the MVC side of things. ( sorry a little of topic, but related to presentation layer ) 

XSLT is fantastic when used correctly - presentation only and with a minimal of conditional statements.

The power of XSLT in Umbraco lies in the power you get from XPATH + all data cached = extremely fast results even on complex queries where L2U performance would be a joke in comparison. 

A true Umbraco ninja is not religious and use the tools that fits the job. Personally I'd use L2U where I'm currently using the NodeFactory. Ie. when I have the need for a presentation using .NET (99% when doing CRUD operations and afterwards needs to update results on the page).

But depending on the data provider you're using full CRUD operations may not be available with LINQ to Umbraco.

I have another question about Linq to Umbraco. Will it also be faster as the current api? In the current situation if I want to fetch 10 properties Umbraco is going to execute 10 queries each for 1 property. Will I be able to fetch all these properties in 1 single query? Can I get data which is stored in both a Node (published data) and a Document (database data)?

Linq - to - Umbraco: How use it? Is it possible to use in admin backend ( XSLT area ) or in code behind only?

is working on a reply...