We built a ajax website and are thinking of migrating to javascriptMVC.
Our site has our own home-made controller which handles ajax calls for html and JS and the UI uses JQuery UI widgets extensively.
I read a bit about javascriptMVC and liked the notion of how models are being handled.
especially how easy it is to interact with ajax to read you data.
I guess i always though of models as JSON objects (structs in a way) and forgot how powerful adding methods to the models could prove to be.
However, going deeper into the javascriptMVC i noticed the controller takes much of the JQuery UI widgets responsibilities. i hate to drop our already working widgets. What are our options?
Can we adopt just the model of the JQueryMX? is it wise?
Should we change our controller and widgets completely and do an all-in into JavascriptMVC?
Any other options?
Speaking of goals - we wish to have a framework for future Ajax sites (controller + widgets).
You can wrap JQuery UI widgets inside of JMVC controllers as an intermediate step but you are losing an important advantage controllers have over typical JQuery plugins. Most JQuery plugins are written in an all-or-nothing style (look at jqGrid as an example) - mixing multiple JQuery plugins is typically impossible or at least quite hard and leads to an ugly codebase that does not perform well (memory leak issues etc.).
JMVC controllers can be designed to be more lightweight so they work well in combination with other controllers. Look at mxui for the "right" way to build widgets in JQueryUI
https://github.com/jupiterjs/mxui
http://forum.javascriptmvc.com/topic/what-are-the-plans-for-mxui
Related
Client side complexity will increase by adding angular mechanisms such as client side modules, controllers and models!
in the other hand by developing MVC .Net web applications we have a good pattern so supports a lot of features and specially increasing re-useability, which we generally miss that in angular based web applications
angular pages with MVC apps causes duplicate codes in server side and client side. i don't know any way to avoid duplicate models and also strongly-typed models!
ok, i know implementing strongly typed model mechanism which models comes from server side is hard. but at least i want to prevent duplicate code with some existing techniques or NEW techniques!
First: are there existing approach? i did not find after lots of searching.
Scenario:
I'm developing a Plugin-Based MVC application which has core and some plugins that they have been implemented on MVC atchitecture. so all of them have own controllers and also own actions and views. The starting page or the so called "Main Application" which starts at first of core staring and contains my plugins contents within, is a SPA(Single Page Application) application that is based on angular libraries.
Now you consider that we're going to have implement all of the our plugin views just in Main SPA application! for example every view in plugins maybe have some forms, models or inputs ... . but anything within there should be angular-based! and it increase client side complexity. in the other hands implementing some rules and helpers for plugins developers seems necessary to preventing irregularity.
my solution is customizing the WebViewPage and enrich it to have lots of helpers to provide angular elements and manage them. for example adding Angular helper which have own BeginForm method instead of Html.BeginForm, and it configures some attributed such as ng-submit and so on.
Second : Is there any better approach or existing better techniques to do it?
I am developing a hybrid mobile app using jQuery Mobile and AngularJS.
I decided to use a mix of the two for the following:
jQuery Mobile
good UI features
not too heavyweight (compared to Sencha Touch, for example)
AngularJS
good performance and resource management (caching, asynchronous requests)
personal experience
I have little to no experience with jQuery Mobile and, as I was learning, I noticed a potential conflict between the page navigation models of the two.
Should I use only one ?
If yes, which one is better suited for my needs ?
Are there any gotchas with this setup ?
Many thanks.
You can't compare them to each other.
Angular.js (like Backbone, Ember eg.) are MV* Frameworks (for SPA) which used to render html templates/views directly in the client instead of server. So you have a lot of application logic now in your frontend and this Frameworks are made to make your life better, coding this.
jQuery Mobile on the other side is a pure widget/plugin library. The AJAX navigation plugin load pages (something static, like html) into the DOM via AJAX. So you have to pre-render this pages on the server somehow.
If you started to build a SPA with Angular it doesn't make sense to use jQuery Mobile's AJAX navigation at all. (If it's a native mobile app you have no server anyway.)
Sure, you won't get far without an UI component library so use one of your choice (eg. jQM) but work with Angular's directives to init the plugins/widgets correctly on your DOM elements since a $(document).ready(...) or a $(document).on( "pageload", ... ) doesn't know anything about your Angular views.
Take a look at following projects:
http://angular-ui.github.io
https://github.com/angular-widgets/angular-jqm
This has been already addressed in HERE
Basically the article states that trying to intercept the navigation from angular can be painful, so leave all the routing jqm
TL;DR
What are the best practices when using .NET Razor views and AngularJS?
Context
We are developing a public website (not an intranet application) using mvc4 with razor, and we weren't very familiar with client script, so we started with what we knew: jQuery.
But now things are getting more complicated and we'd like to switch to AngularJS.
On the .NET part, we use Razor templates and UIHintAttribute (plus some custom ones) to render the right html "control". We also add custom html attributes to give extra information to the jQuery part (like title for a tooltip....)
So we already use a declarative way of setting the user interface behavior, that's why AngularJS seems a good option.
Questions
Since we already have models defined server side, and since AngularJS also uses models, wouldn't it force us to duplicate code?
How do we deal with data binding feature, since we already do some binding server side (in the views). Should we make a completely asynchronous application, making AJAX calls from AngularJS to load data, or can we mix both?
Anything else we should be aware of when trying to use both of these technologies?
I did some research on Google, but I can't find detailed ways of mixing Razor views and templates with AngularJS... Perhaps that's just not a good thing to do?
We dealt with this issue for months when working with MVC plus another JavaScript framework (Knockout). Ultimately, if you're going to be using a client-side MV* framework for rendering your user interface, you will find that mostly ditching Razor is going to be your best bet.
Most of the major MV* JavaScript frameworks, including AngularJS, assume you will be maintaining UI state and rendering your user interface based on JavaScript models or view models. Trying to mix in server-side rendering is just not going to work very well.
That's not to say there is no use for MVC when it comes to developing an Angular application. You can still take advantage of some great features like ASP.NET Bundling and Minification. And sometimes it works really well to embed JSON directly into the page using a Razor view or partial as opposed to making an additional AJAX call.
As for models, you may want to take a look at Breeze.js. It's a JavaScript library for data access that goes great with ASP.NET on the server side to share model metadata.
We wrote our own data binding mechanism that synchronizes the angular.js model with a view model on the server side. The javascript model is generated from a JSON serialization of the server-side view model to avoid the duplicate code that you were talking about.
We are using SignalR to update the client's view model from the server.
Server-side changes of the C# view model properties are sent to the client as a packet containing the path to the property, e.g. Persons[42].Address.City, and the value itself, e.g. New York. The view model inherits a base class that takes care of generating the property path, so the actual view model looks quite clean and we can concentrate on business logic.
Client-side changes of the javascript view model properties are sent to the server in the same way. To catch the change events, we encapsulate all fields of the original javascript model in get/set properties where the setter sends the update packet to the server.
Server-side methods of the view model can be invoked in a similar way. All objects in the view model have an invokeMethod function that can be used like this: Products[42].Manufacturer.invokeMethod('SendEmail', 'mailsubject', 'mailbody'). This will send a packet to the server containing the method path Products[42].Manufacturer.SendEmail and the arguments as an array of ['mailsubject','mailbody'].
In conclusion, the html view (kind of) binds to the view model on the server side where other systems, such as regular Razor views can work on the same objects.
The source code can be found here: SharpAngie.
Just to prefix this question, I've decided to take a look at moving our works old legacy systems (40+ programs from vb6, vba, vb.net to c#.net) into two separate systems using the same DAL (barcoding terminals and one web based system) as I spend most my day fixing crummy or non existant business logic in 15 year old vba programs. I've recently built an entity framework model complete with fluent validation and couldn't be happier with it after using it for a bit.
The small team is familiar with webforms (but not very) but the last few days I've explored MVC Razor. I was loving MVC Framework until I tried to start trying to add more functions onto the same page and then it seemed arbitrarily hard to replicate our a recent system I put in a webform. Before, I would eager load a customer and all it's child entities and then bind that to single page for the customer so they could access everything (which is what they wanted), it works okay and isn't slow. From this single page I could edit all their account details/contacts/emails/phones/jobs.
All the examples I've done and seen in MVC handle a single update, a single edit etc but surely you can't separate out every single action into a new view/page? I can pass a rich model through to the view in MVC, but then its a pain trying to update all the different child entities.
This is probably the exact design that MVC wasn't designed for maybe, which is okay, I'm willing to adapt it if MVC will be a better platform going forward, but how are you meant to handle adding this complexity in? Some methods I've seen:
Lots of partial views? passing child info to them (or the id and lazy loading it)?
I've seen methods that wrap multiple <forms> around everything and handle actions that way.
Separate pretty much every task out
If the solution is more lightweight and easier to maintain I'll go research whatever I need to I just wanted at an earlier stage to see if I'm wasting my time. Any pointers to the correct questions I should be asking would be greatly appreciated.
ASP.NET MVC is neither more or less better equipped to deal with complex pages than any other technology out there.
Certainly, MVC requires more low-level work than a Web Forms app, with no direct binding support, but in most cases this is a good thing and provides much more flexibility in how your page is rendered.
One of the whole ideas of MVC is to give you more control over things, but that control leads to requiring more knowledge and more effort on your part in most non-trivial cases. MVC provides a number of tooling functions to speed up trivial work (like creating standard table based CRUD) but when you have complex models, you will have to do much of the work yourself.
This is not that MVC is "ill suited" for it, but just that control and flexibility has a trade off with more responsibility on your part.
In your case, you simply create a view model with all the fields you want. Then, you create your form to edit those fields. In your controller, you will need to unflatten that view model and create or update the necessary records in the database. It's not difficult, but it's more work than WebForms databinding.
You could look into more advanced tools (commercial) for MVC, such as Telerik's tools, which have developed more of a databinding like interface, but MVC is not a drag-n-drop technology, and requires you to hook things up and write the various logic for what is done.
If you need drag-n-drop, databound functionality, then no.. MVC is not the correct technology. But then WebForms requires you to accept many compromises as well, and ties your hands in many ways.
You could use partial views, however I seldom use them. I prefer to instead use Editor/DisplayTemplates as these take care of naming your form fields correctly, even for collections and complex objects. PartialViews tend to have lots of gotchas if you aren't careful. I pretty much only use them as fancy includes, or when using Ajax.
I'm not sure what you meay by "wrap multiple <forms> around everything`. You cannot nest forms in HTML, it's not legal. If you mean place a form around each row of a table, that isn't valid html either in most cases (it's not legal to put a form in a between the table and the tr).
It would help if you had a specific problem that you could ask about, vague objections don't help us solve your issue.
You can accomplish anything in MVC that you can in WebForms. The difference is MVC will usually require you to write more code as it doesn't really offer you any "controls" to drop on your page.
In WebForms, it's easy to create a master/detail view with a GridView, FormView and then wrap everything in an UpdatePanel for automagical AJAX support.
In MVC, while you do have helpers like the WebGrid and AjaxHelpers extension methods, creating views and/or pages requires more understanding of how things work to get the desired functionality. When I start a new MVC project, here's what I include:
Backbone.js - client-side "ORM" that performs CRUD operations
against RESTful* APIs
Knockout.js - client-side view models and
real-time data-binding for your views
Knockback.js - wraps
Backbone models in Knockout view models
Using these three frameworks, you can quickly create powerful single-page apps using MVC and WebAPI.
There are a few pages here addressing usage of jQuery with .net masterpages - fewer re: masterpages in MVC in .net MVC apps. But those few seem to be making distinctions re pre-release versions of MVC.
Is there now a consensus regarding how and where to include the lib and what potential problems we need to be aware of?
It _looks as though things are fairly straight forward...put the include in the masterpage's head and stuff works. (as it has for me _so far). I guess I'm looking for lessons learned and what to watch out for - i haven't scratched features like partial views and ajax yet.
thx
As Iconic mentioned, you're free to use jQuery however you see fit. I would decide this after planning my site - if only a page or two are using jQuery, I would include it in them only. If my whole site relies on it (like SO does, for example), I would include it in my masterpage. All it takes is a simple tag, and the only thing to watch out for is perhaps some bandwidth, if you expect to have much traffic to only several pages, which does not use jQuery.
There's no magic way to include jQuery. Since it's a client-side library, including it in the master page makes it easy to hook into $(document).ready from any view or partial view.
Once it's at the top of your page, it's trivial to include plugins or hook into events at any point. That way, you can encapsulate jQuery that is specific to your application in the view or partial view itself.