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.
Related
Lets say for example, I have a list of products that each have it's own page... in what way can I create a single page that will list each product as it's contents as a list (with hyperlinks)? Not really sure how to do this directly in Orchard - or will I need to create a custom page / widget? Thanks for any help... new to Orchard and not sure how to tackle this.
You have a couple options. I believe the Orchard gallery at orchardproject.net has a module called Simple Commerce that may solve your problem. (it's simple so it might not)
(In the following section, I've tried to boldface the terminology words that are 1) are crucial to understanding how to use Orchard and 2) helpful in finding your way around the dashboard)
Another option may be first creating a Content Type--probably one named Product with some Fields describing an individual product. Price, SKU and description come to mind, but you'll be better able to describe your own products. Each Content Type in Orchard can be associated with any combination of Parts. You may have to research which ones you actually want for an individual product, but I'd recommend:
Body (this could replace the Description I suggested above) You could include any amount of HTML/script in this section to make your individual product pages look fancy!
Common (this has to be added when Containable is used)
Containable (this will allow the items to be listed)
Route (so you can link to a specific product)
This gives each product its own slug (URL)
Tags (to allow products to be categorized)
Now, you need to create a new List from the dashboard so you can display the products together (and inherit other features like pagination, etc). Be sure to select the Product Content Type in the Contains drop down list.
Then, you can start creating your Content (your Products) one by one. In the dashboard, click the new Product item and describe each new piece of Content.
Finally, you can link directly to this new List using the Products List's *slug*. You could (and might want to) add the Products List to your main navigation menu. Clicking the Products List and checking the "Show on main menu" box will automagically add a navigation button directly to this page. You could, of course, link to this List from anywhere using the slug (also found on the list's edit page)
This page, from the Orchard documentation pages describes more things you can do with a list of content like modifying the layout of the list, placing content fields in different places and even converting your products to widgets which you could use to display some promotional product offering in a special spot on your site.
I highly recommend reading through at least the documentation provided on the Orchard site to get a good grasp of what this CMS can do out of the box and what you would need to write custom code to accomplish (which you could do in this case, but Orchard can handle it out of the box)
Hope this helps!
Two ways to do this:
http://orchardproject.net/docs/Creating-lists.ashx and http://orchardproject.net/gallery/List/Modules/Orchard.Module.Contrib.Taxonomies
short: A listview webpart contains a table with an ID composed of two GUID's, how do I find these?
I am working on adding some additional behaviour to a standard sharepoint listview-webpart.
Preferably I don't want to actually edit the webpart itself. I want to put javascript in a helper webpart to add some onclick events to the table rows which pass the values of the id and status columns to the helper webpart, which then displays some buttons depending on the row's status.
I searched around to see how others tackled this problem, and usually they use the webpart container div with ID WebPartWPQ _n_". The problem is that these webparts are going to be used on lots of sites, and I have no way of knowing the value of _n_.
A bit further down in the hierarchy is the main table of the view, and it also has an ID. In my test-case: {BF3FB0FA-7E7F-4920-A326-B5E46826B693}-{BD0777BD-455D-4554-A80E-8A11D990D1A5}
I figured these two guids must stand for something and could possibly be looked up.
So I went on a search through Sharepoint Manager to try to find those GUIDs, but I can't find them. Neither is the list ID, nor the original View ID, nor the web ID or the site ID.
So my question: Does anybody know what these ID's stand for, and how I can find them with my webpart code?
Have you considered using XSLT to customize the output of the webpart? You could then customize the output HTML and include any identifiers you wish so that you could reference them in your javascript. This is a pretty good description of how to do this: Overriding the presentation of an XSLT List View Web Part.
Our company is split into divisions. These divisions work for client companies and are then further split into account teams that work on projects for a product of the clients.
So the structure goes Division > Clients > Accounts > Projects. And this is mirrored in the setup of our sharepoint installation. At each stage from Division to Account there is a subsite. Access to each subsite is controlled by AD groups and on each subsite there is a 'latest news' announcements list
What we want to do is have a 'wall' of announcements that feeds through so that each user can see on the top-level site all the posts in all of these anouncement lists, but this must be filtered using the AD groups that they are a member of so that confidential information isn't shown to someone who shouldn't see it.
Can anybody think of a way to do this?
Let's see - are those lists split accross site collection? With what tool you want to accomplish this?
You have several options (if you are within a site collection):
Use Content Query Web Part to
aggregate list items. You can
customize it to display fields
you like the way you like.
You can use SharePoint Designer.
Using Object Model/WebServices: Use
SPSiteDataQuery class to query
multiple lists at once and then
SPGridView to display data.
As you have a MOSS build, you could
even use CrossListQueryCache.
It's also a cross list query that
has builtin caching and audience
targeting. Be sure to read this to be sure caching is working.
If you want to aggregate between multiple site collections, then you will need to write code that get's all your SPSite objects and execute SPSiteDataQuery on them.
Maybe you can find out some additional information on Rollup of all Tasks of a Recurring Meeting in SharePoint
Here is how we are doing it.
Set up a content type for each level of announcement. We have national, state, district and the basic site level announcements. Therefore I have 1 national content type, 10 state content types (because we are in 10 states) and 1 content type for each district. All of these content types inherit from the base Announcement type with no modification.
I added a content query web part. I exported it. I edited the XML in the .webpart file to point to a new custom ItemStyle_Announcements.xsl file I had created. I import the modified .webpart and delete the default Content Query Webpart.
I modify the ItemStyle_Announcements.xsl to create the structure and divs I need for the styling. I add styles to the default style sheet I have already created for my site to get the look and feel I want. (I happend to have two styles for these, one featured/most recent item which is big and full, then a listing the next 10)
I find an announcement list that will possibly post to the national new. I add the content types as needed. Now the end user can choose what scope of announcement they want from the New menu.
This remaining issue is that right now, the States and Districts must have TWO announcement webparts on their home pages. One that lists everything local to that site (regardless of scope) and one that has unit announcements aggregated from the other sites in the same state / district.
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.
I want to show the documents in my document library grouped by category. The category is a lookup column that I added that allows for multiple values. Unfortunately this breaks the "group by"-functionality completely. Is there a programmatic solution to this problem?
There is one way... It's complex and ugly - but it should work :)
It is possible for you to write you own view for at list (HTML, JavaScript and all). The VWSTYLES.xml file in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\GLOBAL\XML folder, contains the HTML and JavaScript for the default SharePoint view styles - getting your inspiration from this, you can create your own view style, where you can do anything you want!
The problem is, that SharePoint don't have any way to deploy your custom view style - this is where the ugly part comes in - you have two options for deploying your view style.
Add you code directly to the VWSTYLE.xml/Edit a copy of it and override it with a feature
Pros:
You will still be able to edit the
view from the SharePoint interface
Cons:
You override a default SharePoint
file - your work can be overridden by
a SharePoint update.
Your view style will be available on every list in SharePoint.
Create your view programmatically on the list
Pros:
You don't override any default
SharePoint files.
You can control which list uses your
view
Cons:
You wont be able to edit the view thru the SharePoint interface
I've used method 2 a couple of times myself - and it works... but it's not pretty! :)
I don't think what you are trying to do is possible. When grouping items/documents, you display them in different groups based on a grouping value. I don't think SharePoint has support for adding a single item to multiple groups. With multiple values in the grouping field its' impossible to know which group to add the item/document to. I am not sure if this is an error or if it's by design.
Thomas is correct, this is by design as the item would have to appear multiple times in different groups. It is worth noting that this is possible via the web services, however.
See why I was getting duplicate rows from the sharepoint lists web service
And no, I've no idea why the lists webservice will do it, but the API won't.
Check out this link as well. Access supports this functionality without having to do much ugly code. http://office.microsoft.com/en-us/access/HA012337221033.aspx
So here is a sort of hack that has worked for me, no guarantees though. While your column (Office in my case) has allow multiple values enabled, fill in all of your data as needed. Once done, go to List Settings, click the Column "Office", and turn off allow multiple values. SharePoint will pop up a warning about how this data may be lost (never happened to me). Hit okay, then modify the view you want grouped, "Office" should now show up on the drop down of columns to group by. Finished result will result in your groups (and or sub groups) showing up just fine.
The only qualm I have is that instead of having an item show up in both Group A B because it had both field A and field B checked in Column X, it just creates a new group, Column X: A; B. So in my case, I have staff in both Beaufort and Orangeburg Offices, instead of having those staff in both groups (preferable) it creates a new group as below: