I am trying to figure out how to implement a Polymer component that will centrally handle errors that other components on the page might encounter. The idea is to have a single point of error handling on the page and have all components send errors to this error handler component.
The problem is I am not sure about the architecture of all this. I see two ways to do it:
let all the components be aware of the error handler component and when they see an error, let them look up the error handler component by ID and call a known method on it.
let all the components fire error events and have the error handler component listen to these events. The problem is how to find all components on the page to attach event listeners to. Also, what to do with components that are created on the page dynamically? Listen to DOM changes?
Does anyone have any thoughts?
An easy method is to have your handler component listen for error events on document or window, and then have your reporters fire the error events directly on that object (or let them bubble up).
Related
I have created a SSIS package for migrating data from one sql server database to another. The tasks are created in a sequence container.
I have created events in the event handler and added the send mail task for sending email and getting the following error. I get this error even when I try to evaluate the expression in the expression builder. Please note that I am getting the error on the onTaskFailed event handler. I think the system error variables are not accessible in that event. Do I really need that event handler
I can see the variable in the collection. Not sure of how the scope affects it.
This is definitely a scoping issue. The system variable 'ErrorDescription' is only avialable at 'OnError' event handler and can't be used in 'TaskFailed' event handler. As to the question of if you need it or not, that is something your business logic should dictate. I would suggest to move your code to 'OnError' event handler.
When an http error is received by the controller in my Flex app, I need to display an error and then return the user to the login page. If I'm catching that error in a UIComponent, I can use:
this.parentApplication.currentState = "login";
But how do I do this from a class that isn't a UIComponent?
Thanks.
EDIT: I know I can dispatch a custom event and listen for it elsewhere in the app; I'm just wondering if there's a more direct way to do it.
You can refer to the application object as mx.core.FlexGlobals.topLevelApplication from anywhere in the application.
See the docs about the application object
I have a custom component called shopView which is an MXML skinnable component. I have a controller class called ShopController which takes care of showing this component in popup, updating info shown in the component etc.
Now, I wanted to maniupate some of the subcomponents of this ShopView after it has been created from the controller after the ShopView is created (creationComplete() event)
So, I have attached an event listener which intern does some initialization process
creationComplete="init(event)"
the init() function
private function init(event:FlexEvent):void{
event.stopImmediatePropagation();
initMenus();
initSlots();
dispatchEvent(event);
}
Attached another creation complete event from the controller class
_shop.addEventListener(FlexEvent.CREATION_COMPLETE,onShopCreated);
*_shop is the instance of ShopView*
Now, if you see the init() function, there I am stopping the event propagation, doing some initialization process and after that I am dispatching the event (for the shop controller do the rest of the job)
Now, this is crashing the app because the crationComplete event of the ShopView is recursively called. I was thinking the dispatchEvent will propagate to the other listerners but seems like it is propagating back to the same component.
I have fixed it by removing the e.stopImmediatePropagation() and dispatchEvent(event) lines from the init() function. But I want to know why it is happening like this?
Is it a known issue for the mxml/flex components? OR it is expected behavior?
Update: I am not doing same in .as as I said below. Got answer, basically its my stupidity :)
because I have not seen this behavior when I write .as classes where I
stopevent propagation and dispatch the event based on business logic.
Thanks in advance.
This is expected behavior.
When you redispatch an existing event dispatchEvent automatically clones it (since you can't dispatch the same event twice.) This clears any propagation-related flags.
May I ask why you want to redispatch CREATION_COMPLETE in this situation anyway? Both handlers will function just fine without the two lines you removed.
I am working on an AIR application:
The main window is like a dashboard. With the menu bar, I can open other windows with dashboard details. When I close these, I'd like to refresh the main window.
I tried to use an event listener, but the result is not good. If I open detail windows directly from the main window, I know how to add an event listener - and it works - but I don't know how to do it, if the detail window is opening from the menubar!
Thanks for helping me.
A Singleton is what you are looking for. Just put an event dispatcher inside and you will be able to listen from everywhere in the application.
A Singleton is like having a unique instance of an object in memory, so anyone modifying a variable inside that object ( or sending events throught ) will be modified for everyone.
Here is an example of code on how to use it.
http://life.neophi.com/danielr/2006/10/singleton_pattern_in_as3.html
Note: Singletons are powerful and dangerous at the same time, there is a lot of talk about how to use them, please read a little more about that if you are considering building a big project.
Hope it helps!
The issue is that you're performing business logic from a View. Don't do this. Instead, dispatch an event from each menu rather than directly opening the window from within it. Listen for those events at a higher level, and then you can either directly listen to the new windows you have opened, or you can create a base window Class that exposes a variable of type IEventDispatcher. If you populate that variable with the same event dispatcher, what you wind up with is called an "event bus," and you can listen on that for events.
This architecture requires a little more thought than using a Singleton, but it avoids the tight coupling and other issues you'll run into by introducing one into your project.
You can listen to an object (EventDispatcher) directly by adding an event listener to it, or if the dispatcher object is on the displaylist, such as a Sprite, you could listen at the stage level with the capture parameter set to true.
But the main caveat is that the dispatcher must be on stage for you to catch this event.
Your main window listens to stage (with capture = true):
stage.addEventListener("MY_CUSTOM_EVENT", handle_custom_event, true);
private function handle_custom_event(e:Event):void
{
var sub_window:Object = e.target;
// do something to your sub_window
}
Your sub window can dispatch events like this:
dispatchEvent(new Event("MY_CUSTOM_EVENT"));
But (ab)using the stage as a message passing infrastructure for custom events in this way is a little messy. You could consider a more formal message passing architecture if you really want this kind of communication. Even a static MessageBus class would at least quickly help you identify where you use this in your codebase. Either way, you'll have to be careful about references and memory leaks.
I'm trying to add an event listener to my air application that would prevent the "ActionScript error" window from appearing, so I can handle the error within my application.
I was able to find a little information about this from adobe. I'm just not sure what I should be listening for.
It depends quite a lot on what error is thrown, and why.
Your best bet is to carefully read the ActionScript documentation and add listeners to react to all of the errors that have explicit ErrorEvents (such as IOErrorEvent and SecurityErrorEvent). Those are usually related to network and/or file access, and security issues.
For most other errors, there is the try {} catch() {} finally {} statements. This tutorial might be a good place to start.
And if all else fails, there's UncaughtErrorEvent.
But you should really be using that one as a last resort, not as a magic bullet - the best error handling is a) trying to prevent errors from being thrown in the first place (make sure all variables are properly initialized, test for null, etc.), and b) handling expected runtime errors by catching them explicitly, in order to keep the application running and stable.
You have a couple options. As you know, exception handling is not always possible for certain asynchronous operations.
First off, you need to know what object is responsible for the asynchronous operation that is causing the error. The most sensible approach would be to add the necessary error event handlers to this object.
For instance, a URLLoader performs asynchronous operations; and it's failure can only be handled by adding error event listeners. For example:
var loader: URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, completeHandler);
loader.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
Another 'catch-all' option is to take advanage of the new UncaughtErrorEvent feature of Flash Player 10.1. For this to work, you need to attach the uncaught error handler to the loader of the main application; this will catch everything! For example:
loader.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, loaderErrorHandler);
private function loaderErrorHandler(e:UncaughtErrorEvent):void {
if(event.error is Error) {
// handle error from embedded SWF
}
// suppress error dialog
e.preventDefault();
}
The last option may not be the best approach as it promotes the swallowing of exceptions instead of addressing and handling the problem properly; nevertheless it can be useful in certain unique circumstances (embedding SWFs).
The window won't appear if you're running the standard version of Flash Player.
It will manifest only as a dialog box on the debugger versions of the
browser plug-ins and stand-alone players, as a message in the output
panel in the authoring player, and as an entry in the log file for
Adobe Flex Builder 3. It will not manifest at all in the release
versions of Flash Player or AIR.
Source : here.