Software, Fitness, and Gaming – Jesse Warden

Category: Flex

  • Flex Chronicles #17: PopUp’s in a Modal PopUp

    Flex 1.5 (and Flex 1, and Flash 8, and Flash MX 2004) have a class called mx.managers.PopUpManager that allows you to create modal windows. You don’t have to make them modal, but modality ensures that users handle the interface you’ve provided for them first and prevent them from doing anything else until they have.

    The problem is when you open multiple popups that are modal and have the same parent. A preferences form for example could be opened in a modal popup window which in turn launches another modal popup. It uses very low-level ActionScript to create a “mouse shield” that prevents user mouse clicks from activating anything behind the popup. This ensures that the user can only click on whatever is in front of the shield. Others have found that some keyboard presses can get through, but it’s rare enough to not be a problem.

    The problem here, however, is if you have a component in the 2nd popup that utilizes it’s own non-modal popup. Since some components, namely Panel’s and TitleWindow’s use a shadow that’s actually created in 1 depth below them in their parent’s drawing stack (timeline), the PopUpManager’s modal code compensate’s for this and moves the modal mouse shield 2 depths lower to give it breathing room. For some reason I can’t pin down, nor care to at this point, additional non-modal popups are put behind this lastest shield. So, in the case of a ComboBox for example, the popup list will appear behind your form AND the modality (mouse shield).

    My hack, after it creates the custom List component in a popup (think auto-complete field), is to have the component check if the parentDocument’s deletePopUp method is not undefined. If it’s not undefined, it’s a popup. If it’s a popup, I need to move my newly created List popup up 2 depths higher than the parentDocument that houses it. This works like a charm, but is a hack, breaks encapsulation, and might not work if she’s deeply nested in more than 1 level of popups.

    If you’re popups start appearing behind the modality, and you’ve ensured you’ve positioned them correctly, try swapping their depths to something at least 2 higher than their parentDocument.

  • Sessions with Flex and Flash

    I’m looking for corroboration, confirmation, and/or corrections, so if you got ’em, throw ’em in the comments please and I’ll update this post.

    The more popular Flex and Flash gets, the more exposure I get to large server-side development teams. As most have developed a lot of web based applications, the question of session handling comes up time and time again. I’ve attempted to compare and contrast the current known methods for utilizing sessions in a web browser, and their parrellels with Flex & Flash development. My goal is to better understand why you do or do not need session handling in your web application.

    In this post’s context, a session is defined as a way to uniquely indentify the client to the server. Since normal http interactions are stateless, there is no way for a request from the client web browser to the server to be uniquely identified. Where such situations are needed to know which client is which, and keep data associated with that client while they are interacting with the web application, a sessions is used. The real-world example is keep a list of items a user has added to their cart in an ecommerce site. Even if they go from page to page throughout the site, or back, the session keeps track of their cart items.

    The three main ways to do this are:

    1. appending variables to the URL string
    2. hidden form field
    3. cookies

    The first way involves appending variables that are relevant to the web application state to the end of the URL and making sure each page continues to attach this information along as well. Hyperlinks may add &id=234890somerandomnum&cartitem1=someproductid to the end of the URL when travelling from page to page. The server-side code garner’s context, if needed, since these variables are passed to the server before processing the next page. The pro’s to this is you can easily see what variables are working during development, and this allows you to tweak your pages to test things while using the app. The cons are unweildy URL’s that are extremely long, if you miss passing one variable the whole thing gets fubarred, and harder to secure (assuming your methods handling the server-side variables don’t check for arbitrary data which they should).

    The second way involves sticking a session ID or even additional vars like the above into a hidden form field(s).

    The third way involves utilizing cookies that store session information. Pro is this is very application transparent for the front end, but the con is if cookies are disabled, it won’t work.

    My take as to why server-side developers like sessions is that role information is encapsulated into the request. In the case of AMFPHP for example, each server-side method in a PHP class has a role or set of roles that are allowed to call it. Upon logging in using normal browser security, you’re role is set. This provides transparent interaction between client and server. You can even handle a custom fault of not having the role privaledge to access certain functionality, or even “re-login” if need be without refreshing the page. I guess I don’t understand where this persists, though. J2EE has a similiar setup with a nice, built-in security that works.

    The state arguments, however, make no sense. It is understandable since it requires a lot of effort to work with the developers to get them out of the “page” mindset. There is no page; it’s an application like Outlook; it has state, and doesn’t lose it. There is no page refresh.

    I once worked on a Flash app where in using OpenAMF, the Java guy wanted me to pass him the session ID as the first parameter to every method call. I’d login, get the sessionID as a return value, and set it to a global (static) variable in the Flash app. Every Delegate call pre-pended this value as the first parameter to method calls. It wasn’t so bad, but I never really understood what the session gave us.

    The hidden form variable works similiar to the above; you just store whatever variables you want to keep around in a global/static class.

    While Flex & Flash have their own cookies, they are used for ensuring data persistence across application usage, not sessions. So, if I reboot my computer after using an application, the data will be there tomorrow type of thing. They are for data storage. Just like browser cookies I guess, only harder to delete (harder meaning not built into web browsers like cookies are).

    The current Flex & ColdFusion app I work on, we don’t use ’em. The Flex app keeps state, and just calls ColdFusion CRUD methods. I’m sure we could add roles if need be, but I guess I just don’t get it beyond the built in security some server-side technology has to authenticate requests.

    I’ve never really found a definitive article explaining the session’s role in Flash & Flex development. I’ve seen it discussed more on Flexcoders, but this is mainly because of the influx of server-side talent on that list who is used to dealing with such state. The typical response is “you don’t need them, Flex is a stateful client”, and yet the “logging in” is still discussed. If anyone has anymore sources to add to the above (or correct), please link.

  • Passing ActionScript Classes to ColdFusion via Remoting

    Something I just found out today is you can pass ActionScript classes to a CFC method via Flash Remoting. I was under the impression that this only worked in OpenAMF, AMFPHP, and Flash Remoting for Java. I have publicly stated in the past that it cannot be done, and I was wrong in doing so.

    Typically, the structs I get back from ColdFusion are either objects with properties that have uppercase names, or arrays of structs. I write Factory code in either Flash or Flex, ARP or Cairngorm, to convert these transfer objects to value objects which are basically ActionScript classes that match their CFC counterparts, property for property. This is done so both I and the server-side developer can be on the same page when we discuss what a “Person” really means. If we both have a class that has data for the person defined in properties in our respective languages, it allows us to communicate effectively, both in code and over the phone, email, and IM.

    A lot of time is spent writing Factory code, and is one of my frustrations with using Remoting with ColdFusion. OpenAMF isn’t any better if you don’t have a Java guy with Flash Remoting and/or OpenAMF experience. While your VO’s may technically work, you’ll spend weeks configuring it. AMFPHP just works.

    However, as of today, I found out you CAN send ActionScript classes instead of just plain Object’s to a CFC method as long as you do 2 things:

    1. Wrap it in an Object with 1 property. That property must be named the same as the cfargument tag
    2. Make a deep clone of the VO you are sending back

    If your CFC’s cfargument tag looks like this:

    <cfargument name="someVO" type="struct" required="false" default="" />

    Then you’re service call in ActionScript looks something like this:

    var clonedVO:SomeClass = myVO.clone();
