I am developing a custom SharePoint 2010 Web Part (not visual) in C#.
I need the ability to maintain persistent variables (selected value of a drop down list for example) across postbacks but have it be unique to each individual User and page/tab that the web part is in. Storing the variable in Page.Session accomplishes the per user requirement but persists the variables value across the same windows/tabs for that user. This link describes what I have done, but it definitely not unique per window/tab.
I am not sure of the best way to store the variable, but I have attempted to use ViewState unsuccessfully. I have confirmed in the web.config that it is enabled, but am unable to use ViewState in the same way I use Page.Session Can anyone please help?
Perhaps Postback was not the correct term? My code is actually: Context.Response.Redirect(Context.Request.RawUrl);
Thanks,
MK
Is there a reason you are using "Context.Response.Redirect(Context.Request.RawUrl)"?
You are wiping out View-State data loading the page this way.
Related
I have an XPages Library database where all my XPages are created. From there users will access other databases to do their work.
I need to put the names of those databases in variables so they can be found on any server (development, test, production, etc.) since the names are always the same. I think that those variables should be applicationScope variables but I am not sure.
If applicationScope in the variable that I need, can you tell me where is the best place to create them.
If it is not the right variable, which kind of variable will be the best and where do I define them.
An easy way to deploy some static references is the xsp.properties file. This file allows to add variables which are accessable on all XPages applications on the server
For example this variable...
myproperty.test=Hello World
... can be accessed in any XPage this way:
context.getProperty("myproperty.test")
These properties can be set by a theme too.
But the property has to be added to any server manually.
Another way is to use configuration documents: These can easily deployed by the replication mechanism to any database on any server. The value of these documents can be cached in applicationScope variables for a better performance.
EDIT:
You should alter the XSP.properties file on the server, not the database specific One. This does not require a Designer, only a text Editor is required.
applicationScope variables stay in memory about 10-15 minutes and are discarded after that. If I understood your need correctly, you should store the database names or URLs permanently and Notes documents would be the best fit for that.
The disadvantage of putting the values into a.properties file is that you need a designer Client to make changes.
I would suggest to use a global configuration document for your application that can be edited either in the client or using an XPage.
Take a look into the xhelp application by Paul Withers. Dig into the code to see how you can use a configuration document in your application. XHelp can be donloaded from here http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&documentId=426CB81230B6F94A8625789000830762
I think because you are talking about a portal like application that it would be best to have a settings document implementation. You have to create an admin xpage which will check if there will be a document of a certain type in the lookupsettingsview ( you have to create this yourself ofcourse ). If there is none create the document. If there is one use the document as the datasource.
On this document you can store the replication id's and server information about the applications you want to display. This can be a simple form with a multiline text field on it. The data could be stored in a format like "Description$repid$server". On the web you have to check for this document, read the entries in the document using a repeat. For each iteration you can just use a xp:link tag. Ofcourse you first need to compute the url of the applications but that's not the biggest issue here.
I have a piece of data, a simple string containing the server name that the SharePoint solution is deployed to, that I retrieve from a configuration store in a helper method in a common DLL used throughout my solution. This helper method is used throughout my custom pages and web parts, to build a number of URLs, etc.
I would like to persist this string, and prevent it being repeatedly retrieved from the configuration store. My Sharepoint installation is currently on a single server, but will be migrated to a SharePoint server farm in the near future, so simply determining the server name of the current request, etc isn't an option. I have looked at caching as described in the best practices for SharePoint, but unless I use a coherent cache like NCache or Velocity/AppFrabric, I will again have issues when the move to server farm occurs. Given that this is a single string, adding a full caching solution such as Velocity seems like overkill.
Does anyone have any suggestions on the best way to persist this data? Am I missing something obvious here?
Thanks, MagicAndi
Look into using the Property bag that is exposed by all major SharePoint objects to persist information. i.e.
SPFarm.Properties
SPWebApplication.Properties
SPSite.Properties
You could:
Store the string in web.config. You can programatically change the web.config on all the farm's webservers using a SPWebConfigModification
Store the string in a SharePoint list and read from it. I usually use this solution because I have more to store than a single string. The list is 'available' on all web servers and I cache its values in an ASP.NET cache object. Someone made this concept into a solution you can download and install: SPConfigStore
This article may be of use to those looking at storing configuration data in SharePoint:
Six ways to store settings in SharePoint
You can use SPPersisted to do such kind of operations.
Or at least could anybody point me to docs about its crazy proprietary url parameters and html field name obfuscation? I can only suppose this is caused by SharePoint...
The main problem is, given a start page built with SharePoint, I can't recreate a form post with a programmative client because:
field names vary, they are appended with a some sort of id, hash, whatever (I think session.wise? Not sure)
tracing HTTP traffic on my side, I see the HTTP request is packed with strange parameters like __REQUESTDIGEST, __VIEWSTATE, and many others
Is this an intentional protection device put up by SharePoint? Which is the underlying architecture and which objects are involved (script callbacks, ... )?
(BTW, I'm not doing anything evil, just trying to extract public government data from a website).
Thanks.
SharePoint is nothing more than an ASP.NET Application, SharePoint completely Built on top of ASP.NET 2.0.
Being said that __VIEWSTATE is nothing but a Hidden Field that has the View State Information
Coming to __REQUESTDIGEST this is an Intentional Protection, this carries some sort of
securito validation which is called FormDigest
And finally to answer your Question, You will not be able to guess field and stuffs unless you have control to change the sourcecode of the application. Reason why the Name of the fields looks like obfuscated is because those controls are not handwritten but generated by the Code of ASP.NET Engine and parser, Reason field having such a name called Naming Container
One suggestion I would say is that, rather than trying to scraping the screen data, you can try alternate approaches, like each of the List in the SharePoint has the XML Feed inbuilt,try to consume it, if you have access to the site, try to retrieve the information using export to excel etc.
In addition to RSS, SharePoint also has a Web Services interface that you can use to get at and interact with data stored in SharePoint in a programatic way.
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.
Does anyone know if it is possible to display a prompt to a user/administrator when activating or installing a sharepoint feature?
I am writing a custom webpart and it is connecting to a separate database, I would like to allow the administrator to select or type in a connection string when installing the .wsp file or activating the feature.
I am looking inside the FeatureActivated event and thinking of using the SPWebConfigModification class to actually write the connection string to the web.config files in the farm.
I do not want to hand edit the web.configs or hard code the string into the DLL.
If you have other methods for handling connection strings inside sharepoint I would be interested in them as well.
Unfortunately there is no way to swap to a screen where you can get user via the feature activation process. Couple of comments for you:
I'm assuming the connection string is going to be different for every installation, so there is no way you can include it directly in the Solution.
I'm assuming that you couldn't programmatically construct this during installation.
Therefore, you need some way to get user input. Here are a couple of options:
It could be a web part property, though this would mean setting it each and every time the web part was added, and you would need to then maitain those settings individually.
You could build out your own _layouts settings screen (good post: http://community.zevenseas.com/Blogs/Robin/archive/2008/03/17/lcm-creating-custom-application-page-and-using-the-propertybag-more-detailed.aspx), and from there users can maintain the property, storing it in either the Web Property bag, or inside the Web.Config. I try to avoid using the Web.Config where I can, but if you do wish to go this route then MAKE SURE you use the SPWebConfigModification class (Read this great blog: http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32)
Finally, a technique I often use is storing configuration information in a SharePoint List. Chris O'Brien has a great framework for that here: http://www.codeplex.com/SPConfigStore
Hope that helps,
Daniel
Sounds good. I will look at these possible solutions.
I do not think #1 will work since I am deploying multiple webparts inside a single solution which all use the same connectionString.
#3 sounds like a very clean solution. I see the config items are cached so it looks like if I need to store a connection string, I will not be hit with a SP lookup each time I need that string.
While searching for a solution I did stumble across another method.
If you dig around their code, I looks like they have created an installer that accepts application specific values, adds the values into a FeatureTemplate.xml file and passes them to the SPFeatureReceiverProperties object in the Reciever.
I was about to start tackling this method, but I think #3 would be better.
Thank you,
Keith