I'm refactoring some Flex code written by another developer and I'm implementing a PresentationModel approach, as I like to separate out the ActionScript from the MXML. One of the problems I've found is that the original ActionScript code adds/removes elements from the MXML.
What happens is the handler function checks the model and if the values are correct will either create or remove a element from the view. What is the best way to get the presentation model to ad elements to the view and still keep this loose coupling that I'm aiming for.
I was thinking of using simple events which the presentation model dispatches and a view can list for passing the details of the element to add. Is there another solution?
Thanks
Stephen
If you're using the presentation model, I'd assume that you have some kind of data of what needs to happen. When items of any sort are being dynamically added/removed, I make sure to make it data-driven for easier manipulation. If you want another item added, add another data model to your dataProvider of choice (List, ComboBox, DataGroup, etc).
By doing this approach, you're abstracting the logic from the presenter to the view. Events should only be used as a way for your view to know when your presenter has accomplished something. Data can be received this way (and it's good practice to do so) OR you can just bind the data within the presenter to your dataProvider. Both are good, I just find binding to be cleaner and simpler.
Every part of code that do some graphical stuff (drawing border, setting style, drag & drop management, animations, ...), should be included in the view, not the presentation model.
For this kind of graphical that stuff should be executed after a property has been changed in the PM, we use the Cairngorm 3 Observer lib. Basically, it listens to some changes in the presentation model and allows you to execute a function in the View.
<cg:ObserveValue
source="{ model.firstName }" value="{ Name.SARA }"
handler="runEffectFunction"/>
See the documentation
Related
I want to know if its a good idea to have an mxml file for each component, then inline these various components in one mxml file and able to communicate between these mxml files ?
For example I have a overView.mxml and in this, i inline the other mxml files which contains components like datagrid, another mxml contains may be a form. Will i be able to communicate to the grid data by accessing its id in the form mxml ?
Please let me know if my question is not clear. I will try to rephrase it.
Thanks so much.
Yes, this is a good idea. It's much better than creating one giant MXML or class that contains all of your functionality.
At the same time, it caries some overhead. To communicate between the classes (MXML files are just classes) you have to dispatch events. A parent component that contains child components, can set public properties of its child components (with or without data binding).
You should try to decouple your components as much as possible. Try not to write code where the child component is explicitly referring to the parent (ie: try not to use the parent property). Instead dispatch an event from the child component and make the parent listen for the event.
Regarding your example with a data grid and a form:
If these two objects will have a lot of interaction between them, it will be much easier to keep them in the same MXML file. This doesn't sound like a scenario where one is a parent component that contains a child component. Since these "siblings" are likely to communicate w/each other, it would be easier to have them in the same MXML file. However, if things get complex and the file grows to more than a couple hundred lines, you will likely benefit from separating them.
Let's say you plan to use the form component elsewhere in your project w/out the data grid, then it also makes sense to separate them.
Regarding your question: "will the form component be able to communicate w/the grid component by accessing it's id?":
Technically, yes, you could do that but only by tightly coupling your form component w/the grid component. The form component can use the parent property to go up one level and use the id of the grid. But since the parent property is typed as a DisplayObjectContainer you have to fool the compiler and you loose the benefits of strong typing (because the DisplayObjectContainer doesn't have a property that is the ID of your grid). So while this is possible, it's not good design and prevents you from reusing the form component elsewhere.
This tight coupling defeats the purpose of creating separate components. So you're back to either facilitating that communication through dispatching events, or putting the grid and form in the same document :)
TLDR:
You should generally be trying to create re-usable components. So I would generally lean in that direction. MXML files are just classes, all the usual things people talk about in object oriented programming apply.
I have to create a Dynamic menu in ASP.NET. I want to use dynamic LinkButtons (or can be a Menu Control), but should be appended with sequence numbers. Eg: 1,2,3a 3b etc..and these sequcenes could be dynamic. Any idea. I used a repeater with a label and LinkButton in it, but having problems with view state. Any idea how to append sequence to menu??
Essentially, you have two paradigms with web applications, at least from this conversation's standpoint.
Stream out the HTML, creating it as you stream
Create containers that can bind to data and shape the data
Your concept seems to be "only #1 is dynamic", but that is not true. Any time you can change the data and get a different output, you are dealing with something dynamic. My personal feeling is shape the menu data prior to binding. This cannot always be done, but more oft than not, it can. The second method would be to attach to an event like a item binding or row binding event. Controlling the HTML stream and writing out individual items is generally my last resort.
Now to the viewstate issue. Viewstate is a bastard when you start adding things to an item after binding and semi-problematic when you are playing the dynamic game from #1 above. The problem is things added after the initial definition cannot easily be set up with automagic bits. You end up having to rebind each time. This is why shaping data and then binding is superior. Even in cases where you have to rebuild, you can cache the shaped data and quickly rebind. It takes more "up front" work, but is less problematic.
The actual container you are binding with is inconsequential. Unless you can't use the menu control for some reason (other than having to dynamically add, which can be solved by playing with the bound data), I would head this direction. Actually, I would head this direction and use the CSS friendly adapters so you can alter the look and feel more easily. :-)
I'm pretty new to Flex and I don't know how to solve this problem.
I have 3 mxml components. In Component 1, I let the users fill in some data. In Component 3 I want to use the data, but I can't find a way to make it work.
Can someone help me, please? :)
I can show you code, but I think it would complicate the things a lot because it is data coming from a slider and the code is pretty long.
I feel like I answer this question on a routine basis. What is your display hierarchy?
Here are a few common things:
If component3 is a child of component1; then just pass the data in using public variables
If component1 is a child of component3; then wrap the data in a custom event and dispatch that event from component1 up to component3.
If component1 and component3 have the same parent, then combine the previous two approaches. Wrap the data up in a custom event, dispatch it to the parent. Have the parent pass the data down into component3.
A lot of frameworks make use of singletons and/or dependency injection; to help share data between components in more complicated architectures.
A quick Google reveals these sources; which seem to cover similar ground and may help:
http://www.actionscript.org/forums/showthread.php3?t=120330
how to use mxml component in another actionscipt
Pass data between flex components
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'd like to develop a network graph application for Flex - imagine placing nodes on a Canvas and connecting them with links. The nodes should have editable text and other UI components.
I'm trying to find examples of creating an entirely new UI component from scratch, but all I've been able to find are trivial examples that extend existing components: a RedButton that extends Button, for example, or a ComboBox that has states to choose from.
My main question is, what ActionScript method defines the drawing of a component? What is the ActionScript equivalent of Java's paint() method?
You want to create a component that overrides the updateDisplayList method, and do your drawing in there:
override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
super.updateDisplayList( unscaledWidth, unscaledHeight );
// The drawing API is found on the components "graphics" property
graphics.clear();
graphics.lineTo( 0, unscaledWidth );
// etc
}
More information can be found here: http://livedocs.adobe.com/flex/3/html/help.html?content=ascomponents_advanced_3.html
I would suggest looking at the flexlib project if you need examples of custom components.
There's good general info in the livedocs here
Although you can create custom components in MXML and in ActionScript, I would recommend implementing them in ActionScript.
In short this is what you need to do:
When you create a custom component in ActionScript, you have to override the methods of the UIComponent class. You implement the basic component structure, the constructor, and the createChildren(), commitProperties(), measure(), layoutChrome(), and updateDisplayList() methods.
I recommend reading the 5-part tutorial series by Peter Ent on creating custom components.
Here is the link to Part 1.
Also recommended, tutorial series on ItemRenderers and ItemEditors.
Chapter 19 of Programming Flex 2 by Kazoun and Lott show the construction event model as well as the refresh event model.
In short, the Flex component structure assumes that you have properties of the object that affect its appearance. Instead of applying changes immediately, it allows property mutators to invalidate the component's "content" (e.g. text) via the inherited invalidateProperties() method. One also calls invalidateSize() when a property change will, ummm, change the size of the component, and invalidateDisplayList() when things need to be re-drawn (as opposed to just having different text).
This invalidation model optimizes the work of the component. It does not measure itself unless it knows it changed size; it does not place and draw itself unless something called invalidateDisplayList() since the last time it updated its layout; and it does not move its properties' values into its subcomponents unless it knows those values have changed.
Cheers
The typical behavior is to subclass an existing component, mainly because so much of the work of implementing the functionality of so many of the most typical kinds of components is already done for you -- you just have to know which component most resembles the one you want to create. (A challenge in its own right, given how many there are.)
If you like, though, you can create a pretty bare-bones UIComponent "from scratch" simply by extending UIComponent (which'll give you all the baseline stuff), or I suppose, if you're really going for minimalism, and you're up for a challenge, you can just implement IUIComponent, and define each interface method manually. If you do choose to go that second route, do yourself a favor and listen to this talk first -- it's an in-depth discussion of the Flex component architecture, given by one of the engineers on the Flex team. I recommend it often, and highly; it's excellent, and it clarifies a number of component-development details that still aren't all that well documented. Extremely valuable stuff if you're going to be building non-trivial custom components of the kind you're describing.
Hope it helps. Good luck!