I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
Related
I am currently writing a Sharepoint Workflow that is activated when a user saves an Excel file to a Library. Now I need to process this file and store certain information to a certain list.
Whats the best way to store configuration settings like the name of the output list, names of the Excel columns that the Workflow needs to process, etc?
I understand that there seem to be a lot of different possible solutions like web config, Properties, etc. But since I am totally new to Sharepoint, I cannot properly assess these methods. Which one is the easiest for me to use?
Thank you.
Edit: A Visual Studio Workflow, written in C#
This article is a good starting point Six Ways to to store settings in SharePoint but personally I would be following the MSDN SharePoint Guidance Library which uses the Property Bag storage for their implementation of a hierarchical Configuration Manager which allows you to do things like a farm wide setting but overridden for certain site collections/sites/lists etc.
We use SharePoint 2007 and have set up a web application with several site collections. One for each of our clients. We'd like to synchronize content in all of the site collections. Maybe having a central repository, then all other site collections get content from here.
I was looking at Lightning Tools Conductor web part and seems a pretty good solution. However, I'm wondering if this can also be possible using the Content Deployment feature to copy a site from the central repository to all other site collections.
I do not advice you to copy and thus duplicate the information from your central repository to the other site collections. You'll lose precious disk space, performance and scalability.
If you have content that is created in a common site collection, you should either use the built-in web services or create dedicated ones to retrieve the content within the targeted site collections.
I usually create cross site collection look-up fields that allows a contributor to pick an entity from my central repository in a visual way and apply the rendering of the content once the page is in view mode.
That might not suit every need but I don't think content duplication is a wiser choice.
Edit : re-reading your question, is there a specific reason why you want to copy a complete site (spweb I guess) rather than specific content inside ?
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
I am creating sharepoint custom solution that will show number of drop down in page. The drop down data is shared in may pages.
I want to persist selected values of the user such that when ever he visit that page or any other page that have same drop down, he should be able to see is saved value pre selected in drop down.
To implement this I have a number of options. Please suggest the best for SharePoint
1)Sharepoint User profiles
2)Sharepoint list
3) Cookie
4) Isolated storage?
Options 3 and 4 here are clientside. But I am looking for any other way that SharePoint provides to save user preferences/personalization information.
Which one is the correct way of doing that in SharePoint?
Thanks
One issue you should be aware of with user profiles is that they are only available for MOSS (as opposed to WSS). In WSS each site has their own User information list. If the solution you are building will need to run in both MOSS and WSS environments, you should plan accordingly.
jt
My instinct tells me to use cookies for this, if it's a fairly simple state you need to persist. This seems to be a part of the UI logic, and I wouldn't bind that to the profile storage.
Pages and web parts have personalization stores as well, but they are generally not shared between instances.
I would go with profile storage, because that's the sort of thing it's there for, although generally when you are writing custom code in SharePoint the idea of best practices kind of gets thrown out the window.
I've built a web part for Sharepoint that retrieves data from an external service. I'd like to display the items in a way that's UI-compatible with Sharepoint (fits in with its surroundings.)
I'm aware of the "DataFormWebPart" but was unable to get one working properly. It requires a valid DataSource and I was unable to build one from the results of a web service call... Part of the problem is that my web service wrappers don't expose the XML return info, rather I have a bunch of deserialized objects. There doesn't seem to be an easy way to turn actual objects into a datasource, or populate a "generic" datasource from object data.
I could use an SPGridView to get the same UI, but the grid control doesn't have much in the way of smarts -and- it forces every field into its own column. I'd prefer to render each list item as a single cell with complex rendering (for instance the way that StackOverflow shows its lists of questions.) I'd also like to get as much of the Sharepoint-standard UI as possible, such as the sorting, filtering, and paging controls.
So, first: Has anyone here written a Sharepoint control that does this, and if so do you have sample code to share? If not: am I overlooking some useful control, whether MS-supplied or available in an external library?
Thanks!
Steve
Sharepoint: Best way to display lists
of non-Sharepoint content with
“compatible” UI?
Take a look at the built in sharepoint web controls:
Microsoft.SharePoint.WebControls Namespace
It contains all the controls used in sharepoint. I'd tell you more, but the documentation is very thorough.
Problem with SharePoint is that there are a bunch of different ways to do this. If your data is not changing too often and is not overly large it may be worth considering entering it into a list for display.
If you have the Enterprise licence it may be worth getting your data into the BDC and using it there.
you may have to convert the objects into xml or use the serialised objects with the XML webpart for display. This still has the issue of custom rendering using XSLT.
Here's a great article that explains how to configure BDC connections to web services using the BDC Definition Editor:
Creating a Web Service Connection by Using the Business Data Catalog Definition Editor
http://msdn.microsoft.com/en-us/library/bb737887.aspx
The best way to do this IMO is to make a Web Part. As a Web Part the UI will be automatically rendered to be the same as the theme the site is using (unless you override it) and it will be able to be placed anywhere by anyone with admin privileges.
Tutorial on making a Web Part
Tutorial on packaging and deploying a Web Part
Example Web Part Source Code
You could create a custom web part and use an SPGridView. You say you don't like it, because it forces every field into its own column, but that's not true. You can create a template (ITemplate) for every column and fully customize what's shown inside it, just like you would using a normal ASP.Net GridView. Using this approach I've added the little "New" images right next to a list item's Title, just like SharePoint does itself.