service.method ( {someVO: clonedVO} );

    Notice how the someVO matches the cfargument tag’s name. The first part makes sense, but the clone still baffles me. Regardless, it works, and cuts down on 40% of the time I spend writing Factory code to transpose ActionScript value object classes to plain old vanilla objects.

    This post is irrelevant with Flex 2 and ColdFusion > 7.0.0 since Remoting works like you’d expect it to (at least, from what I’ve seen in the demo’s, haven’t played with Mystic yet).

  • How to trace every remoting call without ServiceCapture

    This isn’t a replacement for ServiceCapture; it should definately be used when you are doing some serious debugging between your client and server (or HTTPLook which isn’t as good with AMF traffic). However, if you have your own debug window, or just want another way to do it all in Flex 1.5, Flash MX 2004, and Flash 8, here’s how:

    import mx.services.Log;
import mx.remoting.Service;

private static var contructedApp:Boolean = contructApp();

static function contructApp()
{
        Log.prototype.onLog = function(message:String):Void
        {
                trace(message);
        };
        _global.mainLog = new Log(Log.DEBUG, "mainLog");
        Service.prototype.log = _global.mainLog;
}

    I believe that’ll show HTTPService calls for Flex 1.5 as well. Naturally, you can route trace in the onLog to whatever you want, or even use a Delegate to have the onLog function point and/or do something entirely different.