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 8 years ago.
Improve this question
I am new to angularJS and I went thru this tutorial on it but did not find anything pertaining to how to create or handle UI elements like modal windows, date controls, file upload with progress bar, input validation, etc. What I've understood from this is that Angular was not originally made for UI like bootstrap is, but only for handling data from the server. After that I still have to inject other jquery controls for all the stuff I mentioned above using either bootstrap or similar other third party jQuery controls and make everything work together.
After a little digging around I found this. Now I am confused as to which way to go about learning angular and following best practices for development using angular. Any guides that you can recommend? I intend to have my next project which is an online photo library driven entirely by angular on the client side with MVC on the server side.
More specifically I'd be interested in knowing how much of the following I can do purely with Angular along with some documentation explaining how its done and which of these I will need to rely on other controls or plain jQuery along with some documentation on how everything plays together:
Handling exceptions thrown by services on the client side using Angular
Using UI controls like modal popups, Grids, date controls, file upload controls (large files) with progress bar
Validation of user input on the page.
Thanks for your time.
Let me try to addess your concerns
Handling exceptions thrown by services on the client side using
Angular
This can be handled case by case basic or at a global level by using response interceptors. See these examples
http://www.webdeveasy.com/interceptors-in-angularjs-and-useful-examples/ and
https://medium.com/opinionated-angularjs/techniques-for-authentication-in-angularjs-applications-7bbf0346acec which shows how you can interceptors are used to catch 401, 403 errors from server.
Using UI controls like modal popups, Grids, date controls, file upload
controls (large files) with progress bar
As you have pointed out ui-bootstrap is one library that provides a decent set of elements that can be used for your project, written in Angular. Since the framework is very popular now there are angularjs ports for almost everything that is available in jquery. If not you can roll out your own directives for UI elements.
Validation of user input on the page.
AngularJS form validation provides a decent set of primitives that can help you implement validations. Developers around have also written their own directives which extend the default validations such as
https://github.com/huei90/angular-validation
https://github.com/kelp404/angular-validator
https://github.com/nelsonomuto/angular-ui-form-validation
http://angular-ui.github.io/ui-utils/
http://blog.technovert.com/2014/03/angularjs-form-validation-library-directives/
Basically, there's no limit to what you can do with AngularJS. There's just a learning curve.
The framework is somewhat confusing at first, but you'll quickly catch up.
Angular-UI is good, learn to use it. I almost never use jQuery.
For starters, I'd recommend building a basic CRUD UI which would hit a RESTful API. Why RESTful? AngularJS plays nicely with these thanks to the $resource factory.
You can then check out how to manage errors from http response. You could then polish your skills and avoid some errors with some client-side validations.
A few more things to check out :
http://ruoyusun.com/2013/05/25/things-i-wish-i-were-told-about-angular-js.html
egghead tutorials
thinkster tutorials
And of course, StackOverflow is a wonderful resource about
angularJS!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I will start a new .Net MVC project with a small team. It have five members, two back-end devs and three front-end devs.
The front-end members will work separately, building a html version of this project using tools like gulp/grunt, less/saas, jade and others frameworks. They prefer to use editors like Sublime and will run interface tests in many differents devices in real time.
They not able to work with MVC specifically Razor view engine, so we need two repositories, one to front and another to back.The back-end developer in the process ever need to catch the built html and suit it in Razor MVC.
Any ideas how to improve this process? How can i reduce the technical gap between back devs and front devs?
IMO you are trying too hard to accommodate the skills/desires of your team members. You will not get good cohesion from the client side with the server side if you completely ignore Razor/CSHTML. Your overall architecture/design should come first, and dictate these decisions. Of course you would take your team's skills into consideration, such that you wouldn't make a team of Java developers adopt C++. But you are taking this to an extreme by basically throwing consideration for design/architecture out of the window, and saying you will divide the application based on what your devs are willing to work with.
My opinions aside, you can make this work, but somewhat painfully.
For one, developing HTML apges first in a vacuum without consideration for interactions with the server is either going to result in very crippled interface that is more like static website from the 90s. There are a few cases where you can build a single-page-application that's pure javascript with no AJAX requests, but these scenarios are very rare.
Therefore, you need to either build the server-side first, or have a design step that mocks up the page and talk through how it will work.
1) Design a page and it's features, and how it interacts with the server. Identify what interactions are navigation actions, such as clicking a link to navigate to another page, versus those which are AJAX operations. Do NOT implement HTML, that comes later. As a team review what each dev mocks up and make sure they've thought through all of the interactions thoroughly.
From this, list what server side operations are needed in the controller for that page:
agree upon URLs
is it GET/POST
is it AJAX
whether it returns a page, partial HTML fragment, or JSON.
what parameter names for each are and data types
2) Your backend developers create controllers, exposing actions based on agreed upon design. CSHTML will for now be stubs and return nothing.
3) Your frontend developers create HTML/javascript to consume these.
They will be able to point ajax operations to the controllers, but they will need to mock what is returned since the Controllers don't know what HTML they should be returning yet.
4) Front end devs provide HTML to back end devs to incorporate into the project so that actions/partial views return the HTML or HTML fragments.
The problem is you are going to constantly be iterating through frontend devs giving HTML to backend devs to incorporate into the MVC project so that the actions that return HTML and or AJAX actions that return partial HTML fragments (PartialView) can be tested.
It makes for a very non-agile process.
You won't be able to take advantage of many frameworks for MVC which assume you are using Razor views/HTML helpers. Many frameworks for compressing/bundling javascript/less/css which integrate well with MVC are not going to be viable. You can still do this stuff, but you'll have a workflow that is not as smooth and will involve more hacking it together yourself.
I would like to point out that almost all javascript frameworks work great within CSHTML. From the client side perspective, MVC/CSHTML doesn't introduce any strangeness that prevents you from building very interactive pages. You can build a CSHTML page that is pure HTML and javascript, and makes AJAX calls to controllers, but trying to take that outside of the MVC project is going to cripple the development workflow. Designing and implementing an interactive page requires alot of consideration for how the actions on the server side are implemented.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am working in Asp.net MVC for last 1 year but I have never used AngularJs , BackboneJs or KnockoutJs . Now I want to use it in my project but I am little bit confuse that for MVC which is one is Best . Somewhere I read that AngularJs has best perfomance but mostly used with MVVM framework so kindly provide me proper guidance that with Asp.net MVC which js is best either AngularJs or BackboneJs or KnockoutJs ?
Thanks in Advance.
If you are building single page application you need a SPA framework. It should include two-way data-binding, client-side routing, page composition, navigation, screen state management, module system, bundling. You can choose between Angular and Durandal. They both provide very similar functionality, but in my opinion, Durandal is the most complete SPA framework, which is very easy to use. Both Durandal and Angular can be used with Breezejs to build data centric applications.
check Durandal, Durandal Auth and HotTowel Angular
If you are building ASP.NET MVC application, then all you need on the client side is two-way data binding to reduce DOM manipulations. In my opionion, it's an overkill to use angular just for data-binding. Backbone or Knockout are good choices, but Angular can be used as well.
It depends on the nature of your application. And since you did not
describe it in great detail, it is an impossible question to answer. I
find Backbone to be the easiest, but I work in Angular all day.
Performance is more up to the coder than the framework, in my opinion.
Are you doing heavy DOM manipulation? I would use jquery and backbone
Very data driven app? Angular with it's nice data binding
Game programming? none, direct to canvas, maybe a game engine - Source
Also, take a look at https://stackoverflow.com/questions/5112899/knockout-js-vs-backbone-js
You can check the following source. It's really complete:
http://www.infoq.com/research/top-javascript-mvc-frameworks
Personally, I'd go for Angular just because of its performance, but there are plenty of reasons...
I'm using Knockout with ASP.NET MVC/Web API at work, but I have played with Angular at home and honestly prefer that. Bear in mind though that Knockout solves a much smaller problem than does Angular, the latter being a complete SPA framework (with services, HTML directives etc). To compare apples to apples, you should consider Knockout in tandem with Durandal, as this is a full-blown SPA framework like Angular.
From practical experience I suspect that memory leaks are easier to avoid with Angular than Knockout, since Knockout produces references implicitly as you subscribe to observables (typically via ko.computed) and we had a very hard time trying to track down such memory leaks due to undiciplined taking of Knockout subscriptions without cleaning up. With Angular I couldn't see that you have the same problem, as you don't subscribe directly to mutating variables ("observables"). Instead, the framework is in full control of applying model changes, which might be harder to grasp initially, but ultimately leads to better maintainability.
I have not tried knockout or backbone. With Angular I have worked with ASP.NET MVC. I personally did not like using MVC views. As Angular requires POJO (Plain Old JavaScript Objects) , So, I changed to Web Api and Angular. To be honest I am very satisfied with Angular because of following reasons:
DOM maniuplations are done where they belong.
Two way binding
Designed with unit testing
Services are where they belong
Designed with HTML5 in mind
Ability to create HTML markup to suit business needs (directives) and many more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been in some discussions lately and the talk is about moving over to ASP.NET MVC and Knockout for future work on a product that is currently ASP.NET web forms. This product has many of the characteristics of the general current definition of a SPA.
I've never quite seen how MVC actually fits in when you start generating all your views with JS view models which get their data from calls to JSON web services.
Is there a "sweet spot" that leverages the best parts of Knockout w/JS models and JSON and the MVC framework?
Here are some things that I've been thinking about this (a little random - just seeing if I can spur on some discussion/answers):
When would you use Knockout vs. Razor? Knockout generates the view elements at run time on the client browser. Razor runs as part of the server request before the client receives the response. Are there times that one is clearly better than the other or does it come down to personal taste?
Is there value in keeping more code under the guise of C#/Razor for the purpose of code completion? Also, when exceptions get thrown, stack tracing to compiled code seems easier than JS debugging.
Is it better to completely separate the view from the back-end by creating a blank ASP.NET application and an independent Web API project?
Lots of great questions, I'll share some of my thoughts on the subjects. (Questions have been paraphrased):
1) Is there a place for MVC in a Knockout world? - Absolutely. MVC is a lot more than just Razor. Server side routing, Areas, Authentication, and more, are all provided by MVC. So in my mind, I can still use MVC for all the "admin and organization" but still have all my Views be primarily (but not necessarily completely) AJAX driven. I have discussed using MVC and KO together on SO before. I also have a video dedicated to that topic at WintellectNOW dot com.
2) When should I use Razor? - Let's actually switch up the terminology. It really isn't about Razor vs. Knockout: it's really about server-side vs. client-side rendering.
So when should you use server-side rendering? One ideal time for this is when you are loading data that only has to be done once when the page is initialized. For example, if you have a list of States for a drop down, and that list is extremely unlikely to change, go ahead and load that on the server side. Why turn around and make another request back to an API in that case? I would reserve those calls for dynamic or context sensitive data.
3) Is there value in keeping more code in C# for tooling purposes? - IMHO, no. It's true that debugging JS can be painful, but that is not enough justification for me to disregard all the awesome things I can do client side. It's worth the occasional frustration to provide a better user experience.
4) Should I move Web API to a different project to keep the code separate. - It completely depends on the needs of the project. If the Web API project is going to service multiple applications, then YES it should be in a separate project. That will also put it on a separate DOMAIN, SUB, PORT, or something to differentiate it from the rest of the Web app. Doing so introduces Cross Origin Resources Sharing (CORS) issues. CORS is a particular hell I wouldn't go through unless absolutely necessary. If your Web API is only going to service your single web app, do yourself a favor and keep it in the same project.
As with everything else, a lot of this comes down to personal preference. Mine is to use Server side for managing the bigger picture of my app, and client side for all the UI/UX.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Personally Coffeescript is ok, but I would rather it be a supporting player in my Rails app, not most of the logic. From what I can see, you still have to duplicate a lot of the logic when using Backbone.js or Spine.js in Rails. Can I not get the benefits of these frameworks or make what is essentially a single page app with js for real time updates using just rack-pjax?
Well what do you want to achieve? No more page refreshes? In that case rack-pjax should work. If you want more speed or a responsive UI then I'm afraid it won't be a good solution.
A single page app is preferred imo because it seriously decreases the load and complexity on the server + there is a nice abstraction between viewlogic & serverlogic.
Your server would basically be an API and your client would render all of the API data to the browser. This way the server is heavily simplified and has a lot less work to do. (win!)
On the client side we can also see a lot of improvements. If done right it rerenders itself continuously based on events and statechanges made to the data. This approach leads to much less coupling (and duplication) in your UI layer and a more responsive UI for the users. (win!)
If you don't care much about that then go ahead and use pjax :)
Keep in mind though that rewriting an existing server-side-view-rendering app to a single page app using a JS frontend is tricky business. It'll probably end up in a major rewrite. You could also experiment with writing just parts of your page in a JS frontend.
While rack-pjax does prevent the browser from refreshing the page with each request, the server is still sending an entire HTML page with each request. If your goal is a "single page" app with no page refreshes, rack-pjax will work but you're going to save a lot of bandwidth and have a much more responsive app if you use a framework that deals with JSON instead of loading an entire page.
For a simple app, I'd recommend starting with something like Backbone or Spine. For more complicated apps, you'll quickly find yourself writing a lot of boilerplate code with those smaller frameworks and you'd probably be better off letting something like Ember or Cappuccino handle most of the heavy lifting for you.
If you want a single-page app, it's a given that some or most of your logic is going to be on the frontend, either written directly in javascript or written in coffeescript and compiled to javascript. Of course, you do still need certain logic at the server (like validations.. always assume, even with validation logic in your JS code, that people can and will send bad data to the server).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm wondering if someone can give some advice as to which is 'better'. Twitter-bootstrap or JQuery mobile?
Thanks,
-peter
I don't know if "better" is something you can answer since they serve different purposes. Bootstrap is great all-purpose CSS library whereas jQueryMobile is closer to a framework. Meaning jQueryMobile doesn't just make your pages look nice- it gives a lot of mobile oriented features such as- swipe-events, page transitions, allows for single page applications (since it will only show a single div with data-role='page' at a time), AJAX preload and history API, and lots of touch friendly components/widgets. Whereas bootstrap is foremost a CSS library mostly for desktop but works on mobile as well especially since 2.0 comes with media queries built in. Bootstrap will not help you with touch friendly lists, checkboxes, select menu's, etc.
One more thing to point out, jQueryMobile takes your markup and dresses it with all sorts of pretty stuff using JavaScript. Bootstrap has some javascript, but only for optional components, the rest is CSS.
So to answer IMHO- if you're a making a web application that you explicitly plan on using primarily on mobile devices go with jQueryMobile; Anything else go with Bootstrap- it's really quite awesome.
jQuery mobile != twitter bootstrap. Twitter bootstrap is used to create responsive layouts [a single CSS can work on big as well as small screen size]. jQuery mobile is intended for mobile development. So if you develop a site using jQuery mobile won't give a good layout consistency in all desktop browsers.
While I agree that Twitter Bootstrap != jQuery Mobile, you can develop mobile sites with Bootstrap. After spending the last couple months developing a mobile site using jQuery Mobile, my conclusion is this:
The concept behind jQuery Mobile is perfect. The "page" concept integrates very well with server side technologies (ASP.Net MVC in my case). It allows you to develop pages as individual files, rendered mostly on the server, as you're already used to doing and probably desire to do.
However, in its current state, it can get very slow and very buggy if you try to do too much with it. I've run into problem after problem with it on my project.
So I'd say, if your site isn't too complicated (e.g. no swiping, no wizards), then go with jQuery Mobile. Otherwise, think about waiting for the project to mature. It's almost there.
I think the main differences are apparent by how the two projects identify themselves:
Bootstrap:
"Sleek, intuitive, and powerful front-end framework for faster and easier web development."
jQuery Mobile:
"Touch-Optimized Web Framework for Smartphones & Tablets."
Both frameworks are aiming at meeting different needs and accomplishing different things. I've used both of them in separate projects and each of them have strengths and weaknesses, but it would be a disservice to both to directly compare them. It's our job as programmers/designers/engineers to decide the goal for your project and pick the best tool for the job.
It depends on what you are going to do with it. I prefer Bootstrap in most cases, because i like the base css plus you can compile with responsive.less so you got a mobile version too. Iam much faster when prototyping with bootstrap because it is very loose coupled and just plain markup (except for the plugins, those are great too).