There are lots of ways to handle the creation of the ID. The important thing is to understand which way is best for your app.
For instance in the HelloFlash demo
[1], the StageMediator's
[2] notification handler case for the ApplicationFacade.STAGE_ADD_SPRITE note is where a new HelloSprite is created. It refers to the SpriteDataProxy to find out the next color and id for the sprite, then it registers a HelloSpriteMediator for this HelloSprite just before adding the sprite to the stage.
Is that arrangement right for your app? Not necessarily. To figure out the right approach for your app, three things that need to be considered:
1) Figure out where you're going to keep the next id for each mediated view component that needs to be instantiated multiple times. This could be kept on a Proxy, the Mediator responsible for instantiating, or mediating the component. Better encapsulation would be to keep it in a class variable on the component itself. You can make the constructor of the component claim the next id then increment it.
The common element of these approaches is that the id is assumed to be important only as a uniquifier to allow us to register multiple mediators.
However, if your view component will have a one-to-one relationship with a particular piece of data for its entire lifetime (for instance, a component to view a specific RSS feed in a tabbed view), then your data may provide a unique id that can be used in the creation of the id for the corresponding component. This leverages the implicit relationship of the view component to its data for more than just a uniquifier. It can set up a communications channel to the specific mediator for data updates its component is interested in.
The proxy could send a note with the feed data in the body of a VIEW_FEED note and the id in the type property of the note. A command could be triggered by this note, create a corresponding view component, set the id and data from the note, then register a new mediator for the component. In the mediator's onRegister, you could then send an ADD_TO_STAGE note that would be heard by a stage or application mediator (or whoever's in charge node of the display list you want to insert this new component into).
Now you have a mediated instance of the feed component in the display list, showing the initial data.
There after, lets say the proxy makes a timed poll of the feed and gets updated data. It could send a FEED_UPDATE note with the feed id in the type and the new data in the body. The mediator for the feed component would be listening for this and if the type property of the note matched the id of its view component, then it would handle the note by setting the data on its view component, otherwise it would ignore it.
2) Figure out where you're going to instantiate the view components. In HelloFlash this happens in the StageMediator. In the scenario I described at length above, it happens in a Command.
It could also happen in the constructor of the mediator that will mediate the new component. Rather than expect a view component on the constructor of the mediator, have the mediator create the child.
One place it would never happen is a Proxy. The model should in no way ever be tied to the view or controller tiers of the application. You should never see an import in a proxy for something not living in your model package. This makes it portable. In HelloFlash, the next id for the HelloSprite was kept there, to show that application data (relating to the operation of the app), as well as domain data (relating to the data model the app serves) can both live in Proxies. But you'll note that the proxy doesn't know any of the view or controller region actors.
3) Figure out how you're going to get the instantiated component into the view hierarchy. Usually the top of the view hierarchy is mediated by an application mediator or stage mediator. (Note that stage is specific to Flash as is the term display list, but remember this same logic governs how all PureMVC apps work regardless of language). But the top of the hierarchy isn't necessarily the place to insert something if in order to do so, you have to break encapsulation of the view component by 'reaching down' into it's children.
For instance, if you have an application, and it has a tab navigator inside of which one the children is an accordion, and it is into this accordion that your new child goes, you would want to be sure that accordion component was mediated, and then send the newly created component off a note like ADD_FEED_ACCORDION_CHILD that the FeedAccordionMediator hears and inserts the new component into its child.
That is a far better approch than having the application mediator take the note and try something snarky like: app.tabnav.getChild(2).addChild(viewComponent).
-=Cliff>
[1] HelloFlash wiki:
http://trac.puremvc.org/Demo_AS3_Flash_HelloFlash[2] HelloFlash's StageMediator:
http://trac.puremvc.org/Demo_AS3_Flash_HelloFlash/browser/trunk/src/org/puremvc/as3/demos/flash/helloflash/view/StageMediator.as