Have you monkey patched the Flex framework?

Have you modified the framework source for your own purposes on a production Flex application? If so I’d like to hear from you as we’re currently trying to understand where folks are making changes and the kind of impact they could have on applications with relation to our new cached framework strategy.

Please let me know the following:
1) What files (or at least what areas) have you patched
2) Is SWF size an important consideration for your app
3) Was patching really the only solution available to you
4) Are you comfortable creating RSLs

You can comment here or mail me: mchotin AT adobe DOT com.

11 Responses to Have you monkey patched the Flex framework?

  1. ekameleon says:

    Hello :)I have not patched the Flex framework but i implement for the moment an important model strategy in my applications with an important robuste event model implementation compatible AS2/SSAS and AS3In my opensource framework VEGAS (AS2/AS3/SSAS libraries) i have implemented a full event model based W3C DOM2/3 event model :)In Flex (AS3 framework) i’ve implemented a part of my AS2/SSAS implementation but actually the AS3 framework it’s really poor :)First, you can see my project in google code :http://code.google.com/p/vegas/And my event model tutorials to see the full implementation in AS2/SSAS(FMS) of my event modelhttp://code.google.com/p/vegas/wiki/VegasTutorialsEvents1) What files (or at least what areas) have you patchedI Have patched the EventDispatcher class with a custom EventDispatcher class :http://svn1.cvsdude.com/osflash/vegas/AS3/trunk/src/vegas/events/EventDispatcher.asYou can compare with the AS2 and SSAS version- http://svn1.cvsdude.com/osflash/vegas/AS2/trunk/src/vegas/events/EventDispatcher.ashttp://svn1.cvsdude.com/osflash/vegas/SSAS/trunk/src/src/vegas/events/EventDispatcher.ascAdditional Features :- Global EventListener (the eventlistener receive all events)- MultiDispatcher with singleton and channel references (important to use a global EventDispatcher reference with channel in FrontController implementation)- Auto remove feature in the addEventListener method- Delegate EventListener class to create a proxy EventListener- Use in AS3 eventlistener functions or EventListener interface( W3C implementation with handleEvent() method) ! Important in the FrontController pattern- Event queue feature : the events can be enqueue in the dispatchEvent method and dispatch after !- EventListener batch implementation- Implements a FrontController class to register eventlistener “controllers”- An ‘AbstractCoreEventDispatcher’ class who use an internal composition EventDispatcher reference… by default the reference is locale but i can change this reference with a global EventDispatcher singleton reference (selected by channel) see example “Global event flow with FrontController” :http://code.google.com/p/vegas/wiki/VegasTutorialsEvents_AbstractCoreEventDispatcher– Bubbling events with all EventDispatcher references and not only DisplayObject class (defines the childs of the EventDispatcher manualy)For me this features are very importants in the AS3 event model of Flex !! I use all this features in AS2 and SSAS it’s easy to develop my personal implementation but for the moment in AS3 if i want use my features it’s difficult to keep the native flash.events.* implementation inside of my patches.EKA+ 🙂

  2. Ian Fuller says:

    Hi,Something I’ve done a few times is import mx_interal – which you clearly shouldn’t, but it seems to be the cleanest way to access subparts of existing components (e.g. panel or button title) so that filter effects can be added.Ian

  3. zwetan says:

    Hi,it’s not directly related to the mx framework itself but more to the playerglobal.swcand yes this could have impact on caching too.would it be possible to split the core objects (ECMAScript spec) from the player objects and globals ?for ex: builtin.swc and playerglobal.swcNow it’s not really relevant, but at ES4 time and then AS4 time, I guess class as String that are final now in AS3will be changed to dynamic in AS4 (only the primitive string will be final), and thuspeople will surely want to add some missing methods to those core classes.I know I will and surely others will want to do that too.(note: and if the different compilers as compc and mxmlc allowed it I would have already done it)I can give more details about why/what I want to do such setup if needed.

  4. Ben Johnson says:

    I recently created a component that would display multiple calendars within whatever space was available. It basically worked like Outlook’s calendar.I wanted to subclass DateChooser so they would have the same interface and so that I could take advantage of the skinning and locale functionality. However, the CalendarLayout control within DateChooser used a lot of private methods and properties for selection and data management.Surprisingly my easiest solution was to copy the CalendarLayout to a subclass called CalendarLayoutAdapter and rename all the variables to have a dollar sign (“$”) prefix and change the access from private to protected. Then I just redirected all the public methods and properties to use my new protected methods/props.I think my biggest request would be that Adobe not make anything private in the framework unless it’s absolutely necessary. Considering it’s an open source framework, it really doesn’t make sense that anything be private. It makes it really hard to reuse some of the components.Also, I think unscaledWidth and unscaledHeight should be public instead of protected.

  5. Tom Lee says:

    I’m monkey-patching mx.controls.scrollClasses.ScrollThumb to increase its explicitMinHeight in the constructor. 10px is too small for best usability, and also for the pill-shaped skin I’m using. I use 20px instead, so that when the ScrollThumb is at its smallest size it is perfectly circular.So glad you guys are taking feedback from the community this way!! You deserve a lot of credit for your openness.

  6. Adnan Doric says:

    I already monkey patched FormItem.as as some key methods are private there (getLabelWidth() for example)I agree with Ben Johnson, you should make everything protected/public if possible as extending is really important in Flex

  7. Todd says:

    ProgressBar.I wanted to make my own visual effects and a lot of what I wanted to control was marked private in the base class. But, I guess this isn’t really Monkey Patching, but seeing this request reminded me that I needed access to a lot of the ProgressBar’s internals.

  8. 1) What files (or at least what areas) have you patchedI’ve been working a lot on the list classes and patching more as a way to learn and understand the existing architecture better.2) Is SWF size an important consideration for your appYES!!! SWF size is hugely important although, I’d trade a bit of size for some smooth scrolling and easier renderer implementation3) Was patching really the only solution available to youno, definitely not.4) Are you comfortable creating RSLsIt’s certainly not on the top of my “fun things to do” list. Documentation/Examples could certainly be improved.

  9. Peter Rendl says:

    I patched ModuleManager.as.I had to load modules from ByteArray, but UIComponent relies on ModuleManager to find out the module’s associated module factory during getClassStyleDeclarations().If the module manager does not know the loaded module, class style declarations won’t be loaded for the module and the components it contains.

  10. Mike says:

    Banana’s were rigorously spoon-fed to BoxDivider (mx.containers.dividedBoxClasses) for one of the key gripes already laid out: accessibility.event handlers should be at minimum protected Best Practices: Writing components with protected event handlers and composite components in general should either be internal or public.I had a need to use the divided box containers similar to a browser frame that can be ‘locked’ / ‘unlocked’ (ie user active) and specifying particular styles / skins to the divider itself in either of those modes.Not wanting to completely re-invent the wheel, I took a modified copy with the same package.class name but in a different source library to create an intentional collision/replacement at compile.The Menu component is another one that is guilty of this, and apparently with the guys at flexlib too. Sub-menu’s are not intelligently stage aware for layout/measure.

  11. Matt says:

    I am deeply frustrated by the amount of private variables within Flex, and echo the sentiments above; extending is very important in our use of Flex, and private variables really hinder the process.