I am creating an ExtJS 4 single-page web application, and coming across some issues deciding on the MVC-favoured way of defining and maintaining my application state. I am aware of the global nature of ExtJS 4's stores, and I like the idea of them, but the practicalities of them are called into question on a couple of points.
For example, I have models that could possibly need to scale into the thousands at some point, and the idea of loading all of these into the memory of the client's browser does not strike me as the best of ideas. I would have great performance concerns with trying to do this.
Additionally, my application will have windows, multiples of which that may be viewed at the same time, in addition to multiple grids on the same tab in a tab panel. These views are supposed to show a subset of the models based on their properties. If these views are tied to the same global store and its models, they will be affected by operations such as filter and will effectively be restricted to showing the same set of models, which is not what I am trying to achieve.
So my actual question is how do I go about handling this situation? I have read a similar concern on StackOverflow that called for the views to hold their own instance of the store rather than using the global instance, but I am not sure this fits the MVC pattern correctly. My current thinking is along the lines of having a controller that manages the state and holds the various instances of the stores so they are not directly tied to the views and yet they can still be accessed on event calls and by other controllers. Is this a good solution or am I missing something?
Well, there's a lot going on in your question. First of all, I think you are over-thinking stores a bit. Ultimately, a store is just a cache of model instances. So you can create as many instances of them that you want, depending on the requirements of your application. If you want to try to use a single store to manage the entire data set, you can certainly do that, but you'll have to be VERY aware and vigilant in keeping track of filters/sorters/etc that you apply throughout the flow of your application.
Re: the scale of your application's data, I would strongly suggest not trying to load all your model instances in at the same time (depending on the size and complexity of data, of course). Unless you actually need all possible instances available in the application at all times, I would adopt an approach that loads only what you need, depending on the scenario. If you need access to thousands of records, you can always apply remote filters to still deal with the whole data set on the server side, but only actually interact with a subset of the data on the client side.
Ultimately, I wouldn't worry so much about whether or not a particular approach "fits" the MVC pattern (which is itself a very particular flavor in Ext JS, a flavor not desired by everyone...). Yes, you want to create an approach that is extensible and manageable; however, I would argue that the requirements of your application should drive how you utilize the MVC conventions that Ext JS 4 provides, rather than allowing the MVC conventions to determine your business requirements.
Related
I have developed some SAPUI5 mobile apps and I'd like to merge them into a portal (with tiles) so I can switch between them as a "reputation".
Now I would like to know, what would be the "best" way to implement this case?
At the moment the apps have got a controller and views. My first idea was to build a "portal-app" which includes all the views of the other apps with an own controller but then I noticed that the performance has decreased (because all resources (OData-models etc.) load when starting the portal-app).
I also tried to link them (all with their own index.html) but this case seems not to be the right one.
So is there a way to load the views dynamicly or a whole app and how can I do that?
First of all, SAP's official solution for this problem is called SAP Fiori Launchpad. However, it's much more complex to set up (you need an underlying application server which holds SAP Fiori. You need to handle user roles and assign applications to roles). However, it's great for inspiration. (Here you can check it)
You can create a separate component which holds the references to other applications. Your applications can be referenced from Tiles.
I don't know the current implementation of your applications, but it's recommended to implement them as components (UI components if they have visual representation).
With components, you will be able to use Routing (navigating between views, or even components using hashes (urls)), which helps you to manage resources and services properly. With this you can prevent unwanted odata requests as well.
It can be a big step forward from a simple application architecture, but it's worth it.
Of course, you can implement one simple application without components. In this case you can experience the mentioned performance issues. Consider to move data intensive operations into event handlers and perform these tasks asynchronously.
I was suggested to use BreezeJs for an AngularJs project and I saw that it has some really interesting features.
In my case the main interests would be in caching, tracking changes, some light querying, and validation.
I think those features can be implemented at some level in AngularJs without too much trouble:
Caching can be accomplished by storing the data, or API calls results in objects in services? Given the services nature, the data will be accessible throughout the app, and they will be cached.
Tracking changes is done by angular with 2-way data binding. Here you may drop some of that 2-way binding(less watchers in Angular), but Breeze will do that checking in parallel.
Queries are something I don't need to be very complex, so Angular filters will do the work. The same thing applies to validations, I have enough from Angular.
For data handling I saw that the EntityManager can be really handy.
I get the feeling that for applications, not too complex, you can achieve almost all the things BreezeJs offers directly in AngularJs, in a nice clean way, without the need of adding one more library.
What am I missing from BreezeJs?
You're missing just about everything ;-)
Angular doesn't do any of the things you mentioned.
Breeze caching ensures entity identity, just-in-time maintenance of navigation properties, entity dirty-checking, query-over-cache, and much more. None of that in Angular "cache".
Angular doesn't track changes to entities. It tracks changes to visible bindings; if it ain't on screen, it ain't tracked. Once it is no longer on screen, the "tracking" is gone. There is no notion of model change-state in Angular.
Angular filters are for in-memory filtering, not querying a server (or a cache).
Angular validations are purely HTML-facing. They don't validate the model. They do not prevent attempts to save invalid entities. They offer no means to answer the question "is this entity-or-property valid and if not, how is it invalid?". With ng you ask about the validity of forms, not entities. It can't help you enforce a business rule everywhere; the best you can do is try to decorate every HTML element that touches a model property with every business rule applicable validation (which may mean minting custom directives for your custom validation rules). Good luck with that.
I am not knocking Angular at all. Angular concentrates on functionality you need to organize your application and interact with HTML. It throws in $http to make server requests but that's as far "down" into the model layer as it goes. In fact, it quite deliberately (and properly IMO) makes no assumptions about the model. Therefore, it cannot do the things that Breeze does nor should it.
If you want to delve a bit deeper, you might look at the slides I presented at ngConf 2014 that try to explain what Breeze does and the synergy between Angular and Breeze.
I don't know whether you need Breeze for your application. But there is nothing in Angular that approximates Breeze. So if you want the functionality in Breeze you have two choices:
use Breeze
roll your own framework, leveraging whatever you can from ng (of which little is directly applicable).
Hope that clarifies.
There are a number of popular frameworks around to provide data binding between objects and views. This is a great idea; when the data changes, the view is updated automagically and vice versa. However, in mobile web apps, wrapped with Phonegap or equivalent, the app usually consists of one single html page holding multiple "views" (usually divs used as containers). Only one view is displayed at a time, which means that only data bindings belonging to the current view need to be calculated and updated. If all views are updated all the time, it means a lot of unnecessary calculation and updates of invisible DOM elements. This should be avoided, since performance often is a problem in these apps.
What is the case with current JS frameworks? How do they handle this? I am especially interested in Angular.JS, but if there are other frameworks that handle the issue better, I am very curious to know.
You can try knockout.js. Knockout allows you to data-bind subset of elements on your page
Suppose I am writing a simple single-page web application in JavaScript. The application just displays employee records. User enters search parameters, the application fetches employees records from the server using AJAX and displays them in the web page.
The application state is search params and employees. How to store them in the application? I see two options:
just use DOM to store the state implicitly.
create data structures for search params and employees and synch them with the DOM.
Does it make sense? What are the pros and cons of these two options?
If you are targeting modern browsers, Web Storage would be a good option for you to look into.
Good write up here: http://sixrevisions.com/html/introduction-web-storage/
That way all load would be kept within the client and data would persist between requests and if user leaves and comes back to application.
The options you mentioned which I'm guessing means you would store data within hidden DOM elements would be easy to develop however you will lose all persistence. If you're going to go down this path, why not just store the data directly in javascript objects?
Another good read: http://diveintohtml5.info/storage.html
Definitely the latter. The DOM was never designed as a data structure. On the other hand, creating an architecture to keep the DOM in sync with your custom data structure can be a pain.
Luckily, there are frameworks that can help you with this. Most of these follow an MVC- (or MV*)-like design pattern. Examples include Backbone.js, AngularJS, Spine, Agility.js, JavaScriptMVC and many others. Have a look around.
Also check out this project: TodoMVC. It might help you decide whether to use a framework like this and, if so, which one.
If you want them to be persistant, you can't use the DOM, and you shouldn't. HTML is for your user interface and linking everything together, not for data storage of your app. You have a couple of options. You can use global variables in your JavaScript, but you have to remember that they will not persist between visits to your page. If this is what you want, go ahead.
Another option is to use HTML5's Local Storage, which is persistant and designed for storing data.
Your last option, which is important if you don't want to store the data locally but do want to persist it, is to use HTTP AJAX GET and POST with a servlet or something on the client side that gets and sets the data, respectively.
If you want to go the old way, you could also use cookies instead of Web Storage. I definitely suggest the later though.
In this case, you can trigger a change in your hash when user applies a filter. For example:
http://www.mydomain.com/index.html#name=abc&department=def . Your app listens for changes in the hash to update accordingly. Libraries like: crossroads.js, sammy.js allow you to to that. This approach on client side borrows the routing concept on server side.
Using this approach, you can send the url to your friends to "jump" directly to a specific state of your application and you can also reuse it, store it anywhere.
You might consider using this kind of leverage if you use HTML 5 :
http://www.jstorage.info/
I'm searching for a simple architecture for my UI that will have some basic javascript functions in like: select all checkbox's, image crop, some pop-ups and some other plugins.
I found this article: Organizing Your Backbone.js Application With Modules
My application is not a SPA (Single Page Application). I want to know if Backbone.js with jQuery will help me even if my application is not a SPA.
The strength of Backbone is really in its ability to manage many models (even complex ones) and keep the rendered page in sync with their current values. It provides an interface to getter/setter functions so that the changing of a model value (there are many different flavors of "change") will call render on the corresponding view and the page will correctly reflect the underlying models. Furthermore, it provides interfaces to saving, paging, and routing actions on models.
I have used Backbone extensively for both SPA's (where it shines) as well as more traditional, multiple page applications. It has no special support for UI and DOM manipulation, but combined with jQuery/Prototype/Zepto it manages their rendering/manipulation.
Basically, backbone works best to untangle elaborate chains of rendering logic and model updating. If you feel that your application has a lot of view elements that need to stay in sync with models that the client will be updating on the page, Backbone is a wonderful solution. If you just need to select and manipulate DOM elements, it's overkill. jQuery alone can handle that.
Backbone is really not about the things you mentioned, but I wouldn't say it is strictly for single-age apps (SPA) either. I'd say it is for any case where you've got quite complicated pages and it would benefit you to break them up into multiple pieces (for example, several views that all pull data from one model).
However, I would say the strength of Backbone.js is in the SPA realm.
You could probably find some jQuery pieces that answer some of your needs if you're not already using jQuery as part of your app. However, jQuery is all about the parts you mentioned (easy DOM manipulation, popups if you use jQuery UI, etc.) and not about structure or organization.
I believe that the principal idea of backbone, is organize you JS code in complex app using the MVC concept.
This way your app becomes easier to mantain and add new features, It get easy to use frameworks tests like jasmine.
Backbone also make possible (and very good) work based on SPA approach, using ajax request to server. It is completely based on Restful concept, to get a code using backbone, is important to understand what is Restful.
Basically Backbone have a Router (that can work like a controller. but is not a controller).
Model that is where you can manage all the data logic of your application.
Collection that is like a list of models.
View that is where you will react accordingly the model changes.
There are other things, but basically, is this.
But as I said before, you can use it without have a SPA.
The most important thing to have in mind is that the concept of MVC must be followed when using backbone. If you don't do that, it doesn't make sense use backbone.