2 Replies Latest reply on Aug 14, 2009 10:28 AM by bringrags

    Too many private methods, constants and variables


      I've been trying to extend some of the OSMF classes to add some custom behavior but I'm finding that way too many of the methods and variables are being declared "private". I'm finding it nearly impossible to not to copy and past code around or start changing declarations from private to protected.


      For example:

      • I want to create a VideoAdElement that essentially plays a video but needs to do an extra step before the standard NetLoader load process and otherwise behave idential to the the VideoElement.
      • Basically I need to change the 1st URL to a second midway though the load process and then call/recreate the behavior of the default load method.


      The specifics that I've run into so far are:

      1. 1st all the parsing methods of the URL classes are private and rawUrl is read only so extending a URL class to make it change inresponse to an event requires a bunch of changes from private to protected or the copy & paste of logic.  If you look at how the FMSURL class is written it is even doing an end around having parseURL() private buy adding more private parse methods instead of extending parseURL() and calling super.parseURL() or the like.
      2. 2nd the constants in the NetLoader are all pivate so when recreating the load method I have to adjust a bunch of declarations from private to public or duplicate a bunch of logic.
      3. Since load() is the entry point into the NetLoader and every other method in the NetLoader is declared private I have the choice of copy & paste or go and change things from private to protected everywhere.


      This makes things a lot harder then they need to be.  I can understand some methods being private but this is taking it to the extreme and makes most of the objects involved totally inaccessable to extension.  Flex has mx_internal namespace which attempts to address the need to abandon a method down the road which the need to be flexable and accessable.  At least as Flex is revised and I get a compile error on something overriding mx_internal I know where to look.  If I'm having to modifiy random method/variable declarations from private to protected every time I update the framework its a messy situation.


      I doubt I'll be the only one trying to extend the framework so it is probably better to address this need early then later on down the road after people give up on OSMF because it is too hard to extend.

        • 1. Re: Too many private methods, constants and variables


          The first item is exactly the reason for my earlier post on url parsing.  Given that I cannot extend the FMSURL class and override parsePath. In documentation it suggests you should be able to customize how the url is parsed. I however do not understand how this is to be accomplished.

          • 2. Re: Too many private methods, constants and variables
            bringrags Level 4

            This is great feedback for us to get.  Let me start with some high-level stuff, then I'll address the specifics of your cases.


            There probably are places in the framework where certain methods or properties ought to be exposed to increase configurability.  The way we'd like to address these is to focus on specific use cases that can't be solved within the framework (and thanks for providing some), but which would be made possible by loosening the access specifiers.  In general, when making a decision between public vs. private where no specific use case points one way or the other, we are always going to err on the side of making things private.  Every method that is public or protected will need to be supported now and forever (*), whereas private methods can be removed, refactored, etc.  The smaller the public API, the more flexibility we have to change implementation, restructure code to improve performance, etc.  If we can address your use case without having to expose a larger API surface area, then that's the best of all words since we can retain that flexibility going forward.


            To your use cases...


            VideoAdElement:  This type of use case ("decorating" a MediaElement to augment or modify functionality) is a common one, and we've come up with a specific approach for this type of problem involving the ProxyElement class.  The basic idea is that you can wrap your MediaElement in a subclass of ProxyElement, and layer additional functionality on top of the MediaElement via the ProxyElement subclass's implementation.  To the client of the ProxyElement, the behavior is the same as if they were working with the wrapped MediaElement.


            For example, you could create a VideoProxyElement which extends ProxyElement, and which wraps VideoElement.  When a client attempts to load the video (via the ILoadable trait's load method), your VideoProxyElement can intercept the call (by overriding the ILoadable trait) so that it gets a chance to rewrite the URL before the video's load begins.  I've attached a ZIP file that demonstrates this:  it has three classes, but the one you would use is VideoProxyElement.  VideoProxyElement automatically rewrites the URL to point to a different one (in my sample code, a progressive video on Akamai's network).  If you were to assign a VideoElement that had a stream URL:


            mediaPlayer.media = new VideoElement(new NetLoader(), new URLResource(new FMSURL(REMOTE_STREAM)));


            Then this would (obviously) play the stream.  But if you wrap that VideoElement in the VideoProxyElement:


            mediaPlayer.media = new VideoProxyElement(new VideoElement(new NetLoader(), new URLResource(new FMSURL(REMOTE_STREAM))));


            Then the MediaPlayer will play the progressive video rather than the streaming video.


            The neat thing about this technique is that you can define a ProxyElement that does any sort of preflight activity you need, without having to touch the underlying VideoElement.  The functionality is simply layered on top.  And (as we'll demonstrate in our next release), you could include VideoProxyExample in a plugin so that the player doesn't need to know any of the details (it just needs to load the plugin up front).


            Hope this helps,




            (*) Once we commit to being backwards compatible, which us unlikely to happen before the version number approaches something much closer to 1.0.