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 am loading an extjs4(.2.1) application within a div in JSP page. In my JSP i display various links based on what the user is allowed to do. On click of each link the page refreshes and I set some javascript variables (based on server-side logic) which are used by the extjs app as input.
In order to get rid of the page refreshes and therefore improve performance I have refactored this page using AngularJS(I just learnt Angular so I thought I would try using it). I have used routing. So now I get all the inputs for each of the menu clicks at once on page load. When the user clicks on a link the Angular route sets up the appropriate inputs for the extjs application without refreshing the page or going to the server. The extjs application now is present in an IFrame instead of a div as before so the Angular route basically refreshes the IFrame each time a link is clicked to reload the extjs app.
The results seem good. Pages load faster.
My questions :
Is this good design?
I know AngularJs's real power is in data binding and directives which I do not leverage. Is it an overkill to use AngularJs for this usecase?
Is there a better suited library for this specific purpose?
Thanks for your time.
While it may work, other people maintaining the app need to understand the two frameworks and visitors to your site will have to download all that extra code.
It looks like EXTJS 4 has extensions for UI routing ext-ux-router and ExtJS 5 has it built in.
By using a router built into EXT JS you may be able to avoid the iframe reloading hack.
I have done some work on sencha like for one controller actions and views but now i want to start work on multiple controller ,actions and views, how can i give links for call particular controller view in sencha just like master page in asp .net mvc application.....
Thanks in Advance
Regards,
Sandy
Each of your controllers can have listeners defined to interact with particular views within your application, so this will be pretty much the same as what you've done with the single controller, just expanded across logical sections of your site.
Regarding how you "glue" these together via interactions within your applications (e.g., a user clicking a link to navigate to a new section of the site), there are any number of ways to go. I would highly recommend implementing something like Ext.ux.Router to help with this. Whether by using this or rolling something similar of your own, you can create logical and robust routing within your application that can be the impetus for your controllers and views to change and be aware of state.
It is said that Backbone handles all the higher level abstractions, while jQuery or similar libraries work with the DOM, normalize events and so on..
Could someone please help me understand this statement with any simple practical example.
Also one important feature of MVC framework like Backbone, Knockout is that it keeps the model (data) and the view in sync. But this seems to be specific at a page-level and not across the entire application. So can we have the model/data and the view synced across multiple pages..(kind of global)
Your opening sentence was actually a very good statement of the differences between Backbone.js and jQuery, so let's unpack it a bit.
For one thing, the two libraries are not at all in competition--they are complimentary.
As an example, here are some things I would do with jQuery:
Animated slideshows
Form control enhancements, like an iOS-style number "spinner"
Toggling visibility of elements based on a class name
And some things that I might do in Backbone.js:
Create a photo album, where the user clicks on a thumbnail and can view a larger version of the photo, along with some data like the camera that was used, the location and the photographer's name
Build a master/details type of page that presents a grid of data and allows the user to click on individual elements and update them in a form.
jQuery excels at the micro level--selecting page elements, smoothing out the differences in how browsers handle events.
Backbone.js is more big-picture. It helps you manage data and application logic. In the photo album example above, Backbone provides several useful structures: you'd have something to contain all of the data related to photos (a model), a list of all the photos in the album (a collection), and somewhere to put logic that determines what happens when a user clicks on a thumbnail (the view). Those are the main pieces in a Backbone control or application.
Backbone.js benefits from jQuery, though, or something like it, to help render the results of your application's data and logic into the DOM. It's common, for example, to use jQuery to select the element on the page that will serve as the container for your Backbone app. It's also common to use jQuery's $(function () {}); to fire up the pieces of your Backbone control. You'd probably display form field validation error messages with jQuery as well.
You can certainly build big, complex user interfaces in jQuery. We have a few in the app I maintain at work. But they are difficult to work with because jQuery isn't designed to provide structure to an application. In particular, jQuery's API, which is based around selecting groups of items and then passing callback functions that manipulate those items, isn't a good pattern to use in a large, complex control or app. You end up with a lot of nested functions and it's very hard to see what's going on.
I'm currently reworking one of those controls in Backbone.js. As a final example, here's a quick summary of how my thought process differs when working on the same control in both different libraries.
In jQuery, I'm worried about:
Am I using the right selector to grab the group of li elements I want?
Do I need to repopulate that list of values when this Ajax call completes?
How can I put these array values back into the input elements on the page?
In Backbone, I'm more focused on:
What is the correct logic to validate this set of properties on my model item?
When the user clicks the Add button, should I add a new item to the collection immediately, or should I wait until they've filled in all the data and it's "valid"?
How should an item in my collection respond when the item immediately before or after it is deleted?
jQuery handles the nitty-gritty details, and Backbone is more high-level.
In closing, notice I've been using the words "control" and "app" when discussing Backbone.js examples. It's not true that Backbone.js is just for single page apps. It is true, though, that Backbone.js is good for building complex applications that manipulate data and handle a lot of logic. It would be silly to use it for small-scale UI elements--the extra structure it imposes isn't needed.
Update: On the issue of multiple pages, yes, Backbone does provide a powerful mechanism for persisting your data. Each model has a save method that will execute an AJAX call to store the changes on the server. So as long as you save your data as you go, you can have a multi-page app. It's a very flexible model, and it's how we'll probably end up using Backbone at work. While I would love to build a single-page app, we have 10 years of work in our existing multi-page application. We're looking to rebuild some of our more intense UI components in Backbone, then sync the changes to the server before the user moves to a different page.
Backbone / Knockout is typically used for single page applications. So while jQuery is a toolbox that can be used with any webpage, Backbone is meant for a specific type of application and helps you organize your code for it. At least in my experience one of the biggest challenges in building a single page app is keeping the code clean and modular, and backbone helps a great deal with this.
The characteristics of a typical backbone app are:
Essentially static html page, with nothing generated on the server
Server acts as a json REST api, which provides the content for the app
The dom elements to display the data are created with javascript in backbone views, using jQuery and various templating libraries to help
Communication with the server as well as between different parts of the app is done through the backbone models
Regarding your question about keeping the data synced across multiple pages, my instinctive answer is that you don't need multiple pages: the user may perceive that the page is changing, the address in the url bar changes thanks to pushState functionality, but technically the entire app is one page.
The biggest advantages of this kind of approach are a smooth user experience (no reloading pages), good caching support as everything except the json data is static content, for mobile targets the possibility to turn the web app into a mobile app with phoneGap (because everything except json is static).
I have never heard of people using backbone.js across multiple pages. It's almost always some kind of single page app.
The single page may have many different models, views, and states and can result in a full blown, powerful app.
If you already have server-side template/view rendering in java then backbone.js is NOT for you. To get the most out of backbone.js you must move or duplicate some of that code in the front end javascript.
If you don't want to do a single page app (this just means an app without page refreshes or changes, but the url can still change and can look like multi-pages to the user) then you can keep all of your MVC on the server and you have no need for backbone.
Edit:
What backbone does is move some of the MVC stuff normally handled on the server and move them to the client. For many people this means forgetting about the server and just writing your app as a single page javascript app. The server becomes just a source of JSON/REST data. If you're not prepared to do that, then backbone.js is not that useful.
Backbone is a MV* framework while jQuery is a DOM toolkit.
The main features of an MV* application are routing, data binding, templates/views, models, and data access.
Backbone could dependant on jQuery partially.
jQuery is a solid API for querying the DOM with extensive browser support and a vibrant community. It comes with event handling, deferred objects, and animations.
Simple event binding using jQuery
// When any <p> tag is clicked, we expect to see '<p> was clicked' in the console.
$( "p" ).on( "click", function() {
console.log( "<p> was clicked" );
});
I have heard a lot about backbone.js and quite frankly I don't understand its concept. Does it require that all the elements should be in single page to work out with its animations and effects ? Or it can grab items from server and load it with transition or i mean different pages but make look like a single page. I didn't understand its concept well, so that's why i am asking. What i am looking for is to combine backbone or any other javascript framework to work with a rails project, that could give some ease transition across pages and can give native application look.
Backbone is also here to give you structure by being MVC, and it allows to communicate in a really simple way with the server. You'll be able to update / fetch / save your data (your rails models for example) on the server. So you'll need it if you want your user to work on an Ajax page without having to reload the page.
For example, you'll fetch all your data from the server when the page loads and then you'll have access to all attributes of your models and will be able to modify it and save it to the server.
Moreover, if you want your models to appear with transition, as Backbone is MVC, you'll be able to make that easily. As you have to choose when and where your views will appear on the DOM, you'll be able to put transition at that time.
By the way, Backbone works really great with Rails!
Backbone.js is all about data to be used in some way from your users, think about it as ActiveRecord plus Sinatra (or rails) on a browser, infact, the framework will give you a way to handle your data inside a browser instead of the server.
If you are looking for a simple way to add transitions to your existing app/website you could use a jquery plugin like Pagify (it rely on $.getHtml()) modifying it to get a fragment of the subpages like my (buggy) fork.