Geeks With Blogs

News





The SharePoint Hillbilly Fewer Big Words... More Pretty Pictures...

So, I continue to try to come up with diagrams and information to help new SharePoint developers wrap their heads around this SharePoint beast, especially when those newer to development are on my team. To that end, I drew up the below diagram to help some of our junior devs understand where/when code is being executed in SharePoint at a high level. Note that I say “High Level”… This is a simplistic diagram that can get a LOT more complicated if you want to dive in deeper.  For my lesson it served its purpose well. So, please no comments from the peanut gallery about information 3 levels down that’s missing unless it adds to the discussion.  Thanks Smile

So, the diagram below details where code is executed on a page load and gives the basic flow of the page load. There are actually many more steps, but again, we are staying high level here. I just know someone is still going to say something like “Well.. actually… the dlls are getting executed when…”  Anyway, here’s the diagram with some information I like to point out:

image

Code Scope / Where it is executed

So, looking at the diagram we see that dlls and XSL are executed on the server and that JavaScript/jQuery are executed on the client. This is the main thing I like to point out for the following reasons:

XSL (for the most part) is faster than JavaScript

I actually get this question a lot. Since XSL is executed on the server less data is getting passed over the wire and a beefier machine (hopefully) is doing the processing. The outcome of course is better performance. When You are using jQuery and making Web Service calls you are building XML strings and sending them to the server. Then ALL the results come back and the client machine has to parse through the XML and use what it needs and ignore the rest (and there is a lot of garbage that comes back from SharePoint Web Service calls).

Marc Anderson made the excellent point that this is not always true. I was thinking along the lines of retrieving lots of data for a list and building a DataViewWebPart with it instead of doing the same thing in jQuery by calling SPServices to return hundreds of rows of data and building a fancy report out of it. You CAN get better performance using jQuery in the some situations because you can delay calls for data until you need it, limit data you want to retrieve with CAML and user input, and not execute a web service call if it’s not needed. Marc’s quote was “Good architecture is good architecture”… wise words…

So.. let’s say it another way… You can get better performance with jQuery over XSL if you can take advantage of the following:

    • Delay execution of code to retrieve data until it is needed
    • Avoid calling a method to retrieve data entirely
    • Lesson the amount of data retrieved by user selection and CAML

Thanks again for the input Marc.

XSL and JavaScript cannot work together in the same scope

Let me clarify. JavaScript can send data back to SharePoint in postbacks that XSL can then use. XSL can output JavaScript and initiate JavaScript variables.  However, XSL cannot call a JavaScript method to get a value and JavaScript cannot directly interact with XSL and call its templates. They are executed in their scope only. No crossing of boundaries here.

So, what does this all mean?

Well, nothing too deep. This is just some basic fundamental information that all SharePoint devs need to understand. It will help you determine what is the best solution for your specific development situation and it will help the new guys understand why they get an error when trying to call a JavaScript Function from within XSL.  Let me know if you think quick little blogs like this are helpful or just add to the noise. I could probably put together several more that are similar. 

As always, thanks for stopping by, hope you learned something new.

Posted on Monday, February 21, 2011 3:53 PM | Back to top


Comments on this post: SharePoint For Newbie Developers: Code Scope

# re: SharePoint For Newbie Developers: Code Scope
Requesting Gravatar...
I agree with Marc's point. XSL just converts xml to html, and you still need to send it over the wire. Whether there is garbage or not just depends on how well you did the data retrieval part.
Left by Christophe on Feb 22, 2011 2:27 AM

# re: SharePoint For Newbie Developers: Code Scope
Requesting Gravatar...
I agree with Marc too, I am trying to make the point that if you rely on the client to retrieve hundreds of rows of data, do calculations on that data, and then build the html (all in the client) it's going to be slower than doing a DataViewWebPart that does the same thing. Again, with the caveats added.

I do appreciate the feedback I've been getting offline too. I'm trying not to muddy the waters too much. Yes, there is client side XSLT, I've even been told it's possible to execute JavaScript on the server, but these are the exceptions to the norm.

