I always put calls to Response.Redirect in my WebForm's OnLoad method, mostly because every example I've seen do that. I was wondering if it was any more efficient (and correct) to do that in OnPreInit? Even if the endResponse param is true?
Obviously, the sooner the better. Don't make your server do any more work than it needs to before redirecting to the real page of interest.
However, you don't always know you want to redirect prior the page load event, or even later- perhaps after handling a button press event.
Related
I looked but I don't see this answered anywhere, or at least not answered using any keywords I can think of...
I just want to have a call come in, have the code look at the user it is intended for and, if the user is currently on another call, have it go off into a voicemail. I am pretty sure I can do everything except have the system sense that the intended user is currently busy with another call... Is there a way to sense this or do I have to implement a flag or something in a database to flip on or off at the start of a call and the hangup?
In the everyday front-end development I often use DOM as a global event bus that is accessible to every part of my client-side application.
But there is one "feature" in it, that can be considered harmful, in my opinion: any listener can prevent propagation of an event emitted via this "bus".
So, I'm wondering, when this feature can be helpful. Is it wise to allow one listener to "disable" all the other? What if that listener does not have all information needed to make right decision about such action?
Upd
This is not a question about "what is bubbling and capturing", or "how Event.stopPropagation actually works".
This is question about "Is this good solution, to allow any subscriber to affect an event flow"?
We need (I am talking about current usage in JS) stopPropagation() when we want to prevent listeners to interfere with each other. However, it is not mandatory to do so.
Actual reasons to avoid stopPropagation:
Using it usually means that you are aware of code waiting for the same event, and interfering with what the current listener does. If it is the case, then there may (see below) be a design problem here. We try to avoid managing a single thing at multiple different places.
There may be other listeners waiting for the same type of event, while not interfering with what the current listener does. In this case, stopPropagation() may become a problem.
But let's say that you put a magic listener on a container-element, fired on every click to perform some magic. The magic listener only knows about magic, not about the document (at least not before its magic). It does one thing. In this case, it is a good design choice to leave it knowing only magic.
If one day you need to prevent clicks in a particular zone from firing this magic, as it is bad to expose document-specific distinctions to the magic listener, then it is wise to prevent propagation elsewhere.
An even better solution though might be (I think) to have a single listener which decides if it needs to call the magic function or not, instead of the magic function being a stoppable listener. This way you keep a clean logic while exposing nothing.
To provide (I am talking about API design) a way for subscribers to affect the flow is not wrong; it depends on the needs behing this feature. It might be useful to the developers using it. For example, stopPropagation has been (and is) quite useful for lots of people.
Some systems implement a continueX method instead of stopX. In JavaScript, it is very useful when the callees may perform some asynchronous processing like an AJA* request. However, it is not appliable to the DOM, as the DOM needs results in time. I see stopPropagation as a clever design choice for the DOM API.
It's well known that you must manipulate DOM elements inside directives when using AngularJS.
However, it seems that, in some use cases, manipulating DOM inside a service is acceptable.
Misko Hevery is talking about this here. You can also find an example within the Bootstrap UI Dialog.
Misko's explanation is rather vague so I was wondering how do you determine when you need to put DOM inside a service instead of a directive.
A directive, with the way it is defined, is always attached to a DOM node. So when you define a directive, it "expands" or replaces the DOM node to which it is attached.
In certain situations (like dialogs) you won't be able to attach DOM nodes to any specific parent. In these cases using a service makes sense and the controller can still stay out of the DOM bit because the DOM manipulation will be encapsulated in a service..
Popups could be another situation where we could probably use a service, but unlike a dialog, a popup IS attached to a DOM node. So, even that is slightly a grey area.
So, a basic and simple test is, "Can this bit of DOM Manipulation code be attached to a DOM node?" If yes, then directive. If no, then service.
Dialogs and Custom Confirm Boxes come in as typical examples where you would use a service.
Whilst I think Ganaraj has described what Misko was saying well, you could (and potentially should) argue that the DOM manipulation code for a modal dialogue (for example) can be put into a DOM node.
One approach is to have a dialog directive attached to the DOM the whole time, and then use ng-show to conditionally show it. You can then communicate with the modal dialog using either $rootScope, or better: a service.
I actually prefer this approach because it feels 'right' - the service handles the transfer of data and the directives interact with the service to make sure it gets displayed in a way that makes sense to the user.
But I think the fact that Misko is not particularly clear about it shows that it's quite subjective. Do what makes the most sense to you.
I'm googling this topic to reinforce my inner feeling about this because I'm working on an issue right now that makes me want to place certain logic in a service. Here's my case, and what I think is a plenty good justification for putting dom-based handling in service:
I have directive-based elements that react to mouse position, globally (e.g. they move or change in some way based off mouse position). There are an indeterminate number of these elements and they don't pertain to any specific location in the application (since it's a GUI element and can pertain to any container anywhere). If I were to adhere to the strict angular "dom logic in the directives only" rule, it'd be less efficient because the elements all share the logic pertaining to parsing the mouse position (efficiently) which revolves around window.requestAnimationFrame ticks.
Were I to bundle that logic into the directive, I'd have a listener/raf loop tied to every single instance. While it'd still be DRY, it wouldn't be efficient since on every move of the mouse you'd be firing the exact same listener that would return the exact same result for every single element.
It's actually best in this case to move this into a service, despite it being dom-based logic, and register each directive instance against the service to call the same, instance-based logic against the logic performed that would be duplicate for each instance.
Remember, while Angular provides some very good advice around how to structure you code, that does not make it bullet proof of by any means a hard and fast rule, since it can't possibly cover all use cases. If you see a hole where the "best practices" seem to fail, its because you're actually properly understanding the best practices, and you've now found a reason to break the rules on purpose.
That's just my 2 cents!!
I agree with #dudewad. At the end of the day a service (factory, provider, value) is just angular's module pattern with the limitation of being implemented as a singleton. I think it's important that you get access to the DOM via an element that is passed into a directive's link function and not by using document or other global approaches. However, I don't think that it's important that the logic that you apply to dom element that you get from a directive lives in the same module. For SRP reasons it can be favorable to break up the code a bit using a service as you might have a particularly complex piece of logic that it makes more sense to have focused test around or you might want to use the logic in more than one directive as pointed out by #dudewad.
one drawback to using a DOM manipulation method based off of changing a variable (ie, ng-show="isVisible") is that the DOM manipulation occurs after the next "javascript turn" loop (when isVisible is updated). You may need the DOM to be updated right away.
For example, a common scenario is displaying a "spinner" during transitions to a new route / state. If you were to set $scope.isVisible = true on the $routeChangeStart / $stateChangeStart event, and then $scope.isVisible = false on the $routeChangeSuccess / $stateChangeSuccess event, you will never see your ng-show, as the whole route / state change happens within one javascript turn. It would be better to use .show() and .hide() in those events so that you actually see the spinner.
to bring this all back and make it relevant to the OP's question -- in a situation where the DOM manipulation is a "spinner" modal being displayed, I would do it during the service, and I would do it with direct DOM manipulation methods, rather than relying on a model change.
I have a method in action page, it will take more time to execute so I have write some description on console window. But now i want to show the description on text area in jsp page. how to show like as console.
Two possible solutions are the "execAndWait" interceptor and using ajax.
Execute and Wait will be the easier to implement but will present less functionality...
http://struts.apache.org/2.3.4.1/docs/execute-and-wait-interceptor.html
Ajax can provide continuous feedback of the state of the request (although managing that feedback is entirely up to you and it will typically require you to think in terms of services, one page will typically make use of multiple services).
For this you will not have to worry about the amount of time it takes your action to return because it is being called asynchronously. You could even make a queue showing how many request you've sent and pop them off as they are received.
To implement ajax services it is easiest to start with json and for that see the struts2-json-plugin http://struts.apache.org/2.2.3/docs/json-plugin.html
This existing question sums up the basics of my question. The best answers there tells the difference between the two methods. I am looking for guidelines as to which method to use.
In short, I have an action in a controller which process a form and then display the results of the processing. When should I use return View() as opposed to return RedirectToAction("FormResult")?
I would venture to say there is a hard and fast rule (well as much as there can be) - the Post/Redirect/Get (PRG) pattern. The standard with MVC (and the html helpers actually expect you to use this pattern) is:
post your data.
If there is an error (i.e. ModelState.IsValid=false) then return View() otherwise return RedirectResult.
If there was an error the HTML helpers will actually look at the posted values to redisplay as opposed to what you pass them by View(model) - again because the PRG pattern is 'supposed' to be what happened.
You can really use either. Generally speaking, though, after a form is posted you want to redirect so that refreshing the page doesn't cause the form to repost. Sometimes, however, it's not feasible to copy state to the new page and your processing is idempotent so refresh wouldn't hurt anything.
It's not that there's a hard-and-fast rule. You kind of have to weigh the pros and the cons.
Return View doesn't make a new requests, it just renders the view
without changing URLs in the browser's address bar. Return
RedirectToAction makes a new requests and URL in the browser's
address bar is updated with the generated URL by MVC.
Return Redirect also makes a new requests and URL in the browser's address
bar is updated, but you have to specify the full URL to redirect
Between RedirectToAction and Redirect, best practice is to use
RedirectToAction for anything dealing with your application
actions/controllers. If you use Redirect and provide the URL, you'll
need to modify those URLs manually when you change the route table.
RedirectToRoute redirects to the specifies route defined in the the
Route table.