GitHub Transition

I’m going to be moving all of my widgets and code to GitHub public repos shortly. I’ll go back and update the posts as they’re migrated. Please feel free to fork to your desire :)

Posted in Development | Leave a comment

AutoComplete.js update 1.2

I’ve completed an update/rewrite of my AutoComplete (Google suggest) widget. It now also includes a complete API document similar to the HelpBallons API.




As always, please let me know if you have any issues or suggestions.


Posted in AJAX, Development, JavaScript, PHP, Widgets | 39 Comments

HelpBalloon.js version 2.0

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. (However, if you want to use different Scriptaculous effects than the standard Fade and Appear, you can set the hideEffect and/or fadeEffect options to whatever you want… Doesn’t even have to be Scriptaculous, just Scriptaculous-compatible)
  • 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, and scriptaculous 1.8.1) 556k zip.

Or you can get the latest via GitHub:

Click here for the API Page

Click here for the Example Page

Update: I’m right in the middle of adding new feature documentation, so the docs are a little wonky. I’ll fix shortly.

Posted in AJAX, Development, Widgets | 179 Comments

Flex 3, Flex Builder 3, and AIR 1.0 Released!

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

Posted in Development | 1 Comment

Using Flex Modules to Load Dynamic Applications at Login

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)

Posted in Development, Flex | 18 Comments