I have been trying to find some good sources on how to handle application-wide elements when using MVVM for web development. I am using knockoutjs.
By application-wide I mean elements like a site's navigation. Perhaps each page has a login box, search box, a footer etc.
Should these go into a separate view model? Or should you derive each page's view model from a base view model containing these? Or should these properties be left out of a view model alltogether?
Thanks in advance.
Consider treating all your supporting components (menu, footer, etc) just the way you treat your business components. Also I recommend having separate viewmodels per UI component regardless of type of the UI component. This makes your components highly loosely coupled.
For example, the menu may have own view model (without being a part of any global viewmodel). Now you may use a PubSub library to implement publisher/subscribe notifications to have loosely coupled communication between different UI components (viewmodels), where your business components may show/hide themselves as per the event request.
But specifically for implementing a menu component, I recommend using a router library that can respond to the URL changes (hashtag part of URL). Then you can simply change URL when users navigate on the mainmenu (simple anchor tag), and your component will be activated/deactivated by the router library. This will let you to bookmark and use browser history buttons.
Have a look at http://boilerplatejs.org which is a reference architecture for large scale JavaScript development. It has all above implemented on it's sample application. It uses UrlController to activate/deactivate components based on URL changes, where as DomController is used to place components statically on the DOM itself (e.g. for menu, footer, headers ). It uses knockoutjs for most of the sample UI components.
Disclaimer: I'm the founder of BoilerplateJS
Related
I have written a set of React components and would like to apply them to a website using a browser extension.
The components are highly interactive, complex and nested hence choosing React to develop.
I plan to use a browser extension to inject them into websites, just as a search browser extension would inject markers to highlight words on a page.
How would I go about this?
Usually, React renders to a single container. If I want to inject multiple React components into an existing site, would I need multiple containers and renderers? Is there a better way?
It is simple to instance SAPUI5/OpenUI5 component as JavaScript variable and to assign its content to the div in html page. But is there some way how to declare SAPUI5/OpenUI5 component in the html file - actually - the best place where the instance of the component should belong? I have read about Angular.js and OpenUI5 integration but this effort was not continued. It is time consuming to write so much JavaScript code where the other frameworks use HTML tags.
First of all, you can write Views in XML, HTML, JSON and JavaScript. The corresponding Controller is always JavaScript.
Unlike angular.js, SAPUI5/OpenUI5 doesn't enhance the existing HTML but takes the Control definitions from the view and creates the DOM based on it (in the Control Renderers). Therefore the "language" of the view only changes the parsing function.
Based on the OpenUI5 Best Practices, the Explored App demoing the Controls, the Developer Guide (and my personal experience) SAP recommends using XML to create Views.
JavaScript Views might seem more powerful at first because you can include more logic in them. But that is also their biggest problem: By including logic in the View, you weaken the separation between View and Controller.
From my experience, declaring your Views in XML also makes them shorter (and more readable) compared to any other option.
Actually the best place is the JS code...google single page web applications. But if you really want to use html or xml you can create different types of SAPUI5 views the options are: Javascript XML HTML and JSON.
SAP recommends using the Javascript views/controllers they are more powerful.
The best way is to wrap the Angular js code as a OpenUI5 Component. You can use this Component any where in the openui5 application depending on the requirement.
This way the dependencies can be managed effectively and the code is modular. You can still have views and controllers within that.
........
Currently I am working on my app and I decided to use AngularJS as a framework to structure my front-end code. However, I don't have any experience with AngularJS and thus, am currently struggling with the concepts and logics of it.
Below you can see a rough draft of my app's scaffold:
So what I am trying to do is to create a single page application for my whole app.
Within the <menu bar> one can select different pages to display within the workspace. I learned that I can realise this behaviour by using the <ng-view> directive.
However, what I want to do is, depending on the buttons clicked within the <workspace> (-> the currently loaded view) I'd like to show different <sidebars>.
For example: If one clicks on an edit object button within the workspace, the form to edit the object will be loaded into the sidebar.
At first I though I could solve this by using multiple ng-view directives within the app, but I learned that this is not possible.
So, do you have any ideas on how to realise the above described behaviour?
I would like to asynchronously load <sidebar> templates whenever they are needed within the app. These sidebar templates should contain some logic, e.g. buttons to submit data etc.
I really don't know how to realise this behaviour, as I'm as well struggling with how to use scopes and controllers in this context.
Any ideas, articles, examples are highly suggested! Thanks.
Edit: I created a small and only minimalised draft of how I imagine AngularJS would handle the process:
You can use Angular-UI.
The UI-Router has much more powerful routing features than the default AngularJS router.
For the views, with Angular-UI, you can have multiple views in a same document (ui-view) and each can load a different template depending on the current application state (the URL).
Here is the documentation for these components:
http://angular-ui.github.io/ui-router/site/#/api/ui.router.state.directive:ui-view
https://github.com/angular-ui/ui-router/wiki
You definitely should check it out!
Please note that once you'll get your two templates, they will be in different scopes so you'll need some sort of communication service to handle passing data from one scope to another without getting into a $watch or $rootscope hell.
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.
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.