Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


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

* | |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / Public Demos, Tools and Applications / VideoSwipe: the revolution will be live-streamed, on PureMVC :) on: July 19, 2013, 10:06:33
I've just put a web-app live, please take a look I value your comments!

http://videoswipe.net/go/

Ben.
2  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 04, 2012, 03:07:06
Awesome. I've totally got it. Sorted.

Thanks Cliff and Tekool for all your feedback, HUGELY appreciated! My coding is really starting to kick ass :)
3  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 04, 2012, 09:05:17
I can see why a lot of people have moved to Flex, it looks like it takes a lot of the strain in laying out and managing your components. I hope all you Flex developers out there appreciate the headaches you've been spared! :)

It would be a very interesting challenge to implement a "view framework" in AS3 that allow the entire view hierarchy to be specified in a flexible XML-style format, cascading resize events down the tree. If anyone's interested in taking this on I'd be happy to contribute.

For now let me share what I've implemented to get this idea off the ground. I'll also hopefully summarise and conclude (?) the above discussion on view hierarchies and God objects.

Firstly, I totally agree with the God object problem. I never intended the stageView component to be aware of every single view instance down to the last button in the bottom right corner.
But it does need to know all the "top-level" components (cf the User List, User Form and Role Panels in the Flex sample) and be smart enough to know how these components might change in response to changes in application state.
In my app, for example, I have half a dozen panels which slide on and off the screen depending on what the user is doing. The panels are black boxes to the stageView, it cares not for their contents, but the panels themselves are under direct control of stageView (eg changes to their position, visibility and dimensions).

The PrepareViewCommand instantiates the stageView.
The stageView instantiates the top-level components.
The top-level components instantiate whatever they want, they must take care of themselves and their children.
The PrepareViewCommand also instantiates a stageMediator to mediate the stageView, and likely further mediators for the top-level components (via references exposed by the stageView).

So far, so good (I hope).

Now, to quote from your last post:

You mediate at different points along the hierarchy as needed.

So what if we want a mediator for a view component which is nested several levels deep into the hierarchy?
The stageView doesn't know about this component, it knows only of the top-level components.
1. Allow the PrepareViewCommand to "reach in" and grab a reference to the view component by descending through the view levels via exposed references at each level (bad OOP!)
2. Component fires an "I exist, mediate me!" event which is caught by the stageMediator which then creates the mediator for it (slightly bad OOP! stageView *still* needs to know what the component is in order to create the correct mediator for it. Besides, at creation time the stageMediator doesn't yet exist)
3. Insist that only the top-level components are mediated and decide that this is exactly the right level of granularity for mediation. Hmmm... would work, but the tail is wagging the dog here.
4. ???

I'll leave that question open, maybe someone can provide a better number 4...


And here's a simple Composite pattern that I implemented to handle cascading resizes:
:
public class XSprite extends Sprite implements IXSprite
{
protected var _width:uint;
protected var _height:uint;

public function XSprite(_w:uint = 800, _h:uint = 600)
{
_width = _w;
_height = _h;
}

public function setSize(_w:int, _h:int):void
{
_width = _w;
_height = _h;
redraw();
}

// redraw must be overwritten in subclasses
public function redraw():void
{ }

}

public interface IXSprite
{
function setSize(_w:uint, _h:uint):void;
function redraw():void;
}


View components now extend XSprite, and must implement a redraw function.
Calling setSize on an XSprite allows a new size to be passed in, and the overridden redraw will then be executed.
The XSprite can redraw itself based on its new _width, _height properties and in turn call setSize on its children.
It wouldn't be too much extra work to extend this further to implement such as things as "VBox" and "HBox" as per the Flex architecture.
4  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 01, 2012, 09:51:40


And sorry if I seem a little harsh in my answers, it's just that I'm really direct because English is not my native language.

:) think nothing of it! I prefer direct, your English is fine. Thanks again for all your help I really appreciate it.
5  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 01, 2012, 07:28:33
Ok, thanks for all your help and the ongoing discussion! I totally agree with the system of Notifications between Mediators. It sounds like its the Mediators that should be responsible for catching relevant messages relating to their view components.

I'm going to proceed along the following lines:

PrepareViewCommand:
instantiate view components
add view components to stage
instantiate mediators (all view components must be mediated at some level)
sendNotification( LayoutStart ) to set initial sizes and positions

LayoutStartCommand:
use stage width/height to determine position/size of all view components
retrieve all relevant mediators, call functions on them to set size and position of their respective view components

later, if user clicks 'full screen' button sendNotification( LayoutFullScreen )

LayoutFullScreenCommand:
use stage width/height to determine position/size of all view components based on new full screen layout
retrieve all relevant mediators, call functions on them to set size and position of their respective view components

