We are trying to create a portal type application with multiple / independent "sub-apps". Assuming that all sub-apps are written in Angular what is a good pattern to achieve the following goals.
Each app can be developed and deployed independent of each other.
They share a common authentication service, they can share common libraries (directives, filters etc).
Only one app will be visible and active at any given time. The scope of each sub-app is isolated from each other.
When the users goes between the sub-apps, the state is maintained as long as the user does not refresh the page or visit another static link. (I think this is built into Angular and no special effort maybe needed)
Each sub-app will have more than one views (it will have its own menu). There will be a top menu based on what sub-apps are available. Ideally the top menu is dynamically build based on what sub-apps are deployed. Maybe there is a server side component to this (the server detects the folder structure etc and determines what apps are deployed and injects the necessary js code into the page).
Given the fact that AngularJs does not have multi-level view structure, I was thinking of using multiple ng-app declarations on different divs and then using $window scope to store the key of the active app and hide the ones which are not active.
There is no easy answer to your (rather open) question, but regarding the $route and ngView limitations, I have been having great success employing a technique derived from this: http://www.bennadel.com/blog/2420-Mapping-AngularJS-Routes-Onto-URL-Parameters-And-Client-Side-Events.htm
This is something that I also have been thinking of trying to implement. While I don't have a complete working solution, I believe that this type of portal app would consist of multiple angular apps on the same page.
The portal app would be the traditional ng-app directive on the main page and the "portlets" would be dynamically created and manually bootstrapped angular apps on a sub view div. You can share data, state, authentication, personalization, etc from injecting the portal services (contained in their own module) that provide these features into the manually bootstrapped portlet apps.
The tricky part is how the portal app would discover the portlet apps and serve up their angular modules knowing that these apps would be independently deployed web apps with their own urls.
I still have some questions around if the service data would be common between the apps or if you would need to try and leverage HTML5 local storage via the portal service (like a data manager).
Related
I am developing a website which unlike others, everything will run on end user's computer. Application will start a server then user will go to localhost to see the GUI. One part of my GUI is called a view. It represents a component which will be provided by the server as a json object.
Which component and view should be rendered will be determined by url parameters like:
localhost?component=mycomponent&view=myview
I want end users to be able to create their own views and someway register them to the application. Let's say they created a view called "userview" and registered it to the application. Now they should be able to go to:
localhost?component=mycomponent&view=userview
And see their representation of the same component.
I will most likely use spring boot for back-end (in case that matters). Views are just HTML, CSS and JS.
I have no idea how to structure such application or even if it's possible. If it is, how would one structure such application? How should the registration be handled?
Update: Solution
I dedicated a folder called "views" in which my server serves all resources under it. Users write their views as simple static websites and put files under that folder. I used an iframe element to embed these websites.
I added all the component related information to parent frame's window element like:
window.viewContext = {}
So that user's can access component related information in their views like:
parent.viewContext
I need to add a custom element/mini-app/extension to CRM Dynamics sales such that it shows globally on all pages that the user navigates to and also can navigate the users urls when certain events happen.
What options exactly do I have to satisfy the above criteria?
The screenshot below shows a sample area that I need to build the app within as an example.
Id imagine there are many use cases where customizing a global element is worthwhile, especially since custom applications may need to be built.
I understand I can use the Resources to create a SPA such as angular which is running so long as the URL stays at the SPA url. But for our use case, we are looking to allow end users to be able to navigate the CRM using the custom controls. but when something happens in a another subsystem, we need end users who are logged into the CRM to instantly view data that is important to them.
Is this technically possible?
Unfortunately this is not feasible. There are some concepts to show learning path like that. It won’t satisfy your need.
I understand what you need, like a news feed or ad rotator for rolling content but context specific flyout area which is always pinned. There is no OOB option or customization/configuration available for achieving this. You can initiate this concept in Dynamics Ideas.
Like you said there can be a HTML web resource developed & embedded in a dashboard, this is very limited for your requirement.
Edit:
I think you are looking for Channel Integration Framework which will help you to configure third party CTI apps.
In CRM V9, they have introduced a new API call for 'Panel'. This panel loads to the side of the screen, and can display content regardless of where the user moves throughout the entire application. I've played around with it a bit for my own person reasons at work, but it looks to be exactly what you're looking for.
The call is 'Xrm.Panel.loadPanel(URL/WebResource)'
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/clientapi/reference/xrm-panel
However, the feature is currently in development, and should only be used in production at your own risk.
I'm currently building a web app using Laravel 5.1 and would like to start creating a native application so that my users can use their phones. I have decided that using the Ionic Framework is likely the best approach for the app and just have a few questions on marrying the two together.
I've got routes in Laravel that looks like this example:
app.dev/geckos - This is a GET request.
Which takes the currently authenticated user, uses their ID and fetches all geckos that match their user ID. It does return a blade view however.
I assume that when working with something like Ionic, the GET request would need to return JSON instead on order to loop through properly?
Is there a way that I can alter my controller to serve JSON based on if the route was something like this instead:
app.dev/api/v1/geckos
Both routes would use the GeckoController#index method, ideally I just don't want to repeat the code.
I'm fairly new to Laravel and very new to Ionic. So if I'm over complicating this theory please let me know.
Any information is appreciated on this,
Andy
Another solution which I used is to have 1. application in Laravel, which is a RESTful JSON API. Then you would have 2. Web app (in AngularJS) and 3. Mobile app in Ionic (which is based on AngularJS).
So you will create two separate applications, mobile and web, which both communicate with the same JSON API. The web would be a single-page AngularJS application, so that way you can reuse all the Angular services which communicate with the API, maybe even some controllers between your mobile Ionic and Web application.
You will save some time when creating two separate responses for mobile/web application, since you would create only one: JSON response. AngularJS will take care of rendering in both applications, that way you won't have to create separate templates for web applications in Blade, instead make all the rendering using Angular in both applications. There will be some nuances in rendering of the same content in Web and Mobile app, but it would only require creating separate js directives/css styles/html templates for both applications, using Blade you wouldn't be able to reuse any view related code between applications. Also you will be able to use the same Authentication method for both applications.
To sum up, this solution should be cleaner then your solution because you will be able to reuse backend entirely between the applications, reuse a lot of fronted stuff (like input validation code, services, filters,..), reuse Authentication and introduce looser coupling and have much clearer structure then the ugly response type switch in controllers.
EDIT:
So this can be a rough example of the structure of such project:
1. API - REST in Laravel, returning JSON
-Controllers
-Session // actions CREATE, DELETE
-User // actions CREATE, VIEW, UPDATE, DELETE..
-Gecko
2. JS application - Angular App, for both mobile and web app
-common //controllers, services, filters - most of the frontend logic which reusable between both applications
-controllers.js
-services.js
-filters.js
-mobile //this part can be hosted on some server or part of the mobile application
-app.js //separate configs for mobile app
-controllers.js //controllers only for mobile app
-directives.js
-web
-app.js //separate configs for web app (links to HTML template URLS,...)
-controllers.js //controllers only for web app
-directives.js
-services.js //or even services only for web app
3. WEB APP
-HTML Templates - bunch of static .HTML files
-Home
-Login
-Register
-Gecko
-Gecko Views...
-Some index file with layout template, which includes everything from js/common and js/web, entry point to your web application
4. MOBILE APP
-www
-index.html // must include everything from js/common and js/mobile
-templates
-Gecko
-Gecko Views...
But the structure may vary significantly, depending on what part of mobile application you want to have hosted on web server and which should be available offline, or how you want to host it, how detailed the structure might be..
Doing this would be messy because your single controller action will be returning two totally different responses.
However if you go down this route, you could add an additional header to the request from the mobile app, and then check for this to switch the response.
I am developing a site that can be broken down to a handful of main pages. These pages can be thought as isolated from each other, except they share the session data (ie. session id and logged-in username).
Initially, I was gonna build the site as a SPA using ng-view (ie. make the pages into AngularJS views). But then, I don't see any benefits for my site to be implemented in that way. And it would require extra time and efforts to make it support SEO (Making AJAX Applications Crawlable).
Going with an approach that does not provide any benefits and even creates extra workload doesn't seem to be too smart. So I thought to myself, why don't I make the main pages of my site into individual AngularJS apps. The parts of the site that need to be indexed by search engines are simply the initial screens of some of those apps, so I wouldn't need to do extra work for SEO. (Note: The initial screens are rendered by the Django server with data for search engines to crawl, so they are non-blank.)
For each of the apps, it may or may not have its own set of partials, depending on the requirements on it.
Example:
mydomain.com/item_page/1234 (load "item" app)
mydomain.com/dashboard (load "dashboard" app)
mydomain.com/account (load "account" app and default to "tab_1" view)
mydomain.com/account#tab_1 (load "tab_1" view of "account" app)
mydomain.com/account#tab_2 (load "tab_2" view of "account" app)
mydomain.com/post_item (load "post" app)
This is solely my random thought and I haven't seen any AngularJS examples that are comprised of multiple AngularJS apps. I would like to know:
Is the multiple-AngularJS-apps for one site approach feasible? What are some caveats that I should be aware of? Are there any example site out there in the wild that's taking this approach?
If feasible, how do I share the session data between the apps?
Note this post is about multiple AngularJS apps for one site, not multiple AngularJS apps on the same page.
There is nothing wrong with such approach, as long as you keep the size of downloaded JS script small enough, and ensure good caching. One of examples of such applications can be GitHub (they are not using angular, but approach is the same). When you go Issues page on GitHub, it loads an html page, common Github JS libraries and page specific JS code. Navigation and actions inside page, are handled by that single page specific script. If you go to other section (like Code) a new page with new page specific JS code will be loaded. Another example is Amazon AWS console, they even use different frameworks for different pages. (both GitHub and Amazon don't use Angular, but this approach works for any JS based framework, even for GWT).
As for sharing some session data between pages, you can embed this info directly in the page itself, using inline scripts or hidden elements. E.g. when your server is generating page, it should also generate some session information into the page. Another approach is to download session data once, and store them in local storage/session storage.
We have two separate web-apps, say 'retailUI' and 'bulkUI'. These two are basically two separate web applications (within the same business domain). Now, the requirement has been given to us to make the two work together in one page with a Tabbed interface (as a PoC).
My problem is that both the applications span over a number of JSP pages for navigation.
Is there a way that I can achieve this using some framework or some other approach?
If you want to keep the two applications as much as possible the way they are now, without rewriting them entirely, you gotta use iframes. That means the content of each tab is actually an iframe.
For such cases I found of great use a ExtJS user developed component, ManagedIFrame which as it's names suggested is a managed iframe. Using it, your iframes can interact with each other(for instance sendind messages from one to another, listeners etc.)
Carefully planing the listeners and their registering by checking whether the peer is there you could build this integrated application without rendering the two separate applications unoperational when ran standalone.
Sounds like your easiest bet is to use Frames. For this, each of your two web apps will be frames of a wrapper web app. You would then hide or show the frames based on which one you want to be active.
This would allow you to have seperate navigation in each, and the two apps don't necessarily have to know anything about one another.