I am trying to implement an HTML page that displays embedded reports with IFrame and I need the report parameters to be displayed on the HTML page and not in the report (because they are ugly).
Is there any way to use the reports dataset or something else to pass the parameters to the web page, when the page is generated or is the only way to do this by making backend SQL-queries and generating the parameter selectors based on that?
Getting parameters out
Your option would be to build a web application that communicates with the SQL Server Reporting Services by SOAP. This can allow you to programmatically load the parameters from a report and handle them in your web application (like display them on your web page). This can be written in a language of your choosing as long as it supports SOAP and Web services to consume the WSDL. You can see the reference article for consuming WSDL here: Accessing the SOAP API.
The methods required to achieve your goal are listed here: Report Parameters Methods.
Getting data back in
You can pass report parameters within a URL. The standard method is to append &ParameterName=Value onto the end of the URL. However, to do so the URL you construct must adhere to specific structure:
http://hostname/ReportServer?/RootDirectory/SubFolder/ReportName.rdl&ParamaterName=Value
You can pass more than one parameter into a URL by simply appending more after the first. For more detailed information please see the Microsoft article: Pass a Report Parameter Within a URL.
Related
I have a dropdown list which is being used on several pages including the Home page. And I don't want to send data requests to the server for that drop-down list for all those pages. I want that drop-down list to be stored somewhere for all the pages at the time of loading the home page.
I could then use that several times on several pages without sending requests to the server each time. So that I could make my site a bit faster. Is there any way to do this?
You can make use of Singleton Service, which can be referred by all the components in your application. Give the server request to fetch data at the start of application, and store the result in the form of properties or attributes declared within the Singleton Service.
Once you have the data within service, you can simply refer that instead of giving server request every time.
Refer here for Singleton Service : How do I create a singleton service in Angular 2?
have been with mvc for a little while. the usual case when an action returning json, it is initialized by ajax in the view and the view is expecting info inside the json.
is there a case the action returning json to the view and is caught by something else instead of javascript? Thanks.
Yes, a JSON API can be consumed by a large variety of clients. It can be the browser sending an AJAX request, but it can also be a desktop application fetching data from the Internet, a server-side job scraping the data for analysis, etc.
For example, let's say you're running a stock exchange website, and you're publishing current stock values as JSON. You can use that JSON on your website to display the data, but you (or any other developer) can also write a desktop application which will get that data and process it on a local machine (to, for example, show the user which stocks they should buy). Or aggregate data from different sources.
Many websites make their APIs public, so that third party developers can write alternative clients, integrate the API's functionality in their own products, and so on. For example, GitHub's APIs are public - the GitHub website can utilize them for the AJAX requests, and GitHub for Windows can show you the list of repositories you own by making a request to that API using C#'s WebClient.
Premise:
This question is more like "is this the correct approach?" rather then "how do I do this?"
Situation:
I have created a CherryPy REST application following this tutorial. The data are returned using the json module with a simple json.dumps. This example works. I have a mako template which I would like to use to create a HTML table with the data. Again, the template by itself works.
The question: In my head, it works this way:
The user asks for a URL
The REST API creates the JSON with the results
The mako template produces the HTML given the results
The HTML is returned to the user
My problem is, I'm not sure this is the right approach: in my (small) experience, the JSON should be returned to the client, which should render it in some way (using jQuery or some other client-side language); instead, the mako template works on the server-side, and that's where I got stuck.
Do you have any advice?
You don't need REST to solve this, this is a regular web application. Just to show you how this works by a REST service:
The user asks the REST client to do some-automated-stuff on the service
The client requests example.com/api/v1 to get the main page
The client looks for hyperlinks on the main page
The client finds hyperlink with relation=some-automated-stuff
The client follows that hyperlink and gets a JSON result from the REST API
The client uses the mako template and produces the HTML given the results
The HTML is returned to the user
A typical client is a 3rd party server side application, which is registered by the service and got a unique API key. The users allow to the clients to do some-automated-stuff on their account by giving permissions to API keys. So for example the service can be the facebook API and a client can be an application developed by Zynga e.g. Farmville. When you allow to the client to post on your news feed that you just harvested 100000 crops on your farm, then it sends a request about this to the facebook API and so some automated message will show up on your news feed.
Ofc. you can write a 1st party AJAX or server side client if you want, but if you don't want to support 3rd party clients, then it does not make much sense to develop a REST service. Ofc. your client won't break as easy as by regular applications, so it might worth the effort if that is important.
I have created created How to a new web app integration with the help of this documentation of Box api documentation.
When i right click on a pdf file i can see my application.
Now i need to know how to configure my application to get the file id?
I believe what you're looking for is the "Callback Parameters" section of your Web App Integration.
Within the Callback Parameters section you can choose whether what your application is expecting is a GET or POST request or a file object (in cases where you would like the file itself to be sent to your application) and input a parameter name that you would like to receive for the value. Then you can click into the box for Parameter Value to see a dropdown of the available parameters that can be sent to your application with a short description of what each one returns. The one you're looking for in this case is the file_id, which will show up as #file_id# once you click it, as in the screenshot provided.
I have a web page that is basically a form the user fills out.
I developed a C# VSTO Outlook 2010 Add-In that can create a JSON object based on the details of an appointment on a user's calendar. The JSON is then passed via the URL (in the Query String) to my web page. The object that is passed is used to automatically fill in the details on the web form. The web page is ASP.NET, although I don't think that's relevant.
This is the first time I've ever passed a JSON object in a URL. Are there any potential pitfalls I should watch out for? Anything that could go wrong? I saw in this question that someone said you can pass JSON objects via URL with "no problems" but the question there was "can I do it?" rather than "what problems might I run into?"
The most realistic problem (if you are not concerned with security) is the GET request size limitation. The IE, for example, have limitation of 2Kb for GET requests. So you could get into situation there your request will be trimmed.
And for the security issues mentioned, the GET requests are stored completely in browser history and thus can be potentially exposed to third-party.