In my flex project i used one option like Link button . If i like it will be open new page
contain more information and components . Which container is suitable one ?
Where is used viewstack and stages ? if you know please explain it . or refer me
With states you can have objects in each state with the same id - this cannot be done with a viewstack. Usually states are used when a group of objects are shared amongst the different "states" or "views". So for example you can have a textinput in each one of your states and give each one the same id of "username". When you reference the "username" id it will use the object in the currently enabled state. If you try to do this with a viewstack it will throw an error saying you've defined an id of "username" multiple times.
So as a wrap up... use states when you're adding or removing components from a set of components shared throughout each state. Use a viewstack when each view is different and do not share components.
Use states when your views are very similar and only differ based on a few controls or components. If you have too many AddChild / RemoveChild elements it becomes more difficult for a developer to follow your code.
A ViewStack also supports deferred instantiation through the "creationPolicy" attribute. This means that only the first Container in a ViewStack will be initialized when the ViewStack loads. This can really speed up load time of your application if you (A) have a lot of children in the ViewStack or (2) the children are large / complex components.
Related
I have a generic function to build rows of controls (each row comprising of sliders, radio buttons, reset buttons, text display) etc, and some functionality to change underlying data based on these
As I didn't want to write specific code for each row, I had code written by which I can detect the row on which there has been a mouseevent, and though the row access each individual control
The hierarchy used is titleWindow (part of popup)->skinnable container->HGroup->control
When I trace for a radiobutton, I get the path as follows Electric_Modify.TitleWindowSkin2620._TitleWindowSkin_Group1.contents.contentGroup.0.RadioButton2645
The '0' before the radioButton stands for the first Hgroup id->named as 0
I tried accessing the radio button as follows- 5th element in the HGroup
((this.contentGroup.getChildAt(row)as Group).getChildAt(4) as RadioButton).enabled=false;
and get a message "Cannot access a property or method of a null object reference" on this line. How should I navigate the hierarchy to reach the element?
You should be using getElementAt(...) and not getChildAt(...).
The get element functions represent a "higher level" element hierarchy which is needed to make skinning easier.
((this.getElementAt(row) as IVisualElementContainer).getElementAt(4) as RadioButton).enabled = false;
It should look something like that, but the exact hierarchy depends on what's in your app.
#drkstr
Thanks for your input... I thought of an alternate approach that worked for me...I mapped out the parent of the HGroup via
parent1=hgrp.parent; and then referenced these buttons as follows
((parent1.getChildAt(row)as Group).getChildAt(4) as RadioButton)
This works like a dream...I presume your suggestion would let me jump across the intermediate layers
#J_A_X/ #Constantiner: Thanks for the suggestion. I have no idea why we didn't think through and go down the DataGroup path. Prima facie seems simpler... we got to creating the UI controls in MXML laying out controls serially,and when it came to making it generic, we literally replicated the MXML approach in AS. Started off easy, till it caused problems like above. We will fix this to a better approach, when we upgrade versions. It works for now
In the examples for RobotLegs, it appears that mediators are used on every button/textArea, rather than on the custom component that contains these children. This would be very time consuming would it not?
From Joel Hooks InsideRia Example
Dependency injection works better with
unambiguous classes. What this means
is that by extending TextArea into our
new MessageView class, we are creating
a specific view component for the
dependency injection to act upon. This
is important if our application were
to have several TextAreas that served
different purposes. By dividing up our
classes in this way, we are clearly
defining the intent of the class and
allowing for the dependency injection
tools to do their jobs effectively.
No, don't mediate every child component. Your components should be organized into groups that perform related actions. In the examples the components are extremely simple and do not reflect what a real application would look like.
One rule of thumbs I use is thinking if that component needs any communication with the rest of the application, or if its only a part of a whole. Keep in mind that mediator are only intended to serve as a bridge between the view and the app.
For example, if I've a view with a form (asume a login form) I don't mediate all the child components (the textfields, the buttons, etc.) because it would be pointless and would have a proliferation of classes and objects on runtime. When I do the form I think, what does the view by its own? and what the other parts of the app should do with it?
When the user fills the form and clicks a button, the view dispatches an event (LoginRequestEvent, for this case), and then the mediator should redispatch that event, making the mediator very lean.
But with practice of the framework, you'll come up with this feel of what you shold mediate. For instance, in one app I mediate every item renderer of a list, and on other I mediate a view stack with two or three navigation contents.
Hope it helps
I have a Flex application with three different views. Only one view is shown at a time, and the choice of view depends on what part of the application the user is working with. If it had been an ordinary HTML webapp I would have created three different HTML-templates/pages for each view.
What is the recommended way to handle such application views in Flex?
The behavior you want is usually accomplished by using a ViewStack component. In MXML you declare child containers for each view you want, but only one gets shown at a time. You can change which one is shown programmatically whenever conditions are met by setting selectedIndex on your ViewStack. By default the first child container is displayed when run. Another approach is to declare and use states in your container and change currentState whenever you need to change the view. Hope that helps.
I have two mxml files. one is main that is application tag mxml file and another is my mxml component file.
I have a viewstack in my main mxml whose id is, say, "mainViewStack".
Now I want to set selectedChild property of "mainViewStack" from my mxml component file.
But I m getting error:
Error #1009: Cannot access a property or method of a null object reference.
on accessing mainObj.mainViewStack.selectedChild.id where mainObj is the object of main mxml file.
Please help me out.
Thank u.
My guess is that you're trying to access the child before it's created. But that's hard to tell without the code.
Try waiting until the FlexEvent.CREATION_COMPLETE event on the application to access the selected child.
This issue is referred to as "deferred instantiation" and is a product of the Flex Component Lifecycle. If you want an extremely thorough explanation of this concept, this white paper is probably the best I have read.
Essentially Flex creates components as they are needed. Each component has a lifecycle that takes it through stages:
Construction
Addition
Initialization
Invalidation
Validation
Update
Removal
A sub-component isn't going to be accessible until it has passed through the initialization phase. This is the point at which a Flex component will dispatch its CREATION_COMPLETE event, letting you (and the framework) know that it is ready for interaction. Prior to this event, you are going to receive null reference errors when attempting to access the component or its children.
ViewStacks compound this by default by not initializing sub-components until they are called for display. The creationPolicy property of a ViewStack, by default, is set to auto. There are several options for this property, including all. Be aware, however, that this can potentially present severe performance issues, as all of the components inside the stack are going to be initialized immediately regardless of whether or not the user actually even looks at the component.
In your specific case this isn't the problem. The component that contains the view stack hasn't been completely initialized. You need to set the child of the ViewStack in a CREATION_COMPLETE event handler.
or you can give "creationPolicy=all" because Flex only creates the first visible child from the viewstack
You can use this code in your MXML component to change application's ViewStack selected child from other MXML component. However it is not a good practice.
FlexGlobals.topLevelApplication.mainViewStack.selectedChild = FlexGlobals.topLevelApplication.childId
You can use static event dispatcher to dispatch an event from one view and listen that event in an other view.
I seem to be running into an issue (Cannot access a property or method of a null object reference) binding events in actionscript to a viewstack layer not currently showing. Are those objects not created until that layer is visible for the first time? I remember something about a creation policy, if this is the case, can I force it to create those children before that layer is viewed?
Yes, that's right -- ViewStack children are created only when needed by default ("deferred instantiation" is a phrase you'll hear thrown around in this context). If instead you want to instruct Flex to create all of the ViewStack container's children up front, consider using the creationPolicy property common to all mx.core.Containers:
A creationPolicy of
ContainerCreationPolicy.ALL means that
the navigator containers immediately
create deeper descendants for each
child, rather than waiting until that
child is selected.
<mx:ViewStack id="myStack" creationPolicy="all" />
It's a bit slower on startup, because you're creating a bunch of child components you might not need yet, but as long as you keep that tradeoff in mind, it may come in handy sometime.
Yeah, I had this same problem myself while working on an application with a PureMVC structure. I was unable to create mediators for the subcomponents of a ViewStack because they were constructed lazily by the Flex framework.
Here's where I eventually found my solution:
http://forums.puremvc.org/index.php?topic=280.0
Found the relevant documentation here. Seems like that'd be something you'd make a note of on the container docs.