... and I imagine creating a Command for each layout configuration which performs similar to above but using different size/position calculations.


6  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: November 01, 2012, 06:13:02

Keep this design, this is the right one. It is always better to initialize view components and their mediators (even if you initialize only one mediator for several view components) in a command. This the PureMVC way to manage dependency injection, using Mediator constructors.

I'm glad we agree on this :) I was very happy when I moved all the view component creation into a separate command. But this approach still has a problem that there is no central "manager" that holds any references to these components. A command to "GoFullScreen", for example, would not be able to access the view components in order to resize/reposition them.

...It would be better to have a dedicated Mediator for you group of MovieClips...
Isn't this effectively what a StageMediator would be? A dedicated Mediator for the top-level group of MovieClips?
There might also be other other Mediators that handle sub-components within the hierarchy, depending on how complex it gets, but at the top-level there would be a group of chunky components which require a mediator. Maybe ApplicationMediator is a better name? The group of MovieClips which represents the application.

When I say that a mediator can manage more than one view component I of course don't mean to place the whole app logic into one mediator. ...
No, me neither. The final decision of how many mediators will depend on the complexity and granularity of the overall system. I really meant that *any* logic should be moved into a command - which is difficult when the command needs to refer to a list of view components that spans the entire stage, and it is born with no immediate access to any of them.


This typically has to be managed by your view component itself, not even the mediator. ...
I'm not sure I agree with this. A view component can be responsible for its own contents, but it needn't/shouldn't be aware of anything outside of itself, such as where it is positioned on the screen. So layout considerations are something for an actor with a higher-level scope than the view component itself.
7  Announcements and General Discussion / Architecture / Re: Does anyone use a LayoutManager ? on: October 31, 2012, 03:12:34
Hi Tekool

thanks for your reply. It sounds like you are saying that the application needs some kind of StageMediator. This would be a mediator to instantiate and lay out a whole set of view components onto the Stage.

I originally designed my application in this way, but then decided that the entire view creation should be separated out into a PrepareViewCommand. I still use a StageMediator but this is now thinned down to be an actor that receives stage resize events and mouse and keyboard events and passes them on via Notifications.

If I were to move the view creation back into the StageMediator this would work, but it would also contain a lot of display logic. Decisions along the lines of "user has moved the mouse, so slide on the tools palette and - if user previously selected it via a checkbox in the settings - the status panel". This seems like a lot of logic to place inside a mediator which is, I thought, only supposed to catch events from the view and pass them back.

In summary then, I agree that a mediator (which holds references to all the various view components and takes full responsibility for their position, size and visibility) *would* work, but it feels like this is overloading the purpose of a mediator which is to be a lightweight actor.

Thoughts?
8  Announcements and General Discussion / General Discussion / Re: PureMVC with netStream / netConnection / Camera / Microphone objects on: April 18, 2012, 06:07:16
Hi

just wanted to say thanks for the thorough, and quick, response to my question - much appreciated!

I also want to add that I got down to work building an app using the puremvc framework with the help of your O'Reilly book "Actionscript Developer's Guide to PureMVC". I would wholeheartedly recommend this book to anyone using PureMVC. It has been next to my keyboard the entire time I've been coding and I find myself constantly referring to it and occasionally lifting techniques wholesale. Its been invaluable to me during this project. No connection with the author here, just glad to pay back with a good reference.

I'll almost certainly have more questions as I learn more, but in the meantime thanks Cliff for leading the way with this framework!

Ben.

9  Announcements and General Discussion / General Discussion / PureMVC with netStream / netConnection / Camera / Microphone objects on: February 25, 2012, 07:26:16
Hi

I read an old thread in these forums which said that basically netStream objects could be thought of as dataProviders to a video object, and therefore neednt be part of the Model but could be bundled into the view component.

I'd like to continue this discussion if possible...

I can see the reasoning behind the above. A netStream doesn't really contribute to the domain model, its just a platform-specific (and therefore non-portable) method of transporting data to the view tier. If this is the case and I understand it correctly, then what does this mean for the various other players in a video application?

Does this mean the netConnection is also part of the view? After all, its also platform-specific and tells us nothing about the domain model. In which case where should the actual netConnection object be created and where should it be stored?
To the netStream we also likely need to attach Camera and Microphone objects. These are clearly view components, but should they be created inside the stream viewer component? And for setting various options (eg camera bandwidth, microphone codec) should the view component expose those objects and let a command set the properties?
Maybe its better to create a WebcamVO object to hold these relevant parameters, and pass that VO into the webcam view component, in which case does this VO belong in the model since its just a convenient way to group together a bucket of numbers.

