I have a simple one page HTML website to get user input and a WCF service that takes user input and return a list of strings depending on the input.
I would really appreaciate any guidance to connect the two together. Can it only be done with httpBinding and JSON serialization? Is JSON the best practice in this case?
If so, how do I make calls to the service? Do I need any server side scripting or is javascript on the client side enough?
If so, how do I capture and output the return of the service?
Thanks a lot.
Generally I use Ajax Enabled Wcf Service, with Json in this case. It works great for me
Most of times it's too much unnecessary complication of the system when you create a WCF service, define bindings, endpoints, contracts, host the service and distribute the client when you could simply get the things done with ASP.NET Page Methods + jQuery even getting rid of ScriptManagers.
You can call a Page Method directly from any .html file, you just need to have a single aspx file on the server, users may even don't know about its existence. The method can return your strings in a single string value, separated with any comma-like sign which is processed by JS later on.
You have a great advantage with page methods, 'cause the service is built into the asp.net web application, you're free of heavy, time-consuming mechanical hand-work every time you have to modify the service. My strong recommendation for you is to make use of page methods if you have an asp.net web app and follow KISS principles.
Related
We have a web client built with GWT that talks to a server via gwt-rpc. One part of the app will now use html/js to replace the GWT GUI and we want that part to talk to the server but not via gwt-rpc. What ways are there to migrate a gwt-rpc call to something that will work with a none a gwt client? Today we send and receive java collections that contain object graphs like a list of order objects that have them self order detail objects and so on.
Thanks
Your best bet is using REST. Your data is sent using JSON, which is part of JavaScript so it will always be understood on the client-side. On the server side there shouldn't be any problems finding a suitable library to handle the rest (ha-ha, get it?).
If you're using GWT on the client and server side for now, resty-gwt and Jersey are a popular combo. There was a talk about it on the last GWT.create conference, it's a good starting point.
I have a WCF webservice developed with .NET 4.0 which I need to be called by a Javascript client. I have been searching online for the best binding to use to make this possible. Most answers seems to point towards webhttp, but I am concerned as this is one of the lest secure bindings. What is the best way to configure this?
As per my experience and understanding of "invoking wcf service from client side using jquery", i would say:
You can use either of webhttp or basichttp binding if need to invoke using jquery/javascript (surely basichttp better choice over webhttp here).
One person even wrote an article on codeproject where mentioned that using jquery one can even invoke wshttp bidning based wcf, I have not tried it myself, so not sure about it but if you need to expose your service with wshttp, then can refer this link on CP:
http://www.codeproject.com/Articles/311908/Calling-WCF-service-exposed-with-different-binding
In my opinion i would say:
if there is no business need to expose service as rest one, then don't go for webhttp, Again if your client app is NOT a .net app and if there is no need to have security in place, then you can avoid wshttp totally, so per this i would say go for basichttp bidning, where you get interoperable service and can even add security in future, if needed.
Quick testing your WCF webservice you can install "Advance REST client", it's available for Chrome/Firefox.
In order to integrate with your JS client app, you can use jQuery http get post depending upon your WCF verb. Alternatively, you can also use Angular.JS for the same, e.g., $http.get
For security you can secure your service endpoints in .net
Take a look at this page which specify different security configurations you can use in wcf.
What is your javascript client? is it running in browser?
I have asked this quesion few days before here and no one answered it.
I had asked it in forum.javascriptMVC.com too and now I have a answer, however I need a a bit more idea.
Question:
I read javascriptMVC's documents and I loved it.
But I don't know how to use it in a large scale project.
I think on the server-side a MVC framework is needed or can help so much. And I've worked with server side PHP frameworks.
I am confused, my understanding of JavascriptMVC projects is that they handle client side events on the browser capture events, execute AJAX requests, manage the responses/data from the server and also show them to user in a graphical interface.
I know that in PHP MVC projects we also have controllers (and actions) that any of them is a separate page with a single entry point, my point is that these pages are whole HTTP requests.
I think the combination of these two frameworks would be in a form of a single or few heavy files (including js , css , imgs etc) that loads and managed by another Javascript libary such as steal.js.
Now user can work with site and its actions (as events) that result in running js functions that may change something in the UI or cause a AJAX request, as in Yahoo Mail where most things happens in one page.
So how will this affect the design of controllers and actions in PHP ? I mean normally in PHP MVC frameworks a lot of controllers and actions means a lot of pages. I think because of AJAX the number of controllers and actions should be actually less. I also think because of JMVC most controllers (and actions) should turn to AJAX responders, however how are layouts and views to be handled in this context?
Finally
I want to know about different aspects of using this method(JMVC+MVC). (I am using Yii as my server-side MVC framework and JavascriptMVC as my client-side MVC).
I also want to know about management of data on the client-side.
I would like to understand how AJAX and web-sockets could be used, where we can use AJAX and where we can use websockets?.
I want to understand about local-storage how we can use it for simulated page data management and maybe caching, how we can cache data coming from server as JSON in a form of a page? I am working on a very large project and I want to build its foundation very strong.
Say that you jave a JMVC framework where
The model gets data from the server using AJAX request - expecting JSON results.
The view does not rely on the server, for more that providing the raw HTML.
The Controllers do not rely on the server, for more that serving the JS files.
Essentially you use the server what it "should" be used for, data storage and processing, while you let your client browser handle all the tedious stuff.
Now, lets see how to define a server-side framework. As I see it we have several options, all of them fairly similar, albeit somewhat different (all returning someing in JSON format):
A fully fledged MVC such as cakePHP
Custom implementation
WebService implementation
Personally I would use a WebService, and I already have. Or rather, I used a WebSocket based JSON-RPC WebService.
Using a fully fledged MVC will have it's drawbacks in maintainability and, not insignificantly, server load. But it is very possible, just implement a view which formats the page as JSON...
Making a JMVC client does not, in my view, mean that it cannot request new HTML from the server. But it does mean that that requested HTML should be free of data, other than meta-data the Java-View needs to know where to put data recieved from, for example, the WebService.
So a main page in the JMVC could just contain a single
<div id=content></div>
and menu clicks can fetch a subpage from the server and load the content into content. Then that loaded content can contain some more javascript which starts WebService requests to get data from the server, to display in the empty placefolders it in turn contains.
First check https://stackoverflow.com/a/4458566/718224 after that you can move forward.
Try this (from https://stackoverflow.com/a/8424768/718224)
No, you don't need to use it server-side, but it will help with organization / separation of application and business logic. Depending on the scale of your application, that could help tremendously in the future.
The key is just making sure you organize your backend code well, otherwise you will end up with a monolithic and/or difficult-to-maintain codebase.
Server-side views would contain your HTML and any JavaScript that may or may not make requests to the server. This assumes that you are actually using PHP to build the pages that a user navigates to.
If you have a static html page that builds itself using AJAX requests, then you may not need to use server-side views at all. Your controllers would more than likely be outputting JSON data. If this is the case, it doesn't make models and controllers any less useful.
Try this (from https://stackoverflow.com/a/8424760/718224)
If you are using any of the major PHP frameworks (CakePHP, Code Igniter, Symfony, etc.) then you ARE using MVC already. If your server side logic is more complex than just a few really simple scripts than you probably should be using one of those frameworks listed, using MVC on the server and the client.
Many (most?) larger web apps being built today are moving towards using an MVC framework for both client-side and server-side application code. It's a fantastic pattern for separating concerns for many large applications, especially request/response server apps and event-driven browser apps.
Try this (from https://stackoverflow.com/a/8427063/718224)
Backbone.js connects your application over a RESTful JSON interface. I honestly find that it works wonderfully in conjunction with the MVC framework. If you build a RESTful API, you can let you server manage CRUD updates quite easily. All your server side code will be responsible is saving and sending back JSON objects to Backbone.js. Then let most of your logic and magic happen within the Backbone.js framework.
Try this (from https://stackoverflow.com/a/8078282/718224)
First, a client-side MVC framework like Backbone isn't just for single-paged apps. You can also use it to add some rich interaction to one or many views of a more traditional app. They simply provide structure and data abstractions on the client.
Next, these client-side frameworks are designed specifically to work with your back-end MVC frameworks. Backbone.js (since you tagged it specifically) models and collections work with REST services. They will talk via GET/POST/PUT/DELETE verbs and will ultimately communicate with your controllers on the back-end when they make asynchronous requests.
In the case of Backbone, it talks JSON instead of HTML. In the case of Rails, this is really easily handled in the controller. If the request is an HTML one, then you return a view as HTML. If it is a JSON request (*.json or Content-type) then the controller returns a JSON representation of the data. I am assuming that it is as easy in Django as it is in Rails to have the same controller respond to multiple content requests (HTML, XML, JSON, etc)
may this help you.
client side web apps and rich client side web pages often use jmvc backbones and etc. and with that kind if js libraries and HTML5 technologies like webstorage you can have a more applocation like websites that all things happens in client side like templating management and etc. and just we have ajax request/response to servers to get/set data or update status. and abput first section they are right a jmvc site are more like a single pages websites. ie hotmail yahoo , etc.
I have found the practice of consuming webservices on the client quite uncommon and have a query in this regard. Is it bad practice to consume webservices on the client end? Does exposing the webservice put your application at risk in anyway. What is the main motive behind calling the webservices on the server and not client, because logic dictates that the number of calls to the server would become much smaller and the whole process would move a lot faster?
Thanks
Shouvik
PS:
I am not sure contrary to what I believe is widely practiced and if so then I may be completely wrong in my notion. Since I could not find any real article on googling I ask this question.
it completely depends on the nature of the webservice and what you do with them, if the webservice is open and doesn't require authentication or certificate validation, then you can obviously load it from the client side.
incase if the web service exposes some critical information which you do not want to expose to the end user, its a practice to load it on the server.
incase if you want to do a business logic on the data returned by the webservice and dont want to expose the logic to the external world, you can do it on the server.
i would say it completely depends on the type of the web service and what you are doing with the webservice.
for ex: if its a weather webservice which is open, no authentication etc, i dont see any value in having it on the server except you want to increase the load on your server
Go over this Sun Link
Totally depends on web-service type you want to use there.
This might help you in further development.
I am currently having an idea where I want to save an image from a c++/openGL application on demand from a browser. So basically I would like to run the application itself on the server and have a simple communication layer like this:
JS -> tell application to do calculations (and maybe pass a string or some simple data)
application -> tell JS when finished and maybe send a link, text or something as simple as that.
I don't really have alot of experience with webservers and as such don't know if that is possible at all (it's just my naive thinking). And note: I am not talking about a webGL application, I just want to have simple communication between a c++ serverside application, and the user.
Any ideas how to do that?
Thanks alot!
Basically no matter what your language/framework you choose for your web server, you just need a interface that is callable from your browser JS, and you can do whatever you want in the server once it recieves the call.
Most likely any web service interface exposed from the server.
Just need to safeguard your server not to get DoS since it sounds like it's a huge process.
As far as I know, JavaScript (at least when embedded in HTML) is executed on your local machine and not on the server so that there is IMHO no way to directly start your server-application using JS.
PHP for example is executed on the server-side and so you could use e.g. the php system function to call your C++/OpenGL application on the server - initiated on demand through a web-browser.
When the call is finished you could then directly present the image.
Well you could always use the cgi interface to invoke your application
and have it save that image somewhere accessible to the webserver.
Then have your js load that via ajax.
Or make a cgi App that talks to the app and then serves a small
page with the pic in it.
[EDIT]
Answering the comments:
CGI is not complex to learn, it is mostly a simple convention
you can follow. I think it would give you the maximum of
flexibility. I don't know which php mods allow you to leave the cozy protection of the server-application and interact with other stuff on your server.