For our single page app, instead of having a set of defined views and viewmodels that live on the server as .html and .js files, we need to build a system where the views and viewmodels are created in “real-time.”
This will be an intranet app and we want end-users to be able to define what they see and use in the app as they are using the app. For example, end-user A creates view1, view2, and view3, while end-user B chooses to create view4 and view5, and so forth. These views are then created in the browser session and saved somehow for the user for the next time they use the app.
They can name these views whatever they want (e.g., dashboard 1, plant view 2, etc.), and then they can select one or more “widgets” to be on each view. A “widget” would be a contain set of JavaScript/HTML/CSS code, similar to user controls in the web forms world, and would perform its specific function and be able to be draggable and resizable. Of course, all the widgets that the user has added to each view will be saved for subsequent uses.
So, each time end-user A opens the app, they’ll see their 3 views as tabs across the top (named whatever they named them when the views were configured) and they’ll be able to navigate to the view and see and interact with the widgets they chose on each view.
Our app will sort of be like Trello in which the views can be added, updated, deleted, etc. by the end-user and “widgets” can be added to the views dynamically, moved around, deleted, updated, etc., all in a dynamically created way.
In studying SPAs, the views and viewmodels are developed as actual physical files that live on the production web server and provide the functionality intended to all users. But, our SPA needs to be more dynamic in terms of what views/pages are available.
Can Durandal be used is this sort of scenario? If so, any guidance on how to do build such a thing?
Or, is this not possible with Durandal? If so, what’s a better path for us?
As a last resort, would we need to create some sort of html and JavaScript generator that will output files after the user has selected the configured options?
Or?????
Thanks for your help!
durandal is a framework for aiding in creating single page applications (SPAs). SPAs are essentially just a website that feels like a desktop application.
Your only limitations on what you can create are the limitations of the browser.
Anything you can build that runs in a browser.. can be used in durandal.
You can have multiple spas inside of 1 spa.
You can dynamically download css/html/js if you need too.
There are lots of options on how you can structure you application.
There's nothing stopping you doing this I think.
You can have flexible routing as you define the routes on Durandal start-up so you could use the saved view data to help construct this. But I have a feeling you basically want a shell that other mini applications sit in? Are your views/widgets completely separate to the main application? If so, you might not really need custom routing.
I was working on something similar. I was using iframes to host the applications and the user was able to move them around. I didn't get as far as persisting what the user had laid out though.
Related
My application was in IBM WebSphere portal, where we have a centralized theme for all the portlets. We build individual portlets with the specific features which are then installed from a page into the portal like as shown below.
So altogether we build a portal with lots of portlets (individual web application). In the portal we creates pages and drag and drop each of these portlets as per the requirements.
Now the requirement was that we are moving everything to Micro service Architecture with Angular4 as the front-end. Currently I am having an angular4 application having many UI components and features. I am posting this question to get some ideas or possibility whether it is possible to create a portal like IBM WebSphere/ Liferay in Angular 4 with having the following basic features:
User/Team can create separate individual angular4 application, build and will be able to install/uninstall within the main application like porltets in portal (IBM WebSphere).
User will be able to view all the installed Angular4 application and can create pages, drag and drop those application within a newly created page.
Each separate Angular4 application (like portlets) installed will be using the main application theme.
Can anyone tell me whether this is doable. Do we have any framework setup in Angular4
One of the possible ways I can think of is using webpack(or any other module bundler) to handle the various angular application.
You can check out my answer here to get a brief overview of how you can configure webpack.
In the end, Angular compile to javascript only. So, It will be possible. But the effort needed to maintain and test the overall application might be huge.
When re-designing a system, it is best to think about the problem you are trying to solve and solve for that use case. It feels like you're trying to recreate the same bad interface with Angular. The code may be new, but the user interface problems will still be there.
I would recommend ditching the portlet idea and creating 1 app with many modules. Angular was designed to be very modular so different teams can work on separate modules. You could then have some sort of settings page where you can turn the modules on and off.
What is the right way of Architecture ExtJS 5 for Single page web applications.
Is ExtJS good for "single page web applications(SPA)"? where we don't have multiple markup pages to refer different JS files to different urls. or rather, how best we can use ExtJS in SPA?
In detail: In www.domain/home.html I can refer tab.js that will load a tab layout, then user clicks on "about us" link, that will load a www.domain/about.html, here I refer aboutTree.js that will load tree widget on left panel. This looks easy. I can create a new JS file that will have a full store, model, OnReady() as shown in sencha document examples.
How is Sencha ExtJS mainly used by most of its customers? as just widgets at some sections of their applications, or the whole application is drove by Sencha ExtJS?
Can a full web application be driven by only ExtJS? I attempted one example for Sencha Touch for a mobile site, that can navigate to new pages with a single Url (Example: Sencha Fiddle or Practice Site). But is this possible for Web applications? Is there any sample that I can refer to how to navigate between pages using only Sencha ExtJS.
Friendly URLs: If I follow this structured I attempted for mobile site "Practice Site" (only about and home links are handled) all pages in my site will always have /mobile.html url, how would I make it such a way it can have friendly urls, like /about, /contact and so on?
There is similar question on SO here ExtJS Architecture for Multi Page Application, but focusing on different concerns.
ExtJS is amazing for single page applications. It would be one of the better uses for it. I will answer in order.
In creation of a SPA, you should look into pulling the data in to your tabs through ajax calls if that is not a option and you only have static information you can have that html preset in panels. If you are forsaking the MVC paradigm like the way you are talking about in this first part, it is best to have each component built within a single onReady. If using the proper MVC/MVVM paradigms you will want to set up most of the application still under each component like set stores seperatly, models seperatly and call them all into the main application.js and use your controllers to manage the logic of your application. With both scenarios you should still only be calling a single index file and allowing ExtJS to manage your application instead of having multiple html pages.
ExtJS is used almost completely for creating full applications completly driven on the front end by ExtJS. The platform has so many features there is no reason to use anything outside of it if you are choosing to use it.
Yes ExtJS can fully drive your application. It is recommended though to have some backed set up to pull in data dynamically though otherwise you will just have a static page. Here is an example of the routing functionality in ExtJS Extjs 5 Guide Router
Just like in the last section the router will create friendly urls for your application. just take a look at the router.
From looking at what you are reffering to it might be best to break away from having those multiple html pages and allow ExtJS to do what it is meant to do maintain and control your whole application.
I'm completely new to Angular. I currently have a Django app that acts as a JSON-serving API (using Tastypie) and also serves up a few static pages for things like user registration, invitations, and viewing events.
Eventually, we're going to have a webapp that interacts with the Django API in all kinds of ways and makes total sense as a single page web app written in Angular (or something similar). However, as it stands right now, I just want to separate out these relatively self contained pages (mostly forms, confirmation pages, and event viewing pages) into their own app.
Since eventually everything is going to be in Angular, my thought is that I might as well start making these things in Angular, even though Angular's architecture doesn't seem very tailored to small forms and other things that will likely just be linked to from email messages.
Does it make sense to build these things out using Angular, setting up the necessary service/factory calls, making controllers for the form/event viewing pages, etc.? And if so, what's the best architectural decision in terms of modularity? Should every part of the app that "stands alone" (i.e., doesn't really interact with other parts of the app) be a separate Angular module?
If they are literally separately loaded pages and you eventually plan to have these pages be part of a single page angular application, Than what I would do is:
Create angular modules that have the same variable name for all seperate pages so like var app = angular.module('blah',[])
I'd link all my controllers for each individual pages at the time to their specific "app" module app.controller('blahCtrl',function(){}); ...
You boot these modules separately on their respective pages for the
time being
then when you do make the transition to moving it to one module where everything is in one page you can simply port the controllers because they will all belong to a module represented through the variable "app"
So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.
Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.
I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!
I'm pretty new to Sencha Touch and am trying to make a simple application that has a login form and makes calls and fetch results into lists.
My question is, how should I create the structure of the application? Should it all be inside one .html file? or should I different pages for each list and the login page? If so, how can I change views from one page to another and get transition effects?
There is actually a generator which you can use to generate the canonical app structure. From the Sencha download, go to the jsbuilder directory, then run a command similar to this:
./sencha.sh generate app MyApp path/to/myapp
Also, this slide set demonstrates the structure, though you may have to dig for more of the philosophy for why things are where:
http://www.sencha.com/conference/sessions/session.php?sid=322
And here's the example app talked about in the discussion:
http://cl.ly/1d1S282O1Y2c3N1v1j1i
It's fine to use a single HTML file to get things started, but in the long run it's worth making the application structure consistent with 'best practices' so that others can look at, and understand, your code subsequently.
Sencha Touch generators (coming in v1.1) place the launch logic in a file called app.js and then have files for each model, view and controller (in respective directories).
While you may not be building a fully fledged MVC application from the start, you should probably still use these conventions. Take a look at the Twitter and Kiva apps in the SDK (and at http://dev.sencha.com/deploy/touch/examples/ ) foor good examples.
The index.html file can link to each file individually, but of course for production, you are also advised to look at the JSBuilder tool to package and minify them all so that the device can fetch them in one single HTTP request.
I would break it up by major function (i.e. purpose). For mobile apps, you want to avoid having unnecessary postbacks / loading multiple pages and views if you can help it.
If your mobile app has one purpose, I would keep it on one html page and only break up the JavaScript files as you need to keep it organized.
If it has two purposes (e.g. 1-to ENTER a bunch of information, and 2-to display reports on your data), then I would break it up into two html files.
For example, if you have a mobile app that takes you through a series of wizard steps to perform data entry (i.e. single purpose), I would house that whole wizard inside of an Ext.Panel (on a single page), and swap out each content Ext.Panel "step" of the wizard as the user progresses through the wizard.
Start with the simplest thing and refactor later. I've just done an app in Sencha Touch and it gets quite bewildering looking at the example files. I found the easiest way to learn was to create a single html file and as soon as something became unwieldy or obviously needed a refactor I started creating subsequent files.