I'm glad to see this alive again. I had worked closely with Darshan in the past on Fabrication, but when he "disappeared" I ended up abandoning it's use because I didn't have the time to take it over myself.

I'm currently starting a new project and this will work nicely into the project. Thanks for picking it up again. I'll try to help out again when I can.

I'm pretty sure this project is dead. It should probably be removed from the forums. It's too bad, it had a lot of promise. I haven't seen Darshan in almost a year and his blog is silent too.

You can use addChildAt(displayObj, 0), that would put each new item at underneath the others.

If I could make one small request, please ensure the template are editable Or, if possible, allow for creation of custom templates in addition to the defaults

I may have misunderstood the issue. I thought the issue was he had overly complex handlers (ie: trying to do way too mcuh per handler), not too many handlers in general.

There isn't one, to my knowledge. Though it would be helpful.

I kind of cheat a bit and use templates I created in FlashDevelop. I generate them when needed and then pull them into FB. It's a bit clumsy but it works. A plugin for Exclipse would be awesome, but I'm not the right person to write one (not a java guy).


there is also this ruby/ant thing http://blog.smartlogicsolutions.com/2008/12/05/introducing-puremvcgen-an-ant-based-puremvc-flex-generator/

If your mediators are getting "out of hand" then you are putting too much logic into your mediators. You shouldn't be putting more than simple "get" and "set" calls in your mediators. Anything more complex should go in a command. It sounds like you are over extending the mediator to pefrom tasks it is not meant to.

As Cliff has stated before, the mediator handleNotification method is constructed in such a way that it acts as a kind of snaity code check. If you find it's getting unwieldy, then it's a sign you are trying to do too much and need to refactor.

Flex Builder (Flash Builder)?

This is a known Flex bug in 3.4. The nightly build of 3.5 fixes the issue. The early beta release used 3.3. The bug was introduced in 3.4.

Temp Fix: http://www.webappsolution.com/wordpress/2009/09/29/workaround-to-flex-sdk-34-bug-22333-httpservice-responders-are-called-twiceheres-a-fix/


Bug: http://bugs.adobe.com/jira/browse/SDK-22333

Thanks for your reply!

I have developed several video players myself in the past, ranging from simple to more complex players that integrate an advertising model.  I also have a client that is interested in a "Media" player (video, audio, image, swf slideshow), that could provide the functionality that OSMF has set out to accomplish.  So, I do see a need for this type of player.  However, I may not be as knowledgeable on the inner-workings of the OSMF framework as yourself, and would love if you could elaborate more.

Our media player also plays all of those formats, including panoramas. I guess I just don't see myself replacing our framework with theirs anytime soon.

I didn't care much for what I saw at Max 2009. I actually walked out of the lab halfway through because the guy doing the lab didn't seem to even understand the framework himself (perhaps that was part of what turned me off of it). He kept yelling to some developer at the back of the room for every question and half the demos he had didn't work. But, keep in mind they've only been actively developing it since the summer so it may be too soon to tell.

My fear is that it will end up much like Flex and other Adobe frameworks, enormous in size! I don't know about you, but my company has strict limits on the file size for our players. They need to load quickly. I fear that things like advertising will be so mixed in with the other media classes that even if you don't need/want the advertising stuff you're going to get it anyway.

My suggestion is to take a weekend and play with it.

I can't see Adobe abandoning this project anytime soon, and it would seem wise to embrace this new framework than reject these efforts to create a decent standard.

I think the OVP project is perfect for getting a standard player architecture out there for the average Flash hacker to use. On the other hand, I think building a heavy framework around processes that are likely to be very different  company to company, a bit much. Anyone building high end, high volume, media players is going to have their own framework (Brightcove for example).

All this will likely do is flood the market with many low end products. WHich I'm sure is great for Akamai since their conneciton classes will be the main part of the framework. What better way to sell your services to the masses than to build a framework around Flash Media Server (Adobe) and your Edge servers (Akamai)? Tons of little comapnies will slap a UI overtop the framework and start claiming to be media distribution companies all paying monthly fees to Akamai for FMS and bandwidth. I don't find it to be any accident the two main companies behind the framework both have vested interests. It's less about standards, more about sales. Make it so easy to get going with their services that you ignore the alternatives. Brilliant really.

(And yes, we use Akamai  )

Again, this is all just my opinion so take for what it's worth. Time will tell.

I looked into it, as well as took a lab at Max 2009 on it, and in my opinion it isn't nearly polished/complete enough to use. It also seems to focus heavily on advertising, and obfuscating the inner workings of video playback, neither of which I cared for.

I have used bits and pieces of the Open Video Player (the connection classes for Akamai mostly since they provide our streaming and I didn't want to reinvent the wheel). Our main business is video playback so I much prefer to build the player myself. OVP is great if you're looking for a customizable video player for your own site and don't want to invest the time to develop your own.

They mentioned at Max that they basically want to merge the two projects together to provide one large media playback framework (just what we need, another framework). I'm not too keen on this cause inevitably, in Adobe tradition, it'll try to do everything in one large inter-tangled framework for which you'll have to include everything to just play a darn video. Why does my video framework have to know how to play/display a swf and Photo? And I really don't like the nesting of constructor calls they use to construct a video call.


</endrant>

Just remember to clean up any event listeners using the onRemove() function and it should be GC'd.

You need to give each INSTANCE of your mediator a unqiue name that corresponds to the component it holds. If you use a static NAME variable to name your instances then only one mediator can exists.

:

facade.registerMediator (new PageMediator ("My Unique Name", Page instance));

...

// inside PageMediator Constructor
public function PageMediator(name:String, viewComponent:Object) {
    super(name, viewComponent);
}


Or if your components already have a unique name on them you can use that as the name for the mediator.

:

facade.registerMediator (new PageMediator (Page instance));

...

// inside PageMediator Constructor
public function PageMediator(viewComponent:Object) {
    super(viewComponent.name+'Mediator', viewComponent);
}



The mediator is only concerned with events that require it to perform some other request. It may be to get data from a proxy and set it on the component,  or to send a notification that accomplishes some other task (via a command or some other mediator listening for it). The rest of your views should send and recieve events as they normally would in any none "frameworked" app. You don't want to route everything through the mediator, only things that require some action to be performed by other PMVC actors (Proxy, Mediator and COmmands).

The best way I find is to have a view/component that exposes public methods for feeding data into the sub components. Then have a mediator mediate that component. This allows you to keep the inner workings of the child components encapsulated within the view component.

Of course, if your main component becomes really big, or a sub component is a candiate for being mediated on it's own, the main component mediator can create another mediator to handle that sub component by passing the child into the viewComponent param of the new mediator.

Okay, so once I have my custom panel class with all the gadgets ready for action, I want my view to inherit from this panel class. Is this the best way to go? In all the examples I've seen so far (not a whole lot), the view always inherits from Sprite. But it's okay for the view class itself to inherit from another class, right?

The view component can extend, or be, any valid decendant of DisplayObject (Sprite, DisplayObjectContainer, MovieClip etc).