I would like to build a webpart that is going to display list content coming from different site collections (but the same content type).
I wanted to use the SPSiteDataGuery to create the datasource of a SPGridView for instance, but it appears to be working only within the same site collection. Do you have any idea ?
The best performing solution would be to use the search object model. Look into FullTextSqlQuery. You can filter based on content type easily enough. The downside in using this technique is obviously there is a delay until the content is crawled. The performance over anything else however will be significantly better. Waldek has some great articles on comparing the alternatives.
Related
I have a document library set up with multiple different categories of document, and I'm using a metadata column to differentiate between them.
I want to be able to display two different document library web part on a page for different categories of file side by side. This is simple for one category, I just set up a list view filtered by the metadata column, but when I add a second web part alongside the first, it breaks the first one.
I have no idea why this is happening, but it seems like SharePoint isn't happy with pulling two sets of data from the same document library.
When I am editing the web parts, I can get them to both display the documents I want, but then when I click save, the first web part empties.
Not sure what other information would be useful for diagnosing or helping with the problem, so if I haven't given enough detail let me know. I am familiar with SPD as well as developing through the web interface, so if this needs a more complex solution that's fine with me!
Having spent some more time playing around with this, it struck me that I could probably achieve what I wanted using something other than a Document web part, and I was right.
Instead of using the somewhat inflexible document web part, I created a content query web part which only searched within the document library from my site, and filtered by the metadata column.
This way I can create as many queries as I like and they don't interact with each other in weird ways. It also has the advantage of being significantly easier to customise the output without needing to resort to SharePoint Designer.
Content Queries are the answer!
I am kind of new to SharePoint. I am learning it on the go and learned about the concept of pagelayout and publishing features on the site. But I am not really 100% sure what is the difference between a WebPartPage, SitePage and PublishingPage. I kind of know what all these pages be used for, but what I not get is: why do they need to separate all these pages?
I think we can just get a publishing page and have all the feature there including webpart and everything else (with our choice of PageLayout). However I dont see a way to use a pagelayout on a particular SitePage.
Is there any particular reasons for using either one of them? Even though it seems like one of them can serve as all of them?
You should use page layout when ever you know the page structure. For example you are running an online news paper. You want to show the news to the users into three columns. First column is for menu, second column is for news content and third column is for advertisements. Now in your daily usage this layout is common. So you can use this page layout for entering the news. After creating the page layout you can make it as a default to your pages. Page layout is nothing but the structure of a page simply!!
A webpart page does not have a field for content directly on the page like a SitePage has. A Publishing Page is like a SitePage, but requires extra fields for dealing with the publishing extra features.
Using a single layout for all three risks being confused as to why one page does not work the same as another when it has the same layout (the difference would be the underlying features are different.).
I will make a comparison with cars. There are three type of cars, each is better suitable for a certain purpose: tractors for farming, buses for public transport, light cars for private transport. You could use a tractor for all the purposes above but it's not ideal.
"One of them can serve as all of them". This is not true in their current implementation. I'll give you one example: prefer Web part pages against Publishing pages to better control content added by contributors in an intranet. There are many other examples.
I've got a tricky situation I'm trying to determine the best way to solve. I'm a VS developer who is learning SharePoint so it's a little frustrating to me when what I am trying to accomplish could easily be done with code and a db.
I have three lists, a parent and two children list that are linked through lookup columns. The client actually wanted everything in one list but due to SharePoint column type limitations I had to split the data into the three lists, there are over 300 fields. The client wants to see all the lists together in one view and be able to filter and edit groups of items.
I have successfully created a new data source linking the lists and can display that on one of my pages to view. After some research however I have learned that I can't create a datasheet view from this linked view due to limitations in the Office componets that SP uses. Which makes sense.
The business need is for the client to filter the three lists based on criteria they select from either list A AND list B and list C to get a group of items, they make the updates and save the changes back to the 3 lists. They prefer to do this in datasheet view because this mimics the excel spreadsheet that they are currently using that this website will replace. They will potentially be updating between 1-30 items at a time using this, which is why they prefer the drag and copy functionality.
I was thinking of two options: trying to create some kind of custom web part that has a gridview of all the columns in edit mode that they can filter down to their items and make their changes. Then I would have to loop through the fields and make updates programmatically. I also saw on this site jQuery.sheet, that looks like it may be a good solution if I go this route instead of gridview.
Or have a modal window with the columns listed, have the user select what they want to filter to, then redirect to a page that shows the three lists in their own DSVs. The user would have to make updates in the three separate views. Then I would use workflows to synchronize the lists after they had made their changes.
I always end up trying to do things programmatically since I am still largely unfamiliar with SP and only seem to hit its limitations instead of its strengths. Has anyone tried to do something similar to this? Or do you have any suggestions as to the best way to accomplish this? Best practices? I appreciate all thoughts and comments! FYI I've also posted this on the MS SP forums as well to cast a wider net...
Thanks,
Sabrina
In this case, you are better off going with a custom solution. A webpart would be an excellent choice for delivering your custom interface.
A dataview webpart will do the job, but if you feel comfortable with the jQuery solution it would make for a nicer interface.
In your code, treat the lists as you would a database and isolate it from the logic and interface code within the webpart.
I'm using a SiteMapDatasource in a tree view to display a simple hierarchical site map. I need to filter this map so that it only shows links to sites and sub sites, and not any links to things like lists, document libraries, etc.
thanks!
Without knowing more about your situation, would it be possible (assuming these are XML type data structures) to use some kind of XPATH query to pull and filter information? Perhaps you can transform it via XSLT? If you can post what things look like, it might help to give a little more insight.
There is always, the possibility of using LINQ on the data source...
We want to create a common document library on a certain site level and then create views on that document library in the different sub sites?
Is that possible in SharePoint?
Can it be done declaratively?
Rine
I would recommend to use the DataFormWebPart (requires SharePoint Designer to insert and customize the DFWP, the result can be exported to a feature)
The following blog entry lists a suitable SPDataSource sample:
SPDataSource and Rollups with the Data View
Good Luck!
Not out of the box. You will either need a third party "roll-up" ("roll-down") web part or you will need to write your own. OTB, views for lists/libraries are only visible at the current site level.
That being said, roll-ups (in one form or another) are probably one of the most common 3rd party seller for sharepoint (just a guess). In fact, I would bet there are several free projects out there that you could use (Check codeplex). You should have no problem finding one that meets your needs.
My suggestion would be to write your own, as this would give you some real good experience using the SharePoint object model and there really are no complicated concepts. Once you get past being able to do site navigation and accessing list data through the OM, you pretty much have all the tools you need.
Good Luck
I have found a cheep and great webpart which does a documents rollup from all subsites with search, paging and sorting functions.
http://speasysolution.miiduu.com/es-sharepoint-2010-documents-rollup
i used it, its simple and powerful