« January 2008 | Main | March 2008 »
When adding code paths in Erlang, whether a or z, you must put double back slashes.
example C:\\dir\\proj
I’ve been repeatedly burned on this the last few weeks and thought that other erlang noobs might find it helpful.
I haven’t been real interested in the Microsoft Yahoo! deal. I think, because by and large, I can’t see much benefit for me as a flex developer out of the deal. But apparently after escaping from the clutching arms of Bill Gates and his teams of minions, Yahoo! has seemed to wander right into waiting arms of Rupert Murdoch and his News Corp, ( which is looking more and more like the Umbrella Corp ).
Now this is more interesting to me. Yahoo! and MySpace together with the MySpace Incubator program and also, since Yahoo! has been giving alot to the flex community lately like the recently released Yahoo! Maps. Think about building an app with Yahoo! data feeds, combined with MySpace socials all wrapped up in an incubator program designed to bubble up new and exciting apps. All that’s left to do is write your business plan.
Well, if they don’t get together, somebody else ( Google, Microsoft, Amazon ) is going to do something similar. And if not there’s always this option.
ps. It’d be nice if Adobe put up some Cloud Servers, but that’s probably not their bag baby.
I’m curious as to how many developers use the Flex Development perspective vs the Flex Debugger Perspective. Personally I only use the Debugger Perspective. I have it modified for preference ( and I'd like to think style of course ), but I don’t want to become one of these.
When Thermo comes out, will they drop the two perspectives?
So flexmdi has been out for a while. People are moving already moving towards an even more Active Desktop and so I though I’d throw together a quick multiple desktop document interface. Easy for you to say. This is just a rough example and none of the code has been imported into flexmdi. And there are definitely some problems with it. I’ve taken a couple approaches at this, and really am only showing this to generate ideas / help / support at to what exactly people are looking for.
I’m using a modified version of Ely’s Display Shelf. ( thanks ). Also, I’m taking snap shots of the screens and there is problems rendering the desktops that haven’t been created. I’ve tried displaying the actual scaled instances, ( wasn’t pretty ). I’ve also tried Doug’s FlowContainer which I will probably attempt again in the future because it seems to fit.
Important : When viewing the desktop picker use your arrow keys ( Left and Right ) to navigate. Hit Enter to select the screen.
Here’s a first pass. demo
Here’s another approach by the Replicants. Thought’s and suggestions welcome.
I use working sets a lot to organize my projects into…, well working sets, of course. It’d be nice if when creating a project if there was an option to add the new project to an existing working set.
For a contextual meaning of the following you’ll probably want to check out this post by Jesse Warden.
While in the course of building flex applications there almost always comes a time when events just don’t line up properly for whatever reason. For example Global Event Listeners that listen for events that reside in modules that may or may not ever get loaded. Renderers that are use in repeater/list/grid controls that may don’t define our events in their metadata. And also, events that are fired from NonVisual Components that may or may not reside in the Display List.
In all these cases, the difficulty resides in the fact that as a developer you may not have / know about the specific instance of the object you want to add your listener to. In most cases this is OK, because as long as the component is a visual component you can still capture that event by adding your listener above it and using capturing/bubbling. The backstop in this scenario is always the SystemManager where you can add listeners to. However, you have to make sure you bubble or useCapture.
In the case of Global Listeners using the SystemManager is fine. But if we’re nested in three or four screens and we want to have specific instance code run and no more, because we may have two or more instances of the same object on the screen at one time, we don’t want the event getting all the way to the SystemManager, ( and we need to remember to stop the event) A better solution would be to confine our event to specific context. A localized SystemManager of sorts. In the case of using a DataGrid custom renderer and dispatching the event we want to listen for the the event in the document that houses the DataGrid. The document object gives an instance level where we can dispatch and listen for events safely. The document object also makes sense from a coder’s point of view. If I create a Panel called MyPanel and stick a button in it that dispatches an event, and then create two or more instances of MyPanel, what we get is objects named like MyPanel0, MyPanel1, MyPanel2, etc.
To get to the basics of how and where we dispatch our events there are only a few things we need to worry about. First, there is always a point up the Application tree where our events can be captured. Thus, the listener is the only one that needs to know about where the rendezvous point is. The object doing the dispatching doesn’t need to care. The way I think about this is:
Listeners, need a rendezvous point from which they can capture the event. Dispatchers must know how to define their target.
To help me remember how to set these two events properly I created an EventManager class that hides the implementation of dispatching these events from me. I also created an AppEvent class from which I can extend my AppEvent classes. An AppEvent might be something like a UserEvent.LOGIN that is global, or might be specific to different sets of code in my app, like a ProjectEvent.PROJECT_ITEM_CHANGE event. All classes in my app can then import my EventManager class to make sure they can dispatch and subscribe to events in the context they need to.
The Signature on my Event Manager class looks like
static function addEventListener( type:String, listener:Function, rendezvous:EventDispatcher = null, priority:int=0, useWeakReference:Boolean=true ) : voidpublic
public
static function dispatchEvent(event : AppEvent, target:EventDispatcher = null ) : void
Some noticeable things about these two methods because at first look they look pretty harmless, in fact almost useless, and duplicated. First with my addEventListener, the noticeable thing is the rendezvous object that you can pass in and that defaults to Application.application. This allows you to look up and down the object chain to find the exact point where you want to add your listener. The addEventListener always uses useCapture, and the AppEvent class always bubbles so we don’t need to worry about whether the event will be caught or not. ( This is especially good for team scenarios where there’s always a fat fingered member that fancies himself a proctologist )
Second on the dispatchEvent method you’ll see that a target is allowed to get passed in ( it defaults to Application.application, which means Global) , which creates some interesting side effects and a lot of flexibility. Essentially passing in a target allows me to set the target of the event in scenarios where an event might not originate on the target. This is real handy when dispatching events that are defined off data as in ValueObjects, a good example might be when I want to dispatch that UserEvent.LOGIN event and I want my target to be a UserVO object. The actual login event might originate when the data arrives from the server with our user info. I can then propagate the UserVO throughout my system and anybody who cares can do something. Our UserVO might contain permissions and we might need to change our layout, or it might contain user preferences, etc..
The ability to set the target of an event is also a handy technique when using NonVisual components. I pointed out in this article how to create a non visual component that is implemented in mxml. Jesse pointed out in his article that he’s changing his mind about using IMXMLObject, which is a fair argument, but when you think about events as Listener : Rendezvous, Event : Target and then realize you can switch out the rendezvous and target, it doesn’t take Tom Sawyer to paint the white fence white. Using our IMXMLObject and the dispatch event technique that I described above gives us the perfect vehicle to dispatch our events. IMXMLObject interface defines the following method
function initialized(document:Object, id:String):voidpublic
We can then use the document object to dispatch our event into the proper context of where we want to dispatch it. Like I mentioned above, the document object comes in instances of objects we defined. From my previous MyPanel example, a non visual component that is implemented in mxml would get a document named something like MyPanel0 or MyPanel1. As long as we have an instance of MyPanel we can add our listeners to it.
In most cases, I just use the EventManager class to dispatch to the proper context. Rarely do I actually listen through it, but it’s there and can be handy.
I’d like to point out that this is by no means a substitute for the built in event lifecycle. It’s important to use this technique only when is necessary. And be very afraid of global events. Like most things global, Global Variables, Global Constants, Global Singletons, Global Warming, they can be very bad, if you don’t believe me, just ask him.
I’ve included a sample application demonstrating some of these techniques with links below. There’s also some more of my value object techniques I’ve been demonstrating, like setting a value object by passing in a form or xml and some other techniques that make app building simple, but I won’t get into detail on them unless someone asks or I run into one of these.
Here’s the demo: I left traces everywhere so you can download the app and run it.
I grumbled about the refactoring time I was experiencing when trying to rename a file in this post. It was pointed out to me that if i uncheck “Update References” and click “Preview” that Flex Builder doesn’t attempt to find and update references. duh?!
Anyways, that makes things a little easier on me. It’d be nice if that was the default however. Perhaps, I’m just the only one out here in Flex Builder land that doesn’t get the file name right the first time. That’d be kinda scary if that was true, but not as scary as this.
Regarding my post here about how to use a base value object, a reader writes:
That’s all well and good, but my data is very complex and is returned to me in an xml hierarchy structure with nodes and subnodes etc., and while your solution allows me to easily create value objects, I still have to pull my data out of the xml so your base value object doesn’t gain me much and it’s easier to bind to xml using e4x.
e4x does rock. I have to admit. My example was just a simple how to solution. I would never try to create a one size fits all solution, and some of your reasons validate my assumption on this:
“my data is very complex and is returned to me in an xml hierarchy”.
Just for the record, my data is all very complex and comes from multiple data sources, such as xml, oracle, sql, webservices and the occasional flat file. Like a lot of people I only have so much control over how the data is returned to me. But from that point on I do have control over what happens with my data, which is why I opted for using value objects instead of xml. It’s just as easy to turn xml into a value object. An example of this is below.
That being shown, I have a few more tricks to set complex data. First, in cases where you have two value objects that have a one to many relationship, it’s quite easy to pass in hierarchical data and and automatically set sub data. This can be accomplished by using getter and setter functions. Consider the following: I have a list of users, and those users have a list of roles. My UserVO looks like this:
I’m using a getter to make sure all my roles are properly typed. This is really effective with xml, where as you are looping over children nodes, and you get to a subset of data, in this case <roles> it passes that node in to the roles array and the getter makes sure everything gets assembled.
The other thing that i’m doing with this UserVO is that i have two getters in here that are more about convenience than anything else. I have a label getter which I’ve already talked about here and also i have a getter named children, which represents to controls like the tree what data I want to represent the children or sub nodes. I can create a bunch UserVO’s and pass them to grids, trees, etc without worrying about what’s getting displayed by default, and if I need to I can always overwrite the label and children in the actual implementation. In essence I’m using my value objects as my Data Descriptor. I’m not sure if the flex guys had this in mind when they built the data descriptor classes, but I find for even the most complex of scenarios where I have several complex value object chains representing data, defining them this way sure does make my code alot cleaner and easier to maintain. I never have to code for different data scenarios where i might have an xmllistcollection or an array collection, I just always convert data into something I can control, which are value objects.
Here’s a quick example. As always right click for source.
After some very encouraging remarks from Ark on this post I decided to make my Titles as boring as possible so all the left brain people in the world ( read about them here ) can understand me. If you want to tune out now now I’ll understand.
Or not, I’m really just interested in blogging about technology so I’ll keep to my thought and talk about using a Base Value Object . One of the things I never do is set individual properties on objects. I should be able to pass them an object, and they should know how to set themselves. I demonstrated this with that horribly named post here, and I wanted to follow up that post with the technique I use to create value objects.
The concept is as follows: You have a lot of different value objects and no matter what you throw at them they know how to populate themselves, so that whether it’s an object returned from the server or it’s a selectedItem from a DataGrid the call to create a new value object should be the same. for example:
var
user : UserVO = new UserVO(selectedItem);var user : UserVO = new UserVO(event.result);
My UserVO looks like this. Notice it passes the args to the super function, and it’s only responsibility is to define what it looks like.
public
class UserVO extends ValueObject{
public function UserVO(args:Object=null)
{
super(args);
}
public var name:String; public var email:String;}
And finally my Value Object that does all the work.
public
class ValueObject{
public function ValueObject(args:Object=null):void
{
setVO(args);
}
public function setVO(args:Object=null):void
{
if(args == null)
return void;
for (var key:String in args)
{
// for some reason mx_internal_uid gets in the way. if (key != "mx_internal_uid" && this.hasOwnProperty(key))
this[key] = args[key];
}
}
}
My base value setVO function is where everything takes place. You can make your objects dynamic and take out the check for hasOwnProperty(). Also, Examine the type of the args passed in to the setVO function to make it possible to pass in xml, or arrays, or any other sort of data type, I took out my checks for the purpose of brevity.
Well hopefully this post was drab enough to win over Ark. If you’re still in the mood, check out this.
brian..
I just voted for my the bugs I'd like see fixed in for the next version of flex. If you haven’t done so you can learn more about it here. One of the bugs I did not vote for was the ability to have a data provider ( although that’s not what I’ve been calling it) for a form. Not because I think it’s a bad idea, but only because I already have a component that will do this very thing. So I threw together this app with an implementation that you’re welcome to download and use. Before I get into specifics, though, I’d like to say that I don’t think the concept of a dataProvider is appropriate, even though, apparently that’s what it’s being referred to in the bug and on flexcoders. I think what the form really needs is ability to set all the controls in it on the one side, and get all the values off the form on the other side.
Anyways, the idea behind this is simple. I implemented an interface called IFormControl that allows me easily set controls. For every form you want to include in a form you can implement the interface. I’ve implemented simple controls in my demo, and the demo is actually a very scaled down version of what I actually use. But if you want to know where you can go with it, think about what it would take to place a data grid in a form control and pull off the appropriate values. Also, think about how you would use remoting to submit the form to your server, return either a Great Success or a Great Failure.
You can view my form control demo here.
If you have any questions, feel free to email, post comments or nothing.
brian..
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 |
Recent Comments