I have a fairly complex app, with lots of different components that update frequently. For example, a clock.
Is it possible to call $apply / $digest on only a subsection of the page at once? I don't want to call every watcher on the page for every single clock tick, for example.
I know I can achieve this by bypassing $scope.$apply entirely, and just updating the clock elements manually in a directive. Is there any hope for me?
EDIT: Actually, it looks like MAYBE what I want is to dun $digest, starting on the scope I want to check, rather than $apply, since $apply kicks off the digest on $rootScope. Is this a valid way to do it?
http://plnkr.co/edit/C8aOswf46qx2GoD5uL9Y?p=preview
If your components are really decoupled, you could isolate those that generate frequent updates in their own angular app instance. They will have independent digest cycles.
Your apps can still communicate but there is a bit more overhead involved.
In order to have 2 apps, you have to manually start the applications (use bootstrap instead of ng-app).
See this example: http://plnkr.co/edit/K3bnACFi79g5Kh0kFS66?p=preview
Whenever you call $scope.$apply() it also calls $apply() on all scopes that fall within that scope. If you want to call $apply() on a limited section of a page then that section needs to have it's own scope, which you can do by adding a controller to that section of the page. Then you can use that controller to update the scopes within that section of the page using $scope.apply() on your section controller.
-- Edit --
See comments below for additional details about the differences between $apply and $digest.
Also see:
http://jimhoskins.com/2012/12/17/angularjs-and-apply.html
https://groups.google.com/forum/#!topic/angular/SSj61VOBBSc
Related
Java8 - In my portal, on the page (Homepage) which gets displayed after Customer logs in, I need to display multiple sections like,
Order details, Available invoices, Catalog pdf etc.
There is no dependency between these sections, just need each section data to display on the front end.
If I try to get these data sequentially on the back end, it takes time to display the Homepage.
I'm looking at speeding up this process, I could think of:
Instead of trying to get all details after login on the back end, I will first display the Homepage, then make individual ajax calls for each section using jQuery.
Use forkjoinpool (RecursiveTask) on the back end and fire up recursive tasks for each section
I prefer doing it on the back end (business tier), Is there any other solution available on Java8 to acheive this task? Looking at calling asynchronously every section logic instead of sequential flow.
We are working on a site in AEM 6.1 which has news and events content with most pages having info on recent and related news/events based on tagging that are dynamic. We are using dispatcher. Please suggest on some caching techniques that could be implemented at application level apart from the dispatcher. Thanks.
Aim of implementing the caching on dispatcher is to allow less hits on your app server and serve as much as possible from web server. In short improving response time from your app server. But in some cases we can't cache too much on web server if results change on app server frequently.
On app server we can have following solutions implemented to get results quickly on top of having dispatcher in place.
Make sure your content hierarchy where you are ingesting news items have as less number of article as possible. Divide your hierarchy based on following structure. Year >> Month >> Day >> Hour (this can be ignored if content flow is less) >> news items.
Having this structure in place, write path based query so that you don't have to traverse in whole content hierarchy.
There is a concept of transient node in CQ, for each news item which is getting created in CQ, update the transient node with newly created item. Means for recent news you don't have to traverse content structure just refer to transient node which has reference to newly created news item.
You could also write a cron job which gets executed in background and takes care of collating views namely top recent news.
To complement the answer of Rupesh I would say that definitely use dispatcher cache as much as you can and for using local caching strategies in AEM try using guava cache it is a very good and easy to use tool there is also a lot of information on how you can set it up and use it for your specific needs. Hope it helps.
I would suggest the following:
For recent news/events, write a scheduler
(https://sling.apache.org/documentation/bundles/scheduler-service-commons-scheduler.html) that will compute the list of recent news/events and write it to a specific node as properties, example:
/tmp/recent
news [/path/to/news1,/path/to/news2]
events [/path/to/event1,/path/to/event2]
Most recent always at the end of the array. Your code need to limit it to the amount of max recent you want to have.
Let's say you want to have the last 5 changed and a 6th page is changed, then you just pop and push(new_page_path)
This could run once a day or at the frequency which you feel is the best depending on your requirements.
If you need instant update, then you can additionally write a Listener when a page is changed/deleted and update the recent list. In this case I would suggest putting the code that deal with updating the recent list into a service and use that service in both the scheduler and the listener.
Listener and scheduler need to run on both author and publisher and on publisher trigger dispatcher cache invalidation for /tmp/recent afterwards.
In order to render the recent list without having to invalidate the whole pages, I would suggest you use SSI for that, that means have a component in your page that will render an SSI include to /tmp/recent.news.html or /tmp/recent.events.html depending on whether you want to render recent news or events.
Give the node /tmp/recent the resourceType for handling the "news" and "events" selector and implement that resourceType to render the content.
For the related
Use the Tag Manager (https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/day/cq/tagging/TagManager.html) "find" method to lookup for all news/events having the same tag as the current page. I assume your news and events pages have a dedicated template or resource type.
Also I would suggest having a dedicated component that would include that content using SSI include. Let's say your page has 2 tags, ns/tag1 and ns/tag2, then you could perform the SSI include like this:
SSI include /etc/tags/ns/tag1.related_news.html
SSI include /etc/tags/ns/tag1.related_events.html
SSI include /etc/tags/ns/tag2.related_news.html
SSI include /etc/tags/ns/tag2.related_events.html
depending on what you want to include
Write a component under /apps/cq/tagging/components/tag (sling:resourceSuperType= /libs/cq/tagging/components/tag) that will provide the rendering for the "related_news" and "related_events" selector and list all related pages.
The advantage with this approach is that you can share the related page for each tag and whenever the tag is changed/deleted then the cache gets invalidated automatically.
In both cases (recent and related) configure the dispatcher to cache the output.
I'm using Segment and have Mixpanel enabled. I used to track our user's life time revenue like this:
mixpanel.people.increment('Lifetime Revenue', 21.99);
The question is how do I do this in Segment?
Looked everywhere, it seems like they do have increment setting under advanced setting. However, I still don't know how to fire those events/trackers.
Thanks!
I too was wondering on how to do this, based on Mixpanel's article (https://mixpanel.com/blog/2014/07/21/revenue-best-practices). I did a lot of back and forth with Segment's tech support, and after a couple of days of repeatedly telling them to read the article, they finally got me to an engineer who actually read it, and was able to answer my question about this as well. Here's his answer:
It looks like a few things need to happen for this lifetime revenue value to be tracked.
First, track_charge needs to be called. Fortunately we're already firing a track_charge call when revenue is passed as a trait in track calls. You can see where that happens in the code here.
Secondly, a the people.increment() needs to be called. We also fire this on the page as you can see here, but it doesn't look like we currently have a way to pass through the revenue in that people.increment call.
Looks like your best bet here would be to fire off the increment and set calls directly. As you may know, we're loading the Mixpanel library on the page so all you have to do is execute the calls within an analytics.ready() method. Doing so ensures that the native calls only fire when the Mixpanel library has properly loaded on the page.
For reference, here are the calls you'd want to place within the ready() method.
mixpanel.people.increment("Lifetime Value", 27);
mixpanel.people.set("Last Item Purchase", new Date.toISOString());
To increment events, log into your account at Segment.com, select the Mixpanel integration, then select "Advanced Options". Within "Advanced Options", there's a text field labeled "Events to Increment in People" where you can specify events you'd like to be incremented.
In AngularJs I can do this:
<header data-ng-include="views/header.html"></header>
which AFAIK asynchronously downloads views/header.html from client and interprets it as a template.
I want to ask if there is any sane motivation to use it because all I encountered with this was a pretty bad usex experience. I have a black Twitter Bootstrap header and this causes the header to show a moment later and therefore "hits" the user right in the eyes once all other content is visible.
On the top of that it does the request every time eventhough it just for a 304.
You can use an ng-include to separate some HTML that is re-used, you can also bind the data-ng-include to a variable on your scope and change the view similar to what you get with ng-view and using the $routeProvider configuration.
I'm not entirely sure about the attempted reload and seeing the not modified response. I would assume ng-include would operate under the same caching rules as a normal page but perhaps something is different since it does an AJAX request for it I assume.
I think you should be able to make it sync loading by adding a public counter to the on-load property of ng-include. And you can then wait the counter to increment to be the number of the templates loaded by ng-include, and then after all templates are loaded continue with other logic.
There are definitely some advantages of using ng-include. For example, you can use it together with ng-switch to conditionally load a template. And it also automatically creates a child scope if you want to isolate model from the current scope.
Hope it can shed some light on.
When a screen has multiple interacting Ajax controls and you want to control the visibility of components to react to these controls (so that you only display what makes sense in any given situation), calling target.addComponent() manually on everything you want to update is getting cumbersome and isn't very maintainable.
Eventually the web of onClick and onUpdate callbacks can reach a point where adding a new component to the screen is getting much harder than it's supposed to be.
What are the commonly used strategies (or even libraries if such a thing exists) to avoid this build-up of complexity?
Update: Thank you for your answers, I found all of them very useful, but I can only accept one. Sorry.
In Wicket 1.5 there is an event bus. Each component has onEvent(Object payload) method. With component.send() you can broadcast events and each component can check the payload (e.g. UserJoinedEvent object) and decide whether it wants to participate in the current Ajax response. See http://www.wicket-library.com/wicket-examples/events/ for a simple demo.
You could add structural components such as WebMarkupContainers, when you add this to the AjaxTarget everything contained in it will also get updated. This allows you to update groups of components in a single line.
When I'm creating components for a page I tend to add them to component arrays:
Component[] pageComponents = {
new TextField<String>("Field1"),
new TextField<String>("Field2"),
new TextField<String>("Field3")
}
As of Wicket 1.5 the add functions take array parameters [1]. Therefore elements can be added to the page or target like this:
add(pageComponents);
target.add(pageComponents);
Components can then be grouped based on which you want to refresh together.
[1] http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket/1.5-M3/wicket-1.5-M3-javadoc.jar!/org/apache/wicket/ajax/AjaxRequestTarget.html
Well, of how many components do we speak here? Ten? Twenty? Hundreds?
For up to twenty or about this you can have a state controller which controls which components should be shown. This controller sets the visible field of a components model and you do always add all components to your requests which are handled by the controller. The components ajax events you simply redirect to the controller handle method.
For really large numbers of components which have a too heavy payload for a good performance you could use javascript libraries like jQuery to do the show and hide things by the client.
I currently use some sort of modified Observer-Pattern to simulate an event-bus in Wicket 1.4.
My Pages act as an observable observer since my components don't know each other and are reused in different combinations across multiple pages. Whenever one component receives an Ajax-event that could affect other components as well, it calls a method on it's page with an event-object and the ajax-target. The page calls a similar method on all components which have registered themselves for this kind of event and each component can decide, on the base of the supplied event-object if and how it has to react and can attach itself to the target.
The same can be archived by using the wicket visitor. I don't know which one is better, but I think that's mainly a matter of taste.