I have a livewire component called Cart.
If the user open this component in multiple devices at the same time (i.e. mobile and desktop, or open it in multiple browser tabs), and add an item to the cart in the mobile browser, is there a way to refresh the component in desktop browser?
I know these components are independent of each other, so I'm thinking of a solution where I have to store, for example, the component ID (or something like that) and create the another one based on it.
Is there a well-developed solution to this?
I'm not aware of any existing solution like this but you could save the cart in DB and then retrieve it for all your platforms. To make it so it's always synced on both platforms you could build your mobile application on APIs or otherwise use something like the Broadcasting within Laravel or a package like Laravel WebSockets.
Livewire is more for building dynamic interfaces removing the complexity of making AJAX requests in the background and doesn't support multiple platforms the way you are wanting.
Related
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.
im trying to create a Single Page Website with DurandalJS in the frontend and Laravel as the Backend. Do you think this is a good Idea?
If yes how would I do the following:
What would your recommendation for the basic interaction between both frameworks be?
Would you rather have all the computation done in JS instead of Laravel sending calculated and styled returns?
How Do I setup Laravels controller in order to only get dynamic Data for, say a Div, instead of a whole page?
How can I adjust the browser URLs?
I hope I was specific enough, thank You in advance.
Laravel does not actually care about what framework you use to build the Frontend. Laravel is just a framework that helps you build your application with. It gives you great advantage with respect to the time spent and effort.
You can use any frontend framework that you want to build your app with. I have actually not used Durandal, but from the first look of it here is my opinion.
Durandal is built on top of jQuery, knockoutJS and requireJS. It also has a MV* architecture in place with support for eventing as well. So you could basically define routes on Laravel and initiate the communication between both the frameworks through events and ajax. Again this completely depends on the functionality that you are building.
In the overall flow of your app, consider Laravel as a Model that just gives data from a source to your app and Durandal as your views and controllers. This way, it will keep your data flow cleaner and easier to build. Computation of your functionality depends on how important and secretive the app is. If there are functionalities/implementations that you need to be secretive about, you can keep it on Laravel and just send computed data to Durandal. If its a web app that you are building, then keeping all implementation on the JS is just a right click away from knowing what and how you have built it. One can just see how the implementation is done just looking at the Javascript source of the web app. If you are building Mobile Device App, then the case is different.
Take a look at Restful Controllers. Will give you an idea on how to setup controllers to return only data. But if you need to return the div itself, then you can make use of the Basic Controllers of Laravel to perform them.
You can setup cleaner routes for the browser URL's. Take a look at Laravel Routing
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 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).
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.