Is the combination of technological ASP.NET-MVC4, and AngularJs work well?
About the needs of my app: most of the work of my application view pages with tables of information.
I need to have an easy option to identify each point in the tables on the client side, highlight it, paint it, and request additional information from the server about it.
ASP.NET MVC and Angular.js have nothing in common.
Short answer is yes - they work well together.
You would simply make all your Actions respond with JSON rather than HTML (unless you want HTML in some scenarios)
i.e you write your HTML template, angular controller, etc on the client, and have an Action to grab all the table records as JSON, then load that in your angular controller to populate the table, interact with it all on the client, and send any changes back to the server.
You could replace Angular with any client-side technology if you wanted. Backbone, Knockout, etc.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I heard a lot about how AngularJS is so much better than jQuery for communicating with server.
But all i found was replacing C# controllers and cshtml views with purely client-side javascript files. And i have no interest in that.
is anything that I'm missing?
I am currently using jQuery Ajax for communication between client and server through JSON. I was looking forward for a better solution for this purpose.
Once a controller returns a view, what is sent to the browser is pure HTML. Razor is rendered server side as HTML. Or your action can return pure JSON.
Therefore, whether you want to use jquery, angularjs, or any other JS/HTML based library, there is really no restriction there imposed by MVC. From the perspective of client side code, controller actions are just URLs that return return HTML or JSON.
Additionally, MVC controller actions which return JSON, or WebAPI controllers, are perfect RESTful endpoints for your AngularJS to interact with. If you need HTML fragments for refreshing dynamic areas of a page, then a controller action returning a partial view will come down to the client as an HTML fragment. So your interactive requests through Angular can still leverage your backend architecture of Controller/Business/Data layers.
What Angular Offers MVC
AngularJS offers an MVC application the same thing it offers any web applicaion. It is a great way to abstract the presentation of UI elements from the interactivity of those elements with the backend. The problem with common approaches with jquery is you react to interaction with specific HTML elements via selectors such as $('.someClass').on(... and then in the handler collect information from the element about what was clicked and submit that in an ajax request, and then take the response and update specific elements $('.areaToUpdate).html(response)`.
So you have three concerns not properly separated:
What element responds to interaction(button click, drop down change, item drag/drop)
The interaction with the server to compile a request, submit it, and parse response.
Updating the UI based on the server's response
Often times because of the way we try to make this code less fragile, you are restricted to a logical hierarchy of objects that also matches your UI's HTML element hierarchy. Long story short, the lack of proper separation of concerns means changing any one will impact a chunk of code that has multiple purposes, and thus changes are more challenging because you have certain restrictions imposed due to lack of decoupling.
AngularJS provides a client side separation of these concerns by using a client side model as the intermediary between these concerns. UI interactions update the model, other code responds to changes to the model and makes server requests which update the model in response, and yet other code can respond to those changes and update the UI in response to the model changing. You are free to modify the UI's structure, and have a much more smaller set of code to update to get the UI changes wired up.
The fact that AngularJS is modeled from an MVC pattern makes it seem as though it would be mutually exclusive with ASP.NET MVC. However, they serve two different purposes. ASP.NET MVC provides separation of concerns for the server side querying of data, population of server side model, and rendering of server side HTML. It also provides a great way to support the rendering of JSON or HTML fragments(partial views) that might be leveraged by a client side interactive framework. AngularJS provides a model appropriate for writing clean client side code for highly interactive pages.
Personally, I think they are very complimentary.
Trying to do highly interactive pages with jquery+ASP.NET MVC is doable and can be efficient, but AngularJS adds a lot to the maintainability of the client side code. ASP.NET MVC provides a good framework for your server side logic. Additionally, if you have simple pages that fit a more traditionally PRG pattern or simply rendering HTML content, then ASP.NET MVC gives you an efficient way to quickly implement these pages without the unnecessary boilerplate code you'd need with Angular. In other words, you can choose to use AngularJS only on the pages that will really benefit from it.
You can mix MVC and angularjs with out completely removing MVC controllers.E.g if you have 5 modules on your app create that parent routes on MVC routing.(E.g Students,Teachers,Attendance etc..)
initially render your first view say student view renders through asp.net MVC then include all your JS files(including states related to that module) on that view(e.g students.cshtml)
.JS files related to this module may be
studentModule.js,studentController.js , studentService.js etc.
Do all your CRUD operations on angular JS.
Here your studentService will interact with MVC controller for all your db operations.
Benefit you are getting with this is
you are interacting with your server asynchronously and you can use
all angularjs features like(Directives,resources etc)
You can authorize all your MVC controller actions with asp.net
identity.
-Also to render any html template on state you can call your MVC controller action from templateUrl.return csHtml from MVC controller
action.
There are lot of applications on live using both asp.net mvc and angular js. here are few things i know.you can check some tutorials for better understanding.
.
Angular and ASP.net are both MVC frameworks. They are in a sense at odds with each other - I work on an Angular / ASP.net project where we serve and initial ASP.net view and then let Angular SPA routing take over, but its kind of a hack and I sometimes which we separated the two and had a plain WebApi implementation with Angular front end.
Using AngularJS just for its Http library is like using a sledge hammer when a hammer will do. You are wasting bandwidth in downloading large amounts of unused JS.
I would look to a pure JS library to handle your Http communication if you are unhappy with JQuerys implementation.
Axios is an amazing example of one of these libraries and uses Javascript promises just like Angular - which make the whole process really neat and easy.
Good luck!
I am new to AngularJS.I have two questions.
Is it possible to use JSP pages instead of HTML in AngularJS.
Is it possible to create a web application using AngularJS without webservices (for fetching data from DB) and use HTTP servlet for that purpose
Is it possible to use JSP pages instead of HTML in AngularJS.
Even if you use JSP the final output will be HTML so you can use JSP in AngularJS but JSP files are mainly used to render the frontend with data that you can do using HTML only in AngularJS.
Is it possible to create a web application using AngularJS without web services (for fetching data from DB) and use HTTP servlet for that purpose
Whether you use plain Servlet or any framework that creates REST APIs, it will be HTTP calls only.
(This is a newbie question which applies equally to all front-end MVVM frameworks. I'll answer it for the general good.)
AngularJS is a front-end framework which runs in the browser. It relies on a server delivering the content (HTML templates, CSS and JS sources) to the browser.
What you use as a server, is entirely up to you. It depends on whether you need server-side dynamic content.
If none is required in that area, you can use a static HTTP server like LightHTTP, or plain old apache, or nginx, or anything else to deliver the AngularJS site to the browser.
But in most you will have some server interaction (i.e. storing / querying stuff in a database, or communication / synchronization with other users, etc). The common approach for that is to deliver HTML/CSS/JS statically and add a bunch of REST interfaces. Flask and Tornado are popular server choices for that, or stuff like spray.IO / akka.http for higher traffic volumes.
In specific cases, you may want to work with pre-rendered HTML templates (usually because you want to dynamically exclude parts of pages for security/user role reasons). Then you need a server-side framework with template rendering. Django, JSP, ASP, pick your favourite.
It seems like you are asking how to use AngularJs in a JavaEE application. And yes it is possible. Only your index.jsp will be in jsp, and all you other views will be in html.
You can then use http requests to fetch data through your servlets.
it can be useful. here are scenarios:
you want to save ram, cpu for mobile phones or machines that doesn't have lots of power. you can partially render page in jsp and keep only minimal in angular.
your team is traditionally jsp heavy and you want to use them and gradually transfer to angular. eg... for i18n rendering jsp seems far better. note that i18n may not add lots of values in angular and you may not want to throw up existing code in jsp.
I have been noticing strong views in stackoverflow and they seem to dismiss everything that doesn't fit in their utopian all new cutting edge. all the angular projects I worked had heavy dose of legacy pages using jsp and it doesn't make sense to rewrite everything from scratch or lay off whole team and start hiring from scratch. and thus, yes, jsp makes sense with angular.
When I first looked at Play and went through all the samples, I was pretty excited by the zentasks sample and the fluid, clean, effortless Javascript routing that left the work of rendering things to Play. But we decided instead to go with Angular.
Upon going down that road, I thought that Angular would control all aspects of rendering.
However, we have a page that has to get a socket. We were having the socket made on the server, so for now, we still have a Play (Scala) template doing that. We have pared it down to pretty much nothing: create the socket and then inject it into the Angular context.
But we are also trying to do Protractor tests and that is made uglier by having to figure out how to accommodate the Scala template.
Question: should we just ditch the scala template and have the Angular controller call the server and get the socket? That was my favored approach to begin with.
I'm currently working on two Play apps with Angular and in both we decided to have one single main.scala.html file that load all the necessary controllers,services,directives, etc from angular using of require.js.
The goal with Angular is to create a single page app and therefore you should avoid to mix it with server side templates.
You must see your main.scala.html template as the entry point of your single page application. There you generate and load all the pieces you need and give the hand to angular to manage the rest.
I agree with Renato. It's probably better to have a single controller and template that sets up the single page app with angular. Then use AJAX to send requests from the browser to other controllers (see http://www.playframework.com/documentation/2.2.x/JavaJsonRequests).
If want to to avoid Scala templates completely, you can put your web pages and javascript in the public directory and only use AJAX.
I am currently using the Backbone philosophy which involves dust.js for template style. Recently I came across AngularJS, which extends the HTML syntax with custom elements and attributes.
Cons of Backbone+dust.js environment:
Upgrading components is time consuming.
Module specification and identification is not easy.
If I move my functionality to AngularJS will it be helpful or does it feel the same?
Can anyone explain to me what the major differences among these two libs are, as they seem similar to some extent?
dust.js is purely a templating module. So, it allows the combination of json with a template to deliver html output.
Angular.js is client side framework that allows binding of logic to variables defined in a template (your page).
So, with dust.js you are responsible for deciding when to run the json through the template. Typically you feed in the json on the server (or client) and ask it to render the results.
With angular.js when the model (the json) changes the framework re-renders as appropriate. Triggers for that change could be user actions (such as filling a form in) or it could be due to loading some fresh json from a service.
Typically you would use angular.js if you want a single page JS app (think gmail). dust.js is perhaps more akin to a traditional approach with multi pages with content driven by passing in json.
You could even use the both of them in tandem - server side rendering using dust.js with dynamic client side logic in angular.js.
Im creating a website and I chose to do it in AJ.
I have two folders:
Gateways => some php files which retrive data from a mysql db and echos the data as json.
Views => Partial html files which are basically the template for each page. eg Users, Items, etc.
then I have a index.js file which handels the request process and routing:
angular.module('Index',['addon'],function($routeProvider,$locationProvider){
$locationProvider.html5Mode(true).hashPrefix("!");
$routeProvider.otherwise({
templateUrl: '/views/index.html',
controller: "index"
}).when("/items/",{
templateUrl: '/views/items.html',
controller: "items"
})
}).
controller("index",function($scope,$http){
$scope.users = [];
$http.get("gateways/list.php").
success(function(d){
console.log(d);
if(angular.isArray(d)){
$scope.users = d;
}
});
}).
controller("items",function($scope,$http,$routeParams){
$scope.items = [];
$http.get("gateways/single.php").
success(function(d){
if(angular.isArray(d)){
$scope.items = d;
}
});
}).
What is the point of all this route providers in AJ except its elegancy?
Dont they just slow down the site because of number of the requests?
I could just write the php code from the gateways files directly in the templates files?
Am I doing it in the wrong way?
You might be missing the point of using frameworks like AngularJS. They are mostly for Single Page application and ajax intensive. And let me begin that the number of requests don't really slow down application. Remember how Gmail used to be at first without Ajax ? Was it faster than the current implementation ?
Now, when you build a single page application, the app sends req to server and server responds in JSON or XML. In frameworks like AngularJS or any other, server sends the JSON response and we render them using client side templates or DOM. This saves enormous resource from the server side since server doesn't have to parse the array and render the template. So if server had to render a table which has 100 rows, the bandwidth to send to your browser might be 20KB whereas only JSON might be 5KB and a string or DOM template with 1KB to do the rendering. So, you're actually having your visitor's browser do a lot of job. It's all about calculations/computations. Think of a statistics table where there are columns and some computed values to be presented in a data grid. With Client side frameworks, your server would just respond as JSON and browser (with JavaScript) will parse,calculate and render it in template.
As for the question of using a routerProvider, it's essential to bookmark and use browser navigation button. Just like a traditional url has a view, a URL in client side app has a view which should be bookmarkable and should support navigation.
AngularJS, as a JS framework, works it's magic in the client - meaning it's your computer that processes the template files, applying any logic needed. PHP can't do that - it's a strictly server-side language. When you request a PHP "file" via AJAX calls, you don't really get the php file, but the processed output that your servers produces (in this case, a list of users that it will map to an object). If you simply include the PHP logic in your templates, in the best of cases the HTML that angularJS reads will have the list you need to show, but there won't be an actual list model (that angular can filter/change/reorder/save/delete at will) in the angular scope.
But you are right, at the level you are working on it can seem to only complicate and slow down processes (with the minor advantage of simplifying your work). But when things get denser, that modularization (and separating the controller (i.e. Users controller) from the different views it can be applied to (view, list, edit, details, etc) is what keeps your application structured.
I don't think they slow down the site in any way. If your concern is retrieving both the html and the json for each page, that is not how it works.
The html templates are retrieved, compiled and cached only once by angular-js. You can see this using some debug tool, like firebug.
So when the user switches to a different page you only make a json request to the server, which -generally- is a faster and lightweight operation than rendering html server side and retrieving the full html. (anyway, nothing stops you from doing that if it is better for you)