BeauScott.com

I’ve completed my updating of my aging AJAX help balloons / tool tips / dialog balloons / whatever you want to call them.

New features included:

• Less library dependence. It’s still prototype.js-based and dependent, but no longer requires Scriptaculous nor the prototype “improvement” script that they previously used. You can optionally still use Scriptaculous if you want the sexy fading effects. Just include the scriptaculous.js file in your document and the balloons will detect it and use it, no configuration needed.
• Use any object as an anchor point. This was available in later revisions of v1, but I’ve solidified it’s support. Simply assign the anchoring element as the balloon’s icon property at instantiation. (See the example page for details)
• Anchor postioning control. This feature allows you to move the anchor around within your icon for fine-tuning the balloon’s display. (See the example page for details)
• Non-caching remote data requests. If you’ve ever tried to use v1 of the balloons with dynamic data, you’d know that once the balloon makes it’s first request, it caches the request result and would not make subsequent calls for fresh data. You can now force the balloon to make a fresh request before each showing using instantiation options. (See the example page for details)
• Fixed direction assignment. By default, the balloons will position themselves based on available realestate, but you can now assign a fixed direction using instantiation options. (See the example page for details)
• Still 100% free, now released under the MIT open source license.
• Better organized and fully commented/documented code. This was a complete refactor/rewrite of the code base, and I made sure to comment the code very thoroughly and try to explain my reasoning (or insanity) as best I could. In addition, I’ve written a proper API page, and have revisited the examples page.

As always, I’m eager to hear feedback — be it wishes, comments, praises or curses. Thanks to all that provided feedback on v1, it was tremendously valuable.

Click here to download the full widget (includes images, HelpBalloon.js, prototype.js 1.6.0.2, and scriptaculous 1.8.1) 200k zip.

Click here for the API Page

Click here for the Example Page

Adobe released Flex 3, Flex Builder 3 and AIR 1.0 tonight! Way to go guys!

Ted Patrick has some highly suspect blogging going on, posting what would appear to be the splash from the final build of Flex 3! He doesn’t say what this means, but one can make assumptions Very exciting stuff here!

I’ve seen a few people ask on the flexcoders mailing list about different methods of loading applications at run time based on a user’s login without navigating to a different URL. There are several ways of doing this using a ViewStack or view states to toggle between application views, using a SWFLoader to load in separate standalone SWF movies at runtime, or using a ModuleLoader to load in Flex modules at runtime, each based on a user’s access rights.

Using a ViewStack/states to accomplish this is probably the least desirable method, especially if your application is even mildly complex. In essence you’re just toggling which view is visible, but each view exists statically in the application at all times. This can cause your application’s file size to be quite large, and can lead to messy event registration and clean up and really complex view clean up logic.

Using a SWFLoader is a bit better with memory clean up and event management, but still isn’t the optimal solution as each of the modules that you download will generally be larger than they need to be because they’re standalone applications and include the overhead of classes already included in the loading application (frameworks, dependent libs, etc.). This will result in a smaller loading application, but when you factor in the size of each subsequent SWF loaded, the total application file size is substantially higher. It also can be a bit complex to manage the applications being loaded in.

Using a ModuleLoader (or ModuleManager) to load Flex modules into the application at run time is very similar to using a SWFLoader: you’re still loading SWF files into the application at runtime, but the difference is the size of the loaded files. Flex Modules are based on either mx:Module if it’s a component that interacts with the framework (view components generally) or mx:ModuleBase if it’s a component that doesn’t need to add things to the display list. This cuts out a lot of overhead as it doesn’t have to include all the application-related objects. Flex Builder also has a built-in tool to help define these modules for your project, making managing them very easy. (See Project Properties -> Flex Modules)

I put together a simplified example using this approach. It’s really just an example and doesn’t have much real-world implementation code, but it does show how to use runtime data to define your application’s behavior while keeping memory and download sizes at a minimum.

My approach involves using a component that consists of a ModuleLoader to load modules in by their package name (eg: “com.beauscott.examples.modules.Module1″), a global UserManager object that handles all login/logout event dispatching and related model information, and a series of 4 modules that are loaded per each users’ module access rights. Each user defined can have one or more modules permitted for their use. If only one is defined, the module loader automatically loads it. If more than one are defined, it will prompt you with a list of available modules to choose from (double-click).

It’s very rough and there may be better methods out there, but I hope this helps as a starting point.  I’d love some suggestions and feedback as usual

Click here to download the project and source code

Click here to see the live demo (you can right-click to see the source here, too)

I’m a little late in reporting on this, but Adobe released BlazeDS RC1 on Feb. 1st.

For those of you who don’t know what BlazeDS is, it’s a soon-to-be open-source subset of Adobe’s expensive LiveCycle Enterprise Data Services Suite. It’s more or less an AMF (pdf) service gateway for your Java application, with other features like http polling for messaging. In the past, if you wanted the speed benefits of AMF with your large-scale java application you had to use a third-party solution like GraniteDS.

Sujit Reddy G has put together a good side-by-side comparison of the two.