I have an app with Knockout binded views. It loads all HTML upfront, to minimize requests to the server.
I want to introduce Durandal to the app. Is this scenario supported? If so how?
Can you give us some more information?
This scenario is possible, as there nothing which would prevent you from loading your own HTML and binding it with knockout.
You will, however, NOT be able to do this in a way that meets the standards and conventions of this framework.
If you have many html views, my suggestion would be to create a small program which converts these existing views and view-models into their Durandal analogues. It will save you loads of headaches later.
Creating a View
Related
I'm a long time ASP.NET WebForms developer. I'm familiar with MVC as a design pattern and have used it in many apps. I'm a little surprised (and excited) about ASP.NET MVC as I am moving a PoC into beta form using ASP.NET MVC,
Architecturally speaking, I have content templates that I will be using on the site to present content in different layouts. What will be the same across the board is that there will be images and text. How it's presented will depend upon which layout (or skin) the author wishes to use.
Architecturally speaking, which of the two scenarios fits better with the framework?
For each layout I desire, I create a single View and a single View Controller where the VC gets the info from the Model (images/text) and gives it to the View. The info from the model will depend on which article the user wants to see. To use a different layout, the view served would be a different view that contains that layout, and it would use the same VM and same Model.
or
I create a layout that has the layout which is then used by the view to present the content. The view could use a different layout to lay things out differently. Each article would have it's own view and when that view is loaded, a determination is made (based on author intent) which layout to use as the layout for the view. There would be multiple layouts that could be used.
Clearly both will do the job. I am new to ASP.NET MVC, so I am wondering, architecturally, what has been done in the past by those architecting similar cases.
I crossed the same bridge a while back and found that building up core "Base" partial Layouts for particular functionality worked in my favor. If you define base partials then you have a solid foundation for partials that extend that particular functionality using Layouts, moreover, if your controllers send base models to your base layouts then extended partials can build up on top of that. Please note that I am making use of a lot of AjaxBeginForm or pushing back smaller content within a larger model so what is described may be overkill.
I am developing a mobile application using ASP.Net MVC4.0, JQuery Mobile, HTML5.
As I am new to ASP.Net MVC, I am not sure whether to use Razor(.cshtml) or webForm(.aspx) view engine.
Can anyone suggest which view engine I can use to develop a mobile application?
Performance wise which is better, the razor view-engine or webform view-engine?
I don't think there is a performance aspect.
However, I find the Razor syntax beautifully terse. The HTML is far more prominent with Razor, which is what you want when you're developing HTML views.
In various MVC frameworks, view development encourages and requires
code written directly alongside markup. Because the ASPX view engine
was not designed with this goal in mind, the ASP.NET team decided to
build an entirely new view engine with a code-focused templating
approach. The result was a more intelligent parsing engine that is
able to very easily figure out where code stops and where markup
begins, without the developer needing to be very explicit.
There are even open-source view engines, that you might want to look at. For example, Spark View Engine.
Razor is the preferred View Engine for MVC, ASPX View Engine is the legacy View Engine and this option is there for backward compatibility. Here you will find a great article who explain the differences between both.
The ASPX engine is listed first. A site we are working on scaling is using only Razor views. Just having the ASPX engine before the razor engine was causing a huge amount to contention to occur when attempting to scale up the number requests. Doing this:
ViewEngines.Engines.Clear();
//Add Razor Engine
ViewEngines.Engines.Add(new RazorViewEngine());
at startup made a huge difference given that each page access was no longer looking for existence of aspx, ascx files. While it might not appear to affect performance on a single request, as you scale up and see contention and rising CPU percents, this is something one should check.
For the last year, I have delivered several relatively simple single-page apps, essentially almost-alike mortgage and financing calculators, to various customers. These have either been the sole focus of a page, or sidebar apps beside some main content. Since these apps differ by very little else than styling, layout, and a few customer specific parameters, it would mean a high ROI if these SPAs could be consolidated into some kind of library.
How one would go about in doing it in practice is a bit more unclear. What are the key points to consider and/or avoid when creating a library of pre-made interactive components?
They need to
be custom-styled per customer (custom widths, heights, fonts, etc)
not clash with other page elements
... ?
It seems unwise (inflexible) to pre-render html and inline css on the server side, and maybe some kind of half-baked JSON representation would be more appropriate, where the actual assembly would be controlled by some javascript, and styling would be done on the client based on some default stylesheet we provide. Or maybe somehow use GWT (we are a Java shop) to create the widgets.
I am out of my depths here so input would be most welcome.
in this case, possibly a better way to think of this is not creating a library, but creating a "calculator" application (widget) that can be configured for different kinds of calculations and to be themeable
So your focus is on how to create it so you can configure it for different functionality.
As an exercise, I intend to replace all front-facing aspects of my Rails application with Backbone.js. Part of the plan includes redesigning everything right down to the CSS.
The issue I'm struggling with is in delegating responsibility for templates and views.
Is there any benefit to implementing the new front-end entirely in Backbone, hence only using Rails as an API?
How do I strike the right balance between Rails and Backbone when it comes to handling the HTML elements of the application?
Since it seems that nobody is going to post an answer to this I'll offer my two cents as just one point of view (I've written elsewhere about the issue of how to get rails and backbone.js to work well together: rails and backbone working together).
Most people in this situation will tend to drop the rails views altogether and migrate everything to backbone.js.
This is what I've done in a project that I'm working on right now.
This is the natural course of events, and particularly once you start getting used to all the complex interesting things you can do with backbone.js and structured javascript, it becomes difficult to turn back and implement standard stateless HTML pages.
As I mentioned in my other answer linked to above; however, there are costs to completely abandoning HTML views and the stateless layer. In my case, I intend to add back pure HTML pages for non-js-enabled browsers for GET requests only once the app has reached a certain level of functionality. We won't support POST or PUT requests unless the user has javascript enabled (or unless they want to go through the JSON API).
That's the balance I've struck: stateless HTML (no-JS) for accessing data, but JS required for posting/changing data. Your choice will vary depending on your use case and target user.
The other thing that I would mention is that if you have been working with rails HTML views on a project for some time, you might be unprepared for the initial overhead required to switch to backbone.js. This is not simply swapping HAML for ERB: you are migrating from a stateless front-end to a stateful one, and that is a potentially huge change (depending on the complexity of the app). I myself was a bit unprepared for the depth of that change, and had to do a lot of catching up before getting our app back on track after making the switch. And we made the switch very early, with minimal functionality already in-place.
Anyway just a few thoughts, hope they help.
I have many Normalized tables - might be more than 50... I was wondering what is the best approach for defining ViewModels - individual ViewModel for each form or making Common ViewModel for multiple Forms. Because making individual forms might increase the size of the data that needs to be downloaded and it might increase the redundancy of data on the client. i.e. using Category on each form has different set of data for each of them. and On the otherside making common viewmodel for set of Forms might increase the complexity in managing stuff.
Is there any proper article describing such aspect of Development. What is the best practices for managing overall Application so that it will offer optimal performance. (Fetching minimum Data from Server)
Thanks for your time and help.
The amount of views & models will increase the size of your XAP file, which is downloaded completely on open, this can be compressed. Actual performance during use is different and depends on other factors as well, try using SilverlightSpy to get an idea of actual browser performance. It is possible to download parts of your silverlight app as required, but this is an advanced technique.
If Messaging is your main concern, then check out Binary Messaging.
I recommend using a new ViewModel for every view, or nested Usercontrol, then use an event aggregator for communication between models.
Typically you'll want to create a View Model for each View. If two Views display the same data and allow the user to perform the same actions but differ only in UI implementation then they can share a View Model but the goal is to keep your View Models cohesive. If your View Models contain code to operate multiple views you run the risk of implementing the "God Object" anti-pattern. If you find that your View Models all share a certain amount of common code, consider moving that code to a common base class.
Remember that two completely different View Models can manipulate the same Models. This might be the case if two views display the same data but each allows the user to interact with it in a unique way.
I would highly recommend reading Pro WPF and Silverlight MVVM by Gary Hall. It's a great book to get started with MVVM, particularly for use with WPF and/or Silverlight.