Is there a tool that allows querying (and aggregating data from) a library of infopath forms in MOSS? I can't use promoted fields, since some of the items I want to query are in repeating groups which (AFAIK) cannot be promoted. So I have to query the underlying XML.
I realize I can write custom code that iterates through the forms and perfoms a xpath query on each, I just wonder if there is an existing tool or functionality for this?
You can use the lists.asmx web service to retrieve the XML and work with it within reporting services or even within Excel.
Look at using XML as a data source in SQL reporting services
if you export the list to a spreadsheet you should also be able to work as you would any other spreadsheet. It all depends on what you want to do with the information and where it will end ultimately.
You could also look at tying the data into dundas charts web parts
Related
I am having a page with documents loaded in SharePoint 2010. I have three buttons below each documents in the page and they are 'Like','Unlike' and 'Comment'. So whenever people go there and see the documents they can click on any buttons of their wish.
My question is how to take the hit count of these buttons seperately and display it for each document. Is it possible to create a list with having these three columns and handle it using Client-Side scripting. Any suggestions or help is much appreciated.
Each item in SharePoint has a property bag that can contain ad-hoc data like this. You could certainly add additional columns to store this data and update those columns but that does mean that users could easily manipulate the values via the UI. Since the property bag is only accessible via the various API's, you wouldn't have this issue.
For an example of accessing the property bag via CSOM (which would be your best option since I'm assuming you want your users to be able to like, unlike and comment without refreshing the page each time), see this post reading and writing property bag values using CSOM
Another thing to consider for comments is the existing notes functionality that exists in SharePoint 2010 and SharePoint 2013. These comments are ties into the social functionality and may give you a bit more bang for your buck. To show the comments page for a particular list item see this post SharePoint Social Data using Javascript
I am using Visual Studio 2010, SharePoint 2010 with custom document content types and forms. And plan to also use jquery to build the document add/edit/view forms.
I am developing a solution where I want to have a document library where each document uploaded also has a number of external data elements added as metadata.
The tricky part I'm trying to figure out is I want the user to be able to specify and add a multiple number of those same external data elements.
I'm trying to figure out how I represent the data internally in SharePoint. My initial thought is to programmaticly add hidden external fields as the users adds those external selections. But then I also think of simply storing those external elements as non-external text fields but have my own code which performs the external data lookup and validation.
I'm not adverse to significant custom coding, as I'm probably going to need to do a lot anyway since even the user interface is going to be a jquery tabbed form to enable all the external data the user will be able to associate with each SP document.
I've made an attempt to hopefully further explain what I'm trying to do and included that image. Essentially I'm wanting to add 1+ external data relationships to each document, as desired by the user.
It uses just example data. I'll actually have 4-7 different complex relationships much like the example. And the user is permitted to drilldown and select 1, 2 or all 3 of the dropdowns.
Think of it as similar to how here on Experts-Exchange we can add multiple zones to a question.
An example illustration is here: http://flic.kr/p/aFUSJn
Could you simply add a multi-line text column and have the user input the metadata with comma's, then use your code to seperate the data and do what you want with it?
You said you were not adverse to significant custom coding :)
One solution is to use SharePoint content types. The trick is that not all items in a list need to have the same content type.
Therefore, you can do the following:
As the user is selecting the fields he wants to use you generate or select a content type that matchs those fields.
You then add your document to the document list using the content template
You then have all your information strongly typed in SharePoint lists.
We have previously built a system where we generate content types based on xsd files, this worked very well.
let me explain my current situation
i have a SharePoint site lets say it is MAIN, and a subsite lets call it SUBMAIN
in MAIN i have a list called "a" and in subMAIN i have a list called "b"
both lists have the exact same columns,
i need to show the content of both lists (ordered by modified date for example) in one webpart in the main page i know it is possible some how but couldnt get to it.
currently i am showing only the content of list "a" in a content query webpart (i have changed the way it display and added to it horizontal merquee) so it will be nice if somehow i can add contents of list"b" also to the same content query webpart (but if it is not possible in content query webpart its ok, at least let me know what other options do i have)
your help is appreciated
If you are using SharePoint Designer to do this, take a look at this blog.
If you are building your own web part, I would perform two queries on the SPList objects. You can then aggregate, sort, etc. the results however you would like. If you aren't familiar with SPList, you can look here for the MSDN overview.
I've built web parts to display items from 2 different lists, and I did something similar to what Scott Price suggested. I used an SPQuery object for each list and used it to get DataTable objects that I could then use with things like Repeaters and DataLists. You could merge your two tables and do something similar.
The biggest trick for me was setting up the custom templates for DataBinding in a webpart. To do that, I created a custom class that implemented the ITemplate interface and then emitted the HTML for each item from the template class in an event handler. Then, you just create an instance of your template class and set that as the ItemTemplate property of your, say, DataList.
This post and this one do a better job of explaining that approach, but the nice thing is that you have complete control of the markup, and you can style it as you like.
If you're not looking to code your own solution, you might consider this webpart on codeplex:
http://rssaggregator.codeplex.com/
It's actually an RSS aggregator, but since all SharePoint lists have built-in RSS feeds, you can use it just as well to aggregate the SharePoint lists from the different sites.
Another approach is SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM will allow you to configure those two lists to be automatically synchronized to SQL tables at which point you can create a query to join the two. If you have the two lists built off a content type (since they have the same fields) you can actually slam the content type and have both lists in the same SQL table.
I'm creating a new content type for a sharepoint project (MOSS 2007). This content type (Letter Template) needs to contain meta-data that is driven from data outside of sharepoint like, template type (which we define in another db). How can I accomplish this in sp (aside from generating xml files)?
So your letter template content type has a number of fields. The data for these fields is stored in an external database? sounds like a job for the Business Data Catalog (MOSS feature, not WSS).
Another possibility is an Item Event Receiver that connects to the database and retrieves the data. This is definitely not the preferred way of handling this scenario, but may be quicker to implement.
hth,
jt
You can try import that content type into a list in SharePoint and use that list as the source. If the source at the database changes often, setup a job to pull the data into the list periodically.
I need to create some functionality in our SharePoint app that populates a list or lists with some simple hierarchical data. Each parent record will represent a "submission" and each child record will be a "submission item." There's a 1-to-n relationship between submissions and submission items. Is this practical to do in SharePoint? The only types of list relationships I've done so far are lookup columns, but this seems a bit different. Also, once such a list relationship is established, then what's the best way to create views on this kind of data. I'm almost convinced that it'd be easier just to write this stuff to an external database, but I'd like to give SharePoint a shot in order to take advantage of the automated search capabilities.
Proper Parent/Child in Sharepoint is near impossible without developing it yourself. There is one approach to that here: Simulate Parent / Child relationship in SharePoint 2007 with Folders & Content Types
(Note: This concerns SharePoint 2007. In 2010, Joins make this much easier)
Do it in a separate database, create a page(s) with controls that surfaces the data and run search over that. Loses quite a bit of the SharePoint features though.
Otherwise it may be okay to create a custom field control that will allow you to lookup the data in the other list.
The custom field control can be the one to "view" the related data.
I know we have done it for parent child relationships between pages on the same list. Not 1-to-N though.
Tough choice either way.
My vote is "to write this stuff to an external database"
You miss a lot of things in Sharepoint things like transaction support, referential integrity, easy way of updating (compare SQL), reporting (using Reporting Services and a SQL database)... see sharepoint as a way to store documents and simple lists.....
The argument for Sharepoint is if it is a small application, no requirements on support for transactions, no need to import external data etc...
When people say Sharepoint is a development plattform there is a need to define whjat they think a development plattform is.
The latest rumours about Sharepoint 2010 tells us that there will be support for SQL server based lists in next version ..... which I think will at least move Sharepoint in the right direction ....
Take a look at SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM allows you to synchronize SharePoint data to SQL, including any relationships between lists. SLAM, in addition to being very useful on its own, is really a framework intended to allow developers to create their own complex data associations using what we call SLAM type profiles. We have one out-of-the-box type profile which is part of the open source project which actually allows you to make a SharePoint list hierarchical using the nested set model. For more information, see this page on our codeplex site.
I do this a lot just using sharepoint, using a framework called AAA (Activity,Assignment,Artifact), which allows you to use lookup columns to link an assignment or artifact to a parent Activity. You then build a web part page with connected web parts that allow you to filter all assignments and artifacts by activity. For example, click next to a submission in the submission web part, and all of the submission items attached to that submission will show up. Works great.
The other approach that you can look at using is persisting XML with a field in the item. This is the approach used by the Podcasting Kit (on CodePlex) to store things like ratings.
One possible method is to create a submission content type based on the folder content type and a submission-item based on item content type. Then you can store data hierarchically like in file system and also will work default views and search functionality.
Other way is to create lookup field that points to same list (list=”self”). This field will be used like reference to parent item and you will get list that contains recursively related data. To use this data programmatically will be ok but using views functionality will be little bit complex.
It's easy to do using a connected web part.
Create two lists:
Parent (Id, Title)
Child (Id, Title, ParentId)
Create a new sharepoint page, add DataFormWebPart (displaying Parent) and another one for Child, set both of them to filter based on a QueryString parameter (use that Parameter to filter Parent.Id, and Child.ParentId) voila, you can display parent-child relationships. Now, adding children is more difficult, and that's the part I haven't worked out yet.