So, I should place the listener of the child view buttons in the class document/PanelView.as then it dispatches events which the Mediator is listening?
Yes. And if you are going to be listening for those events somewhere farther up the display list, then make sure set bubbling to true for the event. For instance, if the button is in a panel, which is inside a tabbed navigation component and the mediator is listening to the tabnav, then you'd need the event to bubble up.
Is it also a best practice say for the view component to have its own event constant, rather than using the its applicationfacade constants?
View components should know about nothing other than your value objects. The easiest thing to do is create a custom event called AppEvent, and it has constants for all the user intentions that will arise from the interface in the form of an event. Make it have a data property so it can carry things and the Mediator won't have get the data from the component itself. In the Mediator, you translate these events to notifications for other mediators or commands to work with. Put those constants on an AppConstants file. Don't worry that sometimes you duplicate a constant on the event and the constants file. There may be overlap (e.g. AppEvent.EDIT_ITEM, AppConstants.EDIT_ITEM), but they are never one to one, and the separation can be thought of as a protocol. One side defines user intentions, the other defines system responses.
My issue really is I have this panelview.as which is a single movieclip that contains groups of related buttons and other widgets. If I directly change the view component's state then i would have long lines of code. Since i would introduce lots of functions for the interaction. Is it ok if i do this?
Encapsulate the state management inside the component itself. Your brain is in charge of its own state. There's a lot of stuff in it and it's very complex, but it works, and the liver doesn't have to be directly involved in every thought. In the same way, you may find that your view components are sometimes quite large because they have a lot of code in them for managing their own state. You start to think, 'well, I have this mediator where I could offload a bunch of this code,' right? Wrong.
If your panel has tons of objects inside it such that managing all their states is cumbersome, then subdivide your panel into multiple components. If the panel has a graph with associated controls, and a data grid with bunch of filtering controls, then break it down. Move the graph and controls into a custom component, and move the datagrid and its filter into another. now the panel only contains two components, and its code for managing them becomes way simpler. Inside the custom graph component, you have only the code for managing the graph and in the custom grid component, you have just the filter and display of the data in the grid. The panel probably gets the data that both components work with from the mediator and passes it on to them. But they are now in charge of their own behaviors and will consume the data and present themselves accordingly.
So in short, if your View Component is getting bloated it is not a sign that your Mediator needs to take on more responsibility, instead, it is an indicator that you need to subdivide your View Component.
-=Cliff>