Every developer needs to understand there will always be exceptions, but learn the 80% first and be accepting when the 20% comes around. If you try to master it all at once, you will not be a happy camper.
Left by Mark on Feb 22, 2011 7:59 AM

# re: SharePoint For Newbie Developers: Code Scope
Requesting Gravatar...
Well, Mark, that's where I do not follow you:
- XSLT: retrieve data; transform to html; send hundreds of rows of html.
- jQuery: retrieve data; send hundreds of rows of xml; transform to html.

I think what you're missing is that with jQuery you send less html with the page, because the html will be built directly in the browser.
Of course, if your purpose is just to show aggregate information (e.g. number of tasks due next week), then XSLT processing will be better. But in standard cases where you display list items, there is no real gain (basically it's just about sending table rows vs. xml rows over the wire).
As for calculations, JavaScript/jQuery will offer you more options than XSLT, especially with SharePoint because you are restricted to XSLT v 1.0.
Also, remember that IE 8 is 3 times faster than IE 7, and IE 9 is 5 times faster than IE 8. The trend is definitely in favor of JavaScript/jQuery.
Left by Christophe on Feb 22, 2011 7:59 PM

# re: SharePoint For Newbie Developers: Code Scope
Requesting Gravatar...
This is where we disagree Christophe, and if I were more ambitious I would actually write a test to hopefully prove I'm right.. for now I have to use my Arkansas logic...

jQuery - Retrieve hundreds of rows of data wrapped in messy XML and extra fields you don't need all passed over the wire, then depend on the client computer (which could be ie6, 7, 8, 9, sarari, chrome, firefox, etc...) THEN convert it to html to display on the page...

OR

XSLT - Retrieve hundreds of rows of data (on the server) transform the data to html (on the server) and send less data across than if you had sent the raw XML for a SharePoint Web Service call.

Of course there are instances where jQuery is faster, but there are definitely instances where XSLT is going to be much faster...

Tell me.. Which of these has more data:

XML from a SharePoint Web Service Call for ONE row which then must be converted to HTML on the client:
<rs:data ItemCount="1" xmlns:rs="urn:schemas-microsoft-com:rowset">
<z:row ows_Title="Elmer@Fudd.com"
ows_MetaInfo="4764;#"
ows__ModerationStatus="0"
ows__Level="1"
ows_ID="4764"
ows_owshiddenversion="5"
ows_UniqueId="4764;#{2272A40C-0DA5-4C0D-938D-BFF3AF9C8ACF}"
ows_FSObjType="4764;#0"
ows_Created="2009-12-12 12:55:10"
ows_FileRef="4764;#sps/Contact/test/Lists/Issues/4764_.000"
xmlns:z="#RowsetSchema" />
</rs:data>


OR

<tr><td>Elmer@Fudd.com</td></tr>

It's pretty obvious to me...

I'm NOT saying jQuery is never faster, or even not often faster, but there are MANY instances where your get much better performance.

Left by Mark on Feb 22, 2011 9:11 PM

# re: SharePoint For Newbie Developers: Code Scope
Requesting Gravatar...
What's obvious in your example is that your Web service call returned a lot of garbage. I assume this is the point Marc was trying to make. With a clean Web service call, you'll just return what you need (the title).
Left by Christophe on Feb 22, 2011 9:19 PM

# re: SharePoint For Newbie Developers: Code Scope
Requesting Gravatar...
That is a Query where the only ViewField specified is Title. You are supposed to be able to suppress the other fields, but many times it ALWAYS returns that much data, even if you specify View Fields Only...
Left by Mark on Feb 22, 2011 9:27 PM

# re: SharePoint For Newbie Developers: Code Scope
Requesting Gravatar...
I see. So now it's my turn to say that if I were more ambitious I would definitely dig into this... or forward the question to Marc ;-). I agree that if parasite metadata are returned it's not really cool.
For the record, I often use jQuery with other standard data retrieval methods - owssvr, RSS, or REST (in SP 2010). AFAIK they don't have the issue you're reporting with Web services. For example the image rotator featured on my blog is built on owssvr.
Left by Christophe on Feb 22, 2011 10:07 PM

Your comment:
 (will show your gravatar)


Copyright © Mark Rackley | Powered by: GeeksWithBlogs.net