3

I'm adding a very simple XsltListViewWebPart to an application page. Like so:

XsltListViewWebPart lvWebPart = new XsltListViewWebPart { ChromeType = PartChromeType.None, ListUrl = "/somesite/list" };
Page.Controls.Add(lvWebPart);

Everything works fine (I can download files, create folders, choose different views, etc.) - but the links of folders have the wrong href: they always point to the root web!

See these examples: enter image description here

As you can see, the document correctly links to ../sites/sr/doclib/mydocument.docx however when looking at the folders they forget the context they are currently in (they are in http://../sites/sr/_layouts/../../..Detail.aspx?RootFolder=..., the important part being /sites/sr/). They try to go to the _layouts folder in the root site collection context -as shown above: http://../_layouts/../../..Detail.aspx?RootFolder=...

Or again summarized:

  • The application page location:
    • http://sp/sites/sr/_layouts/my/application/Detail.aspx
  • The list/doclib I'm accessing
    • http://sp/sites/sr/mylist
  • The URL for folders inside XsltListViewWebPart
    • http://sp/_layouts/my/application/Detail.aspx?RootFolder=...
  • The URL for folders as they should be
    • http://sp/sites/sr/_layouts/my/application/Detail.aspx?RootFolder=...

Here comes the kicker: When using a ListViewWebPart, everything works like it should! So instead of the XsltListViewWebPart above I just use a ListViewWebpart - and folders work, the context is taken into account the the folders have the URL like I want (http://../sites/sr/_layouts/../../..Detail.aspx?RootFolder=...

I tried setting the WebId Property on the XsltListViewWebpart hoping it would set the context, but no luck. I'm now thinking that either I configure it wrongly or the new SharePoint 2010 XsltListViewWebPart has a bug - as the same code works for a ListViewWebPart on the same Application page.

I hope somebody can verify this issue.

Improve this question
6
  • Just don't use OOTB webparts on layouts pages. Actually there are also other bugs which you haven't noticed yet. OOTB webparts and webpartzones on _layouts pages are officially not supported by MS, they were not intended for such usage. Use site pages. You can add code behind there by adding custom control to the page layout. In most cases, site pages can successfully replace application pages, and often even add some benefits.
    – Andrey Markeev
    Commented Oct 21, 2012 at 14:29
  • "OOTB webparts and webpartzones on _layouts pages are officially not supported by MS" Could you back that by some official MS legalese? Never heard that before and didn't know about that. It's just easier creating a layouts page than creating a site page and a special page layout just for that - imagine you would have 10 different pages = 10 page layouts. Good information though!
    – Dennis G
    Commented Oct 22, 2012 at 17:07
  • Why would you want to create page layouts for site pages? :) Do you know that SharePoint Foundation doesn't have any page layouts at all (because page layouts comes from Publishing Infrastructure)? And 95% of SharePoint Foundation site is, wow, surprisingly, site pages :) Site pages can be created even detached from masterpage, if it is necessary :)
    – Andrey Markeev
    Commented Oct 23, 2012 at 7:53
  • For example, on MSDN you can find: "... A site page can also host features such as dynamic Web Parts, and Web Part Zones. Application pages cannot do these things." msdn.microsoft.com/en-us/library/ee231581.aspx, and also it is mentioned here: msdn.microsoft.com/en-us/library/aa979592.aspx
    – Andrey Markeev
    Commented Oct 23, 2012 at 7:58
  • 1
    Ahh sorry I meant just the page itself, i.e. page markup. Ok you can struggle it on, but please keep in mind, XsltListViewWebPart has many bugs (not only this one) when you use it on _layouts pages. This is my experience (and not only mine) and it was actually rather painful and costly in terms of time :( I have the links but unfortunately the discussions were held in russian so I'm afraid they will be of not much help.
    – Andrey Markeev
    Commented Oct 24, 2012 at 12:26

2 Answers 2

Reset to default
4

In brief, just don't use XsltListWebPart on Application Pages.

And here are some summarized explanations:

XsltListViewWebPart and other OOTB SharePoint webparts (especially complex ones), apparently just aren't supposed to work in Application Pages environment. In other words, they weren't tested there and thus their operability is not guaranteed.

This can be indirectly confirmed by reading at least the following MSDN articles:

.. A site page can also host features such as dynamic Web Parts, and Web Part Zones. Application pages cannot do these things.

Also it is stated in MS course 10232.

Concerning XsltListViewWebPart (XLV) in particular, I heard of multiple problems while using it from Application Page, and experienced some of them myself.

For example, if you customize XLV using XslLink property, XLV will fail to cache the xsl file, and as a consequence, ECB and corresponding buttons on Ribbon will not work. In logs, you will get the following exception message:

Attempted to use an object that has ceased to exist.

Also, you can check out the following question for another example of problems with OOTB webpart on application page (ListViewWebPart, this time):

Improve this answer
0
1

First, I think Andrey hit the nail on the head. In addition, you could try to use the ListViewByQuery control on an application page if you are looking for a simple tabular layout of data (i.e. a list). Microsoft does this in the OOB workflow status page (i.e. _layouts/wrkstat.aspx) for display of tasks.

I've not tried it with ECB menus and such, but did use it for Read-Only lists of data. Since it sounds like you are using it for a Document Library with Folders, I am not confident in it working right without lots of code to get folders, sorting, and paging working correctly. It might be worth a shot, though I wouldn't spend much time with it as the Site Page is probably a better way to go with less custom code.

If you go with ListViewByQuery, be sure to review these links for paging, etc:

Improve this answer
1
  • Can't find reference to my original request though: The RootFolder Attribute of the XsltListViewWebPart - I can give the ListViewByQuery control a SPQuery, but no root folder or am I mistaken? Some people are using ugly workarounds for this: social.msdn.microsoft.com/Forums/en-US/…
    – Dennis G
    Commented Oct 28, 2012 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.