Software, Fitness, and Gaming – Jesse Warden

Blog

  • ARP: Controller vs. Glorified Hashmap

    Good discussion over my blog that spilled to email with Grant Davies. He did a coup de grace whilst I drank watered down coffee on my ARP mods. He called my modified ARP Controller a glorified hashmap, and he’s right.

    The Controller in ARP responds to events made from View’s, and runs Commands when those events happen. You click the Submit button, it dispatches the click event. The Controller is listening for the click event, and runs the Login command. Your atypical MVC Controller; listen to events, trigger code to respond to those events.

    I’m faced with a challenge which I’ll probably solve while writing this. Since my changes, the Controller is no longer a controller in the traditional sense. It merely holds command classes in a hashmap (ActionScript Object), and allows you to run them (instantiate the class, optionally passing parameters). That is not a Controller.

    To reiterate the reason I did this to give some history and context, I felt that when writing dispatchEvent in my View’s, it shouldn’t imply anything. To me, event names are spur of the moment, just like naming variables; “What should I call this that’ll make sense, fall more to the verbose side vs. the brief side, and overall make sense?” In ARP, however, this choice carries with it the addition of knowing this event may eventually end up being mapped to calling a Command in the Controller. I didn’t like this, at least for those high level View’s that would be considered emitting system events. Granted, you wouldn’t have to worry about a Button’s click event triggering a command, but your Login component could trigger a command by its click event.

    Peter Hall and I had Aral note our distress, and he in turn suggested we use handleEvent which would allow us to intercept any events and do the mapping ourselves if we so chose. Since handleEvent is called before the actual event on an event listener using EventDispatcher in Flash/Flex, it’s a nice, low-level way to get more control of your events.

    At this point, I may have to re-examine that as an option.

    Typically what I’ve been doing is making an Application class; whether extending my ApplicationTemplate, or Flex’ Application.mxml. This holds all initial logic to create the main GUI’s, who in turn holds all other View creation/destroying, and manages listening to events and running commands; in effect, it’s a Controller and a View in 1; not so strange in Flash. Many purists do not like doing this since a Controller should be a controller and just a controller, and I understand perfectly why. ARP being lightweight enough allows me to bend the rules to my liking.

    However, I don’t think I can bend word definitions however; Controller is no longer such, and without multiple inheritance, I cannot have mx.core.View & Controller become one and the same without using an mix-in which most people, except me, hate.

    …ok, that didn’t work, writing it out didn’t solve it. Perhaps if Controller extended mx.core.View instead of Object, I could use it as my base View/Controller class since most of my apps are Form based anyway, this would work out well. Back to the lab.

    Community input, rocks!

  • Riot for Laptops

    Violence blows, but it makes my heart feel good to know people REALLY want technology. I’d be insulted if someone gave me a 4 year-old iBook; that, to me, equates to a pimp looking paper weight, but then, I’m a spoiled rotten geek. Hey, at least I’d say, “Thank you! That is so kind of you to think of me.” And I’d be sincere, too! I mean, how cool would it be to have an iBook beer-coaster? WHO’S A YUPPIE, NOW, SUCKA!?!

    My favorite quote:

    One woman went so far to wet herself rather than surrender her place in line.

    Panic ensues in rush for cheap laptops

    Via her majesty.

  • Screenweaver Goes Open Source

    To quote my manager, “HOLY [edit] FISH!!! Edwin van Rijkom LIVES!”.

    Before there was mProjector, before Zinc (formerely Flash Studio Pro) was yum, there was Screenweaver, and man was it cool. It had callbacks to ActionScript functions so if you wanted to read the local file system, you got a callback when it was done with an array full of folder and filenames. Cool stuff like that in a nice and comprehensive API. The best part was that Screenweaver was used to create Screenweaver. Good stuff! Then it “fell asleep“.

    To quote the post:

    “…After I had a little chat with Darron a few days back, I’ve
    been working on bringing the Screenweaver 3 code base up to date: I’ve
    decided to release it open source.

    Under the same licence (GNU GPL) I will also release a new development
    effort called Screenweaver Core. This might be of specific interest to
    this list due to the open architecture. Read more about it here.

    I’ll need about one or two weeks to get everything organized properly,
    after which both projects will be available through OSFlash.

    Cheers,

    Edwin van Rijkom
    http://www.vanrijkom.org…”

  • Coding Challenge vs. Reasonable Gain

    I had an epiphany this morning in regards to a piece of functionality I’m developing at work. I like to challenge myself, and I find tackling really complicated forms satisfies that need. I have to not only meet the business requirements of saving the data to the pre-determined data model, presenting the forms in a useable fashion so the user feels like they are real forms, but also integrate some of the features Flex/Flash have into that old format.

    Forms are typically presented in a linear format, and each filled out form is submitted, with either a success or error, very wizard-like. With Flex/Flash, you have a bunch of added benefits. Flex automatically handles the tabbing (where it’s a pain in the neck in Flash), but both allow ALL data to be saved and created into the data-model in real-time with the added ability to hand that data model off to the server-side in something it can easily understand without the page refresh, something AJAX currently cannot do without a lot of overhead parsing. You can cache the data locally in case occasional/disparate connectivity is an issue, and post later if needed, just like cookies are used in HTML forms, but with the added feature of treating it as a native object; something more easily understood with no parsing required.

    Where things really shine, however, is the ability to more easily and quickly create a GUI that matches the designer and architect’s idea of how the interface should be and work. And there-in lies the problem. We developed a really powerful way to obtain some very complex data from the user, which thankfully, they will know ahead of time what type the data is, how it will be viewed, and will have preconceived notions about the verbage of how that data is displayed. This is great because it makes meeting those expectations in the GUI easy, and the client can more easily enter in data the way they want it to… which is why the whole CMS business pays my salary, regardless of employer.

    …however, that’s also the problem. Because things are so easy to match, visual designers are given more leeway in their UI, and do not have to worry about technical restraints as much. “Will this design be able to render friendly and degrade in a variety of browsers? Will my vision of how this is supposed to work really be achievable by the front end and back-end developers?”

    Naturally, being who I am, my resounding answer is, “BRING IT ON!!!”. And that was my downfall. Give me enough time, and I’ll code anything. Granted, I can see pointless endeavors such as trying to get Flash 7 to render 10,000 records in a DataGrid, even if that means re-writing your own DataGrid. What’s the point? There are more powerful ways to display data than just dumped in a DataGrid, and technical ways to cache and page the data. But as you just read, I still attempted to solve it in a more pragmatic way. Can Flash Player 7 display 10,000 records at a reasonable speed on a reasonable target platform? Yes. Is it worth doing? No.

    I have a form at work that is a base class for a bunch of other forms. In 90% of the use cases, it works great. Dynamically allowing the user to create as much data as they want, to be able to scroll through and edit that data quickly is really powerful and makes me proud to create such things with my fellow developers.

    However, there is one niche case where it is being pushed beyond a simple form. The data is so complex, that you start to get into a forest for the trees complex. Making a simple, multi-form base to work with extremely complicated forms, each having extremely deep and nested data is a challenge upon itself. And herein lies the divergence: You can either succeed on the fringe use case, and have an extremely powerful way to enter and display complex data for creation & editing in the CMS, or break it down in smaller, more manageable chunks, which will take less time to do, but have less emotional impact. Both satisfy the same overall goal of CRUD operations (Create/Read/Update/Delete), but the former is extremely impressive, showcasing the best of what Flex/Flash have to offer where the later barely beats HTML.

    However, there are 2 key factors here which are now abundantly clear; if you satisfy the goal in less time, does it really matter? Yes, we have the potential to really knock this specific piece of functionality out of the park, scoring a homerun impression. However, at what cost? Could we get a lesser effect within an extremely more reasonable timeframe? Yes.

    Bottom line, a “well done” for 1 weeks’ worth of work is better than a “NICE JOB!!!” for 4 weeks worth. We as Flex/Flash developers are already showcasing the cream of the crop in form based applications. The temptation for those who are ambitious as well as perfectionists to not only impress the client, but blow them out of the water has a cost. Hopefully I’m getting more pragmatic, or maybe it’s just cynical, but from now on, I’m shooting for what is awesome, but immediately body checking those expectations with the time cost. Does that extra week gain the client anything? Yes, I’m extremely proud of myself after 2 weeks instead of 1, knowing that that extra week paid off in the architecture, but did it pay off for the client, and ultimately the end user?

    Translating my time’s development cost, the time estimations for each projected functionality goal, and providing optional solutions is tough, even more so when trying to suppress my natural developer’s urge to “make it cooler”. I guess this is why they call it “learning”.