I'm new to PhoneGap and everywhere I looked doesn't suggest anything about using webforms as server code.
The application server is normally a web server (Apache, IIS, etc...) and has a server side scripting language such as ColdFusion, Java, .NET, PHP, etc... PhoneGap is agnostic of back-end technologies and can work with any application server using standard web protocols. The application server performs business logic and calculations, and generally retrieves or persists data from a separate data repository - this is normally a relational database, but could be any structure or mechanism for data persistence.
http://phonegap.com/2012/05/02/phonegap-explained-visually/
This article however, mentioned that PhoneGap is able to work with just about any application server including .Net.
Has anyone used PhoneGap with webform before? Do they work?
What about the form postbacks etc? Or everything should be AJAX-based? (Calling webmethods etc)
From the end of the linked article:
PhoneGap applications generally do not talk directly to a database;
communication is routed through an application server. The client
to application server communication can be based upon standard HTTP
requests for HTML content, REST-ful XML services, JSON services, or
SOAP (or websockets if your OS supports it). These are the exact same
techniques that you would use in a desktop-browser based AJAX)
application.
The client-side architecture generally uses the single-page
application model, where the application logic is inside a single HTML
page. This page is never unloaded from memory. All data will be
displayed by updating the HTML DOM, data is retrieved from the
application server using AJAX techniques, and variables are kept
in-memory within JavaScript.
So yes, in general you wouldn't use postbacks, you would use Ajax calls back to the server in order to get/create/update data - which is supported by asp.net webforms via handlers (ashx) or even static page methods on an aspx page. Your actual front-end you just design in HTML and CSS, no asp.net controls, just plain old html inputs, etc.
Related
I am currently starting a massive web app project, and one of the requirements is that down the line I may be required to allow an iOS and Android app to interface with my application, I figured the best solution was to create a RESTful API and have the web application interface with it. However, my coworker who does front end development is unfamiliar with using a javascript framework such as backbone.js (more of a library I know), ember.js or angular.js. Since we're using asp.net I figured that the I could handle authentication and routing using asp.net MVC, delivering seperate views depending on the route, and he can handle the data manipulation only, However, I can't seem to figure out how to seperate routing from the javascript framework, I've looked into ember.js and backbone and both of them seem to require routing to be handled on their end for it to really work.
Does anyone have any idea how to implement data manipulation without the need for routing?
What you are describing is generally called API oriented architecture, meaning you have a RESTful service on a back-end and rich client-side application on front end.
The point is, it basically does not matter what technology you pick up on server. It could be anything: ASP.NET MVC, Web API, Express.js or Django. As soon as it's really RESTful and pure. By purity I mean, it deals only with data, no serving of HTML or something.
Server just specify the interface you work with data,
GET /invoices // get all invoices
GET /invoices/:id // get invoice by id
POST /invoices // post new invoice
If you confident with .NET, WebAPI is probably good choice. Typically you would prefer JSON output, WebAPI could handle content negotiation for you.
Now, the client job is to consume the API data and dynamically create HTML in browser. A lot of options now: Backbone.js, Angular.js etc.
Please be aware: client side routing and server side routing are completely different things.
Server side routing: routes particular HTTP request to particular controllers action (or any function).
Client side routing: detects the URL change and triggers corresponding JavaScript function to handle change. Client side routing is vital for SPA (single page applications). You can find a bit more information on SPA on that blog post.
Have a look at KnockoutJS, which would allow you to use ASP.NET MVC for routing or another JavaScript library like sammy.js (just for routing) or Durandal (for routing and navigation).
Note: Durandal version 1 used sammy.js internally, but version 2 has a custom routing engine and no longer uses sammy.js.
I wish to implement REST service which will be integrated with ASP site (basically the same project).
I've tried to provide my custom VirtualPathProvider (VPP) and it works, but to a certain degree. First, the content-type of the response is always application/octet-stream. Second, only GET requests are piped through the VPP. I've seen people playing around with HttpApplication to solve these problems. I am not sure if I wish to follow the path of hacking the ASP as it might take a lot of time, and in the end it might be simply impossible to accomplish the task.
Is there a way to do it, or I should create a separate page for MVC, and talk with it via some inter-process communication. This way MVC will be handle the REST requests and call my code in response. And vice versa - ASP will be able to send REST requests to remote servers.
If there are any other, cleaner, safer & easier, ways of linking MVC with vanilla ASP, then feel free to post them in comments/answers.
VirtualPathProvider is meant to be a way to virtualize the filesystem for internal ASP.NET operations (e.g. storing *.aspx and *.master files in a database), it is only coincidental that it works for user-provided URIs and requests.
Your best bet is just to use ASP.NET MVC, which is now integrated with ASP.NET (since 4.x) or as an easily redistributable component in .NET 3.x. ASP.NET MVC does play nice with WinForms in the same application, so don't reinvent the wheel.
However, if you are insistent, the only real option is to do it all from within a custom IHttpHandler that chooses to handle incoming requests or not (as you won't have ASP.NET URL Routing because you're not using ASP.NET MVC).
Is it feasible to write an ASP.NET MVC2 application that uses the Cache Manifest mechanism to support offline processing? I know this might sound like a contradiction in terms, but I have an MVC2 web app and I'm looking at trying to make it resilient to unreliable network connections.
Of course that it is possible. The HTML5 offline storage is independent of the server side technology. Here's an example with ASP.NET. In this example the illustrated custom IHttpHandler could be easily replaced by a controller action in an ASP.NET MVC application.
can you please tell me what is the difference between webservice and webapplication.
A web service:
Typically returns XML or JSON or something like that, something that is easily decoded by a program
The results you get from a web service is typically not just shown to a person in its raw form (ie. since it isn't HTML, the results have to be reformatted, like placed into a form)
The intended usage of a web service is that it is something an application can talk to
A web application
Typically returns HTML or image data or similar
The results you get from a web application is usually shown to a person, through a web browser
As for similarities:
Both typically use HTTP(S) as the transport
Both typically use HTTP authentication/authorization to secure data
Both are typically hosted by a web server
So the main difference is who usually talks to them. A web service usually by another application, a web application usually by a web browser. Other than that they're pretty similar.
Here is the Web Application and here is Web Service
Web application: any application which resides on a server, and mainly used by human using web browser. All user interactivity is done through web pages.
Web service: server-based application (as above) which may be accessed over the web via HTTP, but is meant primarily for interaction with other programs. Generally it is WEB API for other applications.
In a nutshell, a Webservice uses special HTTP transport protocols to communicate to other servers. Webservices are meant to be used by other applications.
In the ASP.Net world, a web application is a type of Visual Studio project that allows building ASP.Net websites in a particular configuration. E.g. A Webservice can be built using a Web Application type project. Or a Web Application can also refer to a website that is meant to be used directly by an end-user ( unlike web services ).
Here are a few links and related SO questions...
What is the difference between an asp.net web method and a wcf service?
ASP.NET Web Site or ASP.NET Web Application?
Introduction to Web Services and ASP.NET
check this
http://en.wikipedia.org/wiki/Web_service
http://www.w3schools.com/webservices/ws_intro.asp
I have just experimented my first ajax enabled WCF service in a sample asp.net webform application... If i have 10-15 pages in my webapplication which involves add,edit,view and delete operations, is it possible to make them ajax post and get without using .cs(codebehind) of all pages...
What are the pros and cons when choosing ajax enabled WCF service in an asp.net webform application?
At first, if you want to implement the server side of jQuery Ajax calls, you can do this with either ASMX or WCF services. You can find a short comparison between these two here. WCF is more modern technology and will be my preferred choice for new projects. It can provide you with the following:
Help you program against an interface
It will serialize/deserialize objects to JSON for you. No need for JSON libraries
Provides client methods that you can use (via the ScriptManager). It is also easy to use jQuery if you prefer
As an disadvantage I would say that it will take you some time to learn the technology. I found that proper configuration of web.config was a little tricky.
I usually have a single svc service that serves all Ajax requests. You can implement as many methods as you want in a single service. The services are called from different pages.