Looking through my business requirements, the web analytics team wants to make s.T() 'page load' calls when a user navigates to different sections on the same long ass page. This is also supposed to happen when they scroll to or through this content. I feel like this should perhaps be completed with a link tracking call, is that correct? Is there a recommended approach for handling this scenario? Are there any well document drawbacks to faking pageload omniture calls?
There's absolutely no issues calling s.t() multiple times, as long as you want each of those calls treated as a page view.
Really the only differences between s.t() and s.tl() are as such:
s.t() calls increment page views while s.tl() calls do not
s.t() calls collect pageName and pageURL while s.tl() calls do not
s.t() calls send all defined variables while s.tl() calls only send variables defined in s.linkTrackVars
Based on your business requirements, if you want additional page views to be incremented as they scroll through it, by all means use s.t(). If you want page views to only increment on actual page loads, consider using s.tl() calls.
Related
I am building some html reports. The user can choose to view additional data for individual elements of the report, or choose to view all additional data.
To view a single line of additional data, an Ajax request is made.
My question is that if a user clicks "View all additional data", should I make 20 or so asynchronous Ajax calls, or just make a single Ajax call that might take a little longer.
Aside from usability, are there any best practices as far as making lots of smaller Ajax requests vs one larger one?
I would say normally you would want to make one call. Your sending a request to the server - while you are there - just get all the data you need before coming back. Depending on the situation you could always cache some of the data (by storing in a variable) - to limit the amount of information you are retrieving.
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.
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
Background
I'm working on a web application utilizing AJAX to fetch content/data and what have you - nothing out of the ordinary.
On the server-side certain events can happen that the client-side JavaScript framework needs to be notified about and vice versa. These events are not always related to the users immediate actions. It is not an option to wait for the next page refresh to include them in the document or to stick them in some hidden fields because the user might never submit a form.
Right now it is design in such a way that events to and from the server are riding a long with the users requests. For instance if the user clicks a 'view details' link this would fire a request to the server to fetch some HTML or JSON with details about the clicked item. Along with this request or rather the response, a server-side (invoked) event will return with the content.
Question/issue 1:
I'm unsure how to control the queue of events going to the server. They can ride along with user invoked events, but what if these does not occur, the events will get lost. I imagine having a timer setup up to send these events to the server in the case the user does not perform some action. What do you think?
Question/issue 2:
With regards to the responds, some being requested as HTML some as JSON it is a bit tricky as I would have to somehow wrap al this data for allow for both formalized (and unrelated) events and perhaps HTML content, depending on the request, to return to the client. Any suggestions? anything I should be away about, for instance returning HTML content wrapped in a JSON bundle?
Update:
Do you know of any framework that uses an approach like this, that I can look at for inspiration (that is a framework that wraps events/requests in a package along with data)?
I am tackling a similar problem to yours at the moment. On your first question, I was thinking of implementing some sort of timer on the client side that makes an asycnhronous call for the content on expiry.
On your second question, I normaly just return JSON representing the data I need, and then present it by manipulating the Document model. I prefer to keep things consistent.
As for best practices, I cant say for sure that what I am doing is or complies to any best practice, but it works for our present requirement.
You might want to also consider the performance impact of having multiple clients making asynchrounous calls to your web server at regular intervals.
Background:
http://www.hanselman.com/blog/HanselminutesPodcast188ASPNETMVC2BetaWithPhilHaack.aspx
Start from 27:15,RenderAction has been discussed at 28:43 that a RenderAction will not be part of Asynchronocity as an asyncronous action method called.
(Let's say your home portal index action calling 1.GetNews 2.GetWeather 3.GetStock asynchronously.You have have a RenderAction displaying user recent posts on the same view. (GetUserRecentPosts))
Questions
What if RenderActions themselves are asynchronous ?
Would GetUserRecentPosts be called only after home index completed its action even though?
Should RenderActions be rendered asynchronously on a view by default?
I don't think you can do this successfully. The point where you could benefit from asynch processing has already passed when your views start rendering. The MVC pipeline that sets up the begin/end methods has already completed and the View has no way to get back into it on the same request. Seems like you may be stuck with synchronous processing OR devise some way to retrieve all your data up front and cache it in TempData or something for rendering.
Lift framework in Scala is probably the only one that I am aware of that has parallel partial actions which will not block the rendering of the main content but will use Comet-push to deliver partial view content for those blocks which may take a while to get data for.
to use it, just wrap a block in your view inside a parallel node
<lift:parallel>
//this is where Html.RenderAction("GottaFetchNetworkDataFromSomewhereView");
//this is where Html.RenderAction("GottaFetchNetworkDataFromSomewhereView2");
// would go
</lift:parallel>
Lift will also take care of connection starvation of your page to manage http requests in the appropriate manner so that browser pushes are not "waiting 'round".
Unfortunately, ASP.NET MVC has poor Comet support. There's not much outside of Asynchronous Controllers, which is an improvement but not as elegant as, say, Akka's framework suspend() method for long-polling.