Over 10 years of community discussion and knowledge are maintained here as a read-only archive. New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC
|
|
|
Show Posts
|
Pages: [1] 2 3 ... 17
|
1
|
Announcements and General Discussion / Fabrication / Re: Fabrication 0.7.2 released
|
on: July 15, 2010, 08:39:36
|
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.
|
|
|
7
|
Announcements and General Discussion / Architecture / Re: Handler classes for mediators
|
on: November 12, 2009, 08:24:48
|
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.
|
|
|
10
|
Announcements and General Discussion / General Discussion / Re: Adobe Strobe or Open Source Media Framework
|
on: October 28, 2009, 07:04:56
|
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 ![:o](http://forums.puremvc.org/Smileys/default/xshocked.gif.pagespeed.ic.CrwtrNUjLO.png) ) Again, this is all just my opinion so take for what it's worth. Time will tell.
|
|
|
11
|
Announcements and General Discussion / General Discussion / Re: Adobe Strobe or Open Source Media Framework
|
on: October 27, 2009, 06:24:12
|
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>
|
|
|
13
|
Announcements and General Discussion / Architecture / Re: A Mediator How to control multiple components ?
|
on: October 14, 2009, 08:17:00
|
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); }
|
|
|
14
|
Announcements and General Discussion / Architecture / Re: What kind of events need to be handled by the Mediator?
|
on: October 01, 2009, 06:02:35
|
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).
|
|
|
15
|
Announcements and General Discussion / Getting Started / Re: Big Picture Question about Views
|
on: September 30, 2009, 08:59:50
|
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).
|
|
|
|
|
|