I have a search template on PicoSearch and our design uses a server side include to load the menu so I'm wondering if I can link to the server side include on our server from the search template.
Unfortunately, no. If you have full control of the environment in question, you can set up a method (like a service) to feed the information for the other application, but even if you successfully figure out how to #include from another site, you will end up with warnings for your end users, which is not very nice looking for the user.
Related
In the Blog App (I am using 3.00.02 I think), I notice the queries for the main article list have filters for In:Settings:Category. This appears to be Module Settings, but I am not sure. Can you tell me how/where to add and store these settings? I am hoping they are module settings of some kind so I can filter for different types of articles (press vs news vs announcements) on different pages across the site.
Is there an example somewhere in the app of how this filter is used?
Anything on the "In" comes from an in-stream on that data-source. So that block must have an inbound stream called "Settings" - look at where that comes from.
Is it possible to retrieve drl ex:https://host:port /ewebtop/drl/objectId/0900a58e80970f7b of document via .net application?.So that when users clicks on this link they can be able to edit the document and when they close the document the document should be autosaved onto documentum.
First of all: a link is a link. What you decide to do with it I u to you. Default handler in browser will just redirect you to webtop application. If you have SSO you can have the document opened for edit. There are some extra arguments that can be provided (view/edit).
The object id is the only varying part of the URL, so you can easily construct this in code.
Secondly: what is your goal? There is no way to make the document upload itself into Documentum repo. You can write a plugin for every application to handle that, but it seems like a big task - especially dealing with security.
The problem is that upon check-in, user must provide some information - at least about the new version number...
If you're building a thick client in .net I would go with DFS - that's the only real option here.
Where do I start learning SOAP API based on C# for Reporting Service ? MSDN articles are difficult for me to understand and ended up making me confused. In fact, they are like giving more facts. I want to get my hands dirty on coding. But I don't know where could I start. What I want to do is I want my RDL reports/or RDLC reports to get accessed by users over the web. Please give me some guide.
P.S My coding skill is not very good ,but I want to learn more and practise more to improve it. Currently I am using SQL 2012 and VISUAL STUDIO 2012.
Thanks.
For me the easiest way was to start with generated proxy class. I did that using this MSDN article. Follow the section named "Adding the Proxy Using the WSDL Tool". According to it, first generate proxy class running this in command prompt (you may need to use VS dev command prompt to run wsdl.exe):
wsdl /language:CS /n:"Microsoft.SqlServer.ReportingServices2010" http://<Server Name>/reportserver/reportservice2010.asmx?wsdl
You will get ReportingServices2010.cs file, which you can include in your projects and use to connect to SSRS server.
var service = new ReportingService2010(){
Url = "http://<your server>/reportserver/reportservice2010.asmx" // url to your server
};
Then you can code anything you want according to MSDN documentation on this reporting service.
Let me know if this helped you.
I don't know if you made progress since your post (I hope so), but in my case I use the SOAP web service, without created proxy server by hands. VS will do the job.
This MSDN article and related links explain it.
The principle is the following : access the SOAP web service through an URL that looks like that : http://server/reportserver/ReportService2010.asmx?wsdl
where "server" is your domain name server, or IP address
and "reportserver" the access point of your SSRS server (it can be different in function of your installation settings).
After, in your VS, go in "Project" menu and choose "Add a service reference". Then enter the URL of your SSRS SOAP service (as explained before) and that's it !
It will create a new folder in your project called "Web Reference" with a item inside, directly linked to yout web service.
Then you can us it like any other object of .NET Framework (by creating ReportingService2010 for example like done in previous post).
Let me know if you have any other questions.
Regards
I'm creating an app that will be configurable by the end-user to access SharePoint lists, on various different SharePoint sites, that are entered by the user.
All of the examples for reading SharePoint lists I've come across online are of the form:
Open or create a Visual Studio
project.
In Solution Explorer,
right-click the References node, and
then click Add Service Reference.
In the Address box, type the URL to
the target site and append
/_vti_bin/ListData.svc. For example,
the address for the site
intranet.wingtip.com would be
http://intranet.wingtip.com/_vti_bin/ListData.svc.
Change the default name in the
Namespace box from ServiceReference1
to something more appropriate, such
as WingtipSite.
etc, etc, etc
This method creates proxy classes within your project based on the specified server reference. However, in my case, the server/site is not known at design time, only runtime by reading the sites/lists specified by the user. How would one go about doing that (reading the list via http://intranet.wingtip.com/_vti_bin/ListData.svc, but at runtime only)?
Note: I am making this call from a different machine than the one running Sharepoint.
There are a couple answers.
If the lists schemas will be consistent across all the sites you are querying, you can still use the generated proxy. When you create the DataContext, you just need to pass in the URI to the ListData.svc for the site chosen by the user.
If not, then you can use an ASP.NET WebRequest with an appropriately formatted URI and parse out the ATOM or JSON response that comes back.
For more information on using the REST APIs, check out this talk from the 2009 SharePoint Conference
http://msdn.microsoft.com/en-us/sharepoint/ff462048
You can set the URL in your proxy class at runtime with the Url property.
SharePoint does not provide a proxy class for their web services. Therefore it's not possible to set the url at runtime. WHat I have had to do is add 2 service references and then paramaterize which one I will access. I use a config setting to determine which one to access. If the site name changes or list changes, then I need to remove the references, re-add them, recompile and redeploy. There is no way to change the SharePoint site/list at runtime. Have been searching for 3 days for an answer. Microsoft does not know how to accomplish this.
We have a sharepoint environment with many sites (and sometimes many site collections). Each site (or site collection) has the same default page with some custom webparts that use sitecolumn values (for example a projectcode or clientcode) to show information from external systems. (for each project we have to create a separate site (or site collection) because of other reasons)
What is the best approach to minimize duplication? The dynamic parts of the page are stored in site columns. When we add a new webpart, ideally the default page every site/page should show the new webpart without spreading the update to the individual pages
Thanks
One approach you may want to take is to use the web part as a wrapper for a user control. The user control does the heavy lifting on the site. Once the web part is included on your pages, the user control should be able to tell which site it is being executed on and pull the necessary dynamic data from your site columns.
When you need to make updates, you update the user control and then redeploy the solution package to the farm. Each site will pick up the change as soon as the solution is deployed.
Here is a little information about this approach:
http://msdn.microsoft.com/en-us/library/ff649867.aspx.
The above article relates to WSS 3.0, but that should give you a starting point.
An approach you may want to look at for SharePoint 2010 is a visual web part. More info can be found here: http://msdn.microsoft.com/en-us/library/ff597539.aspx.