I guess if I can summarise those random thoughts into a coherent whole:
when using these built-in AS3 classes such as netConnection are these immediately good candidates to stay out of the model since they are necessarily platform-dependent? And more generally are there good rules of thumb to determine where object creation and storage should be carried out?

Thanks,

Ben.



10  Announcements and General Discussion / Getting Started / Re: what is the BEST way to instantiate mediators? on: July 01, 2011, 03:34:12
thanks for the quick and thorough reply!

maybe I can continue this discussion a step further:

of course I can see there is not a best way to do these things, every project is different and personal taste gets involved too. I've just noticed that (in our project at least) we come across a similar set of steps that need to be carried out:

create and register a proxy
create and register a mediator
instantiate a view

so I wondered if there was a recommended practice for this oft-repeated process. I browsed a few demo projects and didn't see a consistent approach (maybe there's a clue in there).

so if I can comment on the solution you proposed, here's what I notice:
1. commands do the work
2. two (or more) notifications might be usual, the command catches one and sends one
3. use a stageMediator to place concrete view components onto the stage

point 1 I can totally get behind, makes perfect sense

point 2 I can deal with, but it might take a bit of getting used to! I find it hard to follow notifications, when a sendNotification is executed you have to hunt around your source tree looking for the classes that are interested in that notification. I haven't found a system for doing this yet except for "search in files" and that feels wrong!

point 3 I can also understand and will use in this project. I was imagining a future scenario where we had twenty (or more) mediators and twenty corresponding notifications and twenty cases inside a long switch statement in the stageMediator. But maybe I'll find ways round this as the project grows (a generic "place view component on stage" notification?)

Finally, I noticed you created the view object in the command and then passed that into the mediator which is an approach I hadn't thought of. Thanks for that insight! In our case this is especially useful since the mediator can now mediate any video object, including other client streams, making the mediator far more useful. Thanks for that note also!

Looking forward to sharing more with the puremvc community in the coming months :)
11  Announcements and General Discussion / Getting Started / what is the BEST way to instantiate mediators? on: June 30, 2011, 06:33:00
Hi

first of all thanks to the PureMVC community for providing such a solid framework, I'm really enjoying getting my head round the new concepts.

My question is probably fairly typical, of the form "what's the best place to put code?" but I've taken a good look through the forums and demos and I'm still not clear so I thought I'd just ask for help.

I'll use our real project which is a Video Phone app, although I'm sure the steps are very generic.

So we have a NetConnectionClient object (Proxy) which receives calls from a remote server. One of these is a "doVideoCall" request which means that this client should begin a video call.

on a "doVideoCall" request we want to:
1. create a webcam model to hold all the info for streaming the client webcam, some of which is new and some of which we already have (eg name of this client, width/height of the video)
2. create a webcam view to display the webcam to the screen

here model = Proxy + ProxyVO and view = Mediator + viewComponent

this could be translated into the following simplified code:

var webcam:WebcamProxy = new WebcamProxy( infoObject );
var webcamMediator:WebcamMediator = new WebcamMediator( viewComponent );
var webcamView:WebcamView = new WebcamView( webcam );

just three lines of code, and yet a whole world of possibilities...

I've thought through some of the possibilities so I'll present them as a brief list, with my objection to each one. Maybe someone could point out the best method and why.

Method 1: Use a Command
command acts on a notification from the NetConnectionClient, executes the above code.

Objection: the command doesn't have any knowledge of the stage, so it doesn't have a viewComponent that it can pass to the mediator.

Method 2: Use a StageMediator
stageMediator receives notification from the NetConnectionClient, executes the above code

Objection: the stageMediator is doing all the heavy lifting, will end up with most of code in the stageMediator

Method 3: Separate out creation of Proxy from creation of Mediator
a command creates the WebcamProxy and then fires a notification which the stageMediator catches to instantiate the WebcamMediator

Objection: we have added a notification and a command AND we are still using the stageMediator to create the webcamMediator. ie every request now requires two notifications and a command and must be routed via the stageMediator.

Method 4: Instantiate WebcamMediator on startup
now we can go back to the original command idea since it will not need to instantiate the webcamMediator

Objection: we adopt the practice of registering *all* mediators at startup. Seems like it goes against the principle of only instantiating things at the moment they are needed.

Method 5: Use a StageProxy
now the command can access the stage via the proxy so it is able to instantiate mediators.

Objection: seems a bit weird to create a proxy just so we can get round the problem of mediators requiring a viewComponent when they are instantiated.


I guess if I could distill the above thought process into a single question it would be:

if we want to create a proxy and its corresponding view (plus mediator) and we want all this to happen only at the moment we need it - then what is the best approach for making this happen?

and if I could simplify this question even further it would be:

what is the BEST way to instantiate mediators?

Hence the title of this thread... :)

Any help or further thoughts will be much appreciated!
Pages: [1]