I am new to Sharepoint and I want to make sure I am on the right path.
I am in a highly restricted environment and would rather do this in Visual Studio but am currently in the position where I have to try to get this to work using just the web interface and Sharepoint Designer.
I have created multiple lists that I plan on using in a relational way. I have designed this to mimic a relational database.
I have been able to link these lists for multiple item views and single item views, but need to be able to create items and modify items and so I need to be able to also link these lists and use them in a form.
Is this even possible?
If not, how do I handle updating these items?
Lastly.....
Am I going about this all the wrong way?
Thanks!
Tim
It is possible to do so using visual studio, not sure about SharePoint designer. I've been doing something fairly similar for a client myself however I am able to use visual studio to develop my features and even then it's been a pain.
Part of the issue is that various controls in SharePoint make the assumption about query variables and their meaning to the control (the ListFieldIterator comes to mind on this one). Trying to edit two different list's items on a single page is possible but I don't think it could (or should) be done through the desinger.
Can you get away with two separate forms/pages? If so that makes life much easier where you could do some kind of linking/forwarding between the pages. If you have to have a single page that represents both lists and their many items things get much more difficult. For the later you will almost certainly have to use Visual Studio since you will have to handle quite a bit of the server side logic.
Depends on how restricted you are. If you have access to the server via RDC, you could create these lists bases on a custom schema. All of this can be done using notepad.
A possible solution (that i've heard of but never tried):
a) Create your feature folder, and 2 schema files
b) Get a copy of a basic list schema, engineer it to match your requirements.
c) At the bottom of the schema, you can specify which aspx page is called when i) editing ii) viewing the list. Look at the default out of the box page that is usually referred to, make a copy (customblabla.aspx) and point your list schema to that file (obviously store it along with the out of the box aspx file.
Since you have control over this aspx file, you may able to tweak it do exactly what you want.
Sorry if this doesn't work...
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'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 noticed that sitecore has the option of exporting users in an Excel format.
I need to have similar functionality for exporting 'participations', (a users can enlist to take part in an 'event', and if their entry is approved via a sitecore workflow, a 'participation' item is created in the content tree)
Since mostly everything in Sitecore is in essence based on items, and I want to export items to Excel, my question is - what are some of the best ways of doing this?
Questions:
Is there a way to re-use this functionality for regular items?
Would it be a good idea to create a custom admin page (any tips on doing this?) which has some custom code that reads the items from the database using the API?
are there sitecore plugins/shared source projects that can help me achieve this?
Or does anyone have a better idea? - would it be better to just store the participations in SQL? I'm mostly doing it this way because I want to make use of the 'free' functionality offers, for example workflow, but if that leads to me using anti-patterns please shoot me ;)
Link is different now: https://marketplace.sitecore.net/en/Modules/Advanced_System_Reporter.aspx
P.S. Couldn't leave a comment to original answer as I don't have enough reputation. Oh well :)
Found a most excellent shared source module which does exactly this (and much more)!
Basically it allows you to configure (and easily extend, if you need to) any kind of table based report on 'items'.
The report module shows up as an application in the sitecore menu (like the user manager tool) and comes with features such as xml,csv, xls export. It's also really easy to set up, once you get the hang of it.
http://trac.sitecore.net/AdvancedSystemReporter
Recently, we came across a severe problem in production farm with the Content Types. I would like to explain the background of this problem first.
We have nice working feature for Content Types installation in production and test farms. We developed and deployed (using wsps) this SharePoint feature in Visual studio. We are using the publishing pages using page layouts and Content Types to help content editors to quickly publish the web pages. Unfortunately, some Content Types and site columns have been manually updated/added by some people in the production, so whenever I (developer) make some changes to the existing Content Types (using Visual Studio and feature activation/deactivation) , SharePoint removes one or two columns (during feature activation/deactivation) from Content Types; or the columns which have not been added in a best practice way. I think the best practice is to update Content Types using Visual Studio.
Now, I wish to ensure that site columns shouldn't get removed from Content Types upon feature activation/deactivation.
Note: Our feature for Content Type activation/deactivation doesn't hold any activation dependencies in the feature.xml
Recommended Approach
Based on all these factors, my suggestion would be to:
• Create two Features: one for the original markup and one for making changes. (Or you can put them in the same Feature; I just want to differentiate between where you do what.)
• The original Feature should contain the CAML for Site Columns and Content Types. This ensures the IDs have been assigned ahead of type and remain constant.
• If you want to update a Site Column by changing nearly anything about it except its Field type, do it using a Feature Receiver. By doing this, you can call the Update method and pass in a boolean indicating if you want all the existing assets in the site that inherit from this to update to, (something you couldn't do via the CAML.)
• You can also add an existing Site Column (that you provisioned via the CAML feature) to an existing Content Type (that was provisioned via the CAML feature). This is helpful if the Column was not part of that Content Type before, etc.
• In a scenario like the one I just mentioned in the last bullet point, it's necessary to deactivate and reactive the CAML feature (to provision the new assets) before calling your Feature Receiver. What will this mean for the site? Since all the Site Columns and Content Types in the lists in the site are using the same ID's as the ones provisioned in the Site Collection root, removing its parent from the Site Collection won't change that. It might leave it orphaned temporarily, (i.e. there will be no relationship between that item and an item in the Site Collection root, but it will function the same way it always has, since it's really a fully-functioning copy of the original item) until you reactivate the Feature that puts the item back in the Site Collection. It's like the parents are going on vacation when you deactivate the Feature, and are coming back home when you activate the Feature again.
You have a choice when it comes to how you maintain the CAML and the Feature Receiver, since you have two scenarios: existing Site Collections and new ones.
• You could make a policy that every time you write code in your Feature Receiver to update a Site Column or Content Type, you have to make the change in your CAML as well. That would mean that every time you activated the CAML Feature in a "fresh" Site Collection, the CAML would be up-to-date and accurate; there would be no need to run the "updater" feature. (In your Feature Receiver, you should make sure you do some extra checking to make sure a Site Column doesn't already belong to a Content Type before adding it, etc. in case that change is already in place before the code executes.) This approach means you only have to execute one Feature when creating a new Site Collection, but it also means you're maintaining changes in two places: in your Feature Receiver for making changes to existing sites, and in your CAML for new sites. It's a cleaner approach, but also contains an element of redundancy, which always leaves room for human error.
• The other approach is to simply assume that every time the base CAML feature is activated, you're always going to execute the Feature Receiver. This approach says the only time you'd change the CAML is to add a new Site Column or new Content Type; otherwise, all the changes happen in the Feature Receiver. This approach reduces redundancy, but also means your Feature Receiver code could get quite large with all your changes over time, and it could leave your CAML as very much "legacy" over time.
Src: http://blog.beckybertram.com/Lists/Posts/Post.aspx?List=eb3e1762%2Dbab0%2D4e96%2D8bc5%2Dd67d6e6bfd44&ID=18
Updating Content Types is still one of the underdeveloped portions of Sharepoint which sometimes causes trouble, especially in Content Deployment scenarios.
The best thing in your case would be to always avoid making any changes to content types by hand (using UI)
Whenever you are installing the content type, make sure that you remove the previous one and then install the new one. (Sometimes its not possible due to pages being already created out of it).
My current approach to deploying content types is to do as much as possible using code rather than CAML. That way it is easy to fully control the logic of updates, including ensuring that changes made manually don't cause conflicts. I have the structure defined as attributes on an interface I also use for strongly typed list access, but there are several other ways you could do it.
The only piece that isn't available in the API is setting a specific content type ID, so you need to have a caml file for that, but it's a small/simple file, doesn't try to make updates and is only referenced from a feature that will also run the update code.
Is there a way to extend the SPGridView control in a webpart such that a user can select the columns that they want to display? Kinda like when creating/modifying a view for a list?
Thanks
SPGridView is not sealed so certainly it can be extended with this functionality. You would need to build your own data store of what users have chosen (a SharePoint list should suffice), make the UI modifications, etc.
One thing I've found when trying to extend the provided SharePoint controls is that even though most aren't sealed, often they aren't designed to be extended either. In some cases the members are obfuscated as well which in some cases can put an end to extension plans.
Make sure you research this as much as possible with some quick proof of concepts before devoting to this development. You may find it's necessary to write your own control from scratch (or find another standard ASP.NET control that provides this functionality and hook it up to a SharePoint data source).