This is, I'm afraid, too general question to answer, as I feel you're coming from different framework (PureMVC?). I've never encountered view cloning and can't imagine a situation in which it could be used - can you explain more? Also, it feels like a problematic step to perform, if possible at all.

From injection point of view, you have two approaches to choose from - either have one presentation model, created in context and then injected into each view object of the same type or each view can create their own presentation model upon construction and wire it back to context._________________Sebastian Zarzycki
Feerie Software

Let me explain a problem I am facing. I have a very busy screen (with mediator) - about 50 fields. All these fields are custom controls with skins and everything. When I am showing just one screen it gets rendered fast enough, but if I have to show multiple copies of this screen it takes longer then I want. I guess that it takes long time to render the screen to Stage because the following line of code:
var _screen:sometype = new sometype()
is executed at no time. But it would take time to get the app to respond to a mouse click in case I have to show multiple copies using a loop with the above code inside. I was thinking to use cache to avoid the above line of code and reuse the screen somehow.

This isn't really a Parsley question. Flex views can be quite intensive and with lots of controls, you can expect slowdown. This is a shortcoming of Flex and Flash Player that many have noticed. But you can't simply overcome this by creating view copies as normal objects. The actual instantiation of view object doesn't take long - the initialization cycle takes long - creation of children, layout, measurements, skinning, bindings, events. All this happens when objects is added to Stage, either directly or as children of other already added objects. There's little you can do to avoid that beside different design and smart object optimizations.

Why do you need many screens consisting of 50 fields being shown at once - this doesn't seem even plausible, given the screen estate? Can you solve it with viewstack, states or components supporting virtualization, like lists or grids?_________________Sebastian Zarzycki
Feerie Software

I assume a bitmap copy is not suitable? That's the only way to "clone" a component. It's fast but it's just a stupid bitmap you can't interact with.

The constructor in Flex does close to nothing; The real work happens when you call addChild/addElement with your component on its parent. This step is ridiculously slow, mainly because of the inefficient code (Mostly because it's not native like in browser engines) computing the styles of your component.

Flex applications are difficult or at least time comsuming to optimize; The framework is not well designed and generally has low performances: Not modular, lots of random static calls, 400 lines methods, encouraging bloated components everywhere (skins made this problem much worse), no option to opt in or out of expensive operations (Again, styling is usually the main culprit, unless you have a tiny stylesheet)

Conceptually, cloning a UIComponent is not a terribly bad idea. It's difficult however and I don't think anyone produced a working implementation. You will need to copy the children hierarchy, all the component state (public, internal properties, register the components with the usual collaborators) and then at the very least monkey patch UIComponent's addChild and Group's addElement (Plus a couple others places as this code is copied pasted... Lol) and check whether the component is ready (has just been cloned, so a simple Flash's addChild should suffice) so that you can skip the heavy operations (Again, mostly styling). Seems too complicated? Yeah, I would not do that.

Keep your skins to a minimum, most fundamentally one-off structural components DO NOT need a skin. Non Skinnable components are decent people. Don't have crazy bindings that are going to fire 50 times before they stabilize. Don't put anything in creationComplete handlers, that is just for throw away prototypes; Do not create 10.000 medium lived objects: GCs are nice but have their limit, this will bloat the Flash thread like crazy. They are so many things you need to be aware of when you develop a Flex application... Mostly because the framework is pretty bad and was designed for phone stores like applications in mind

Last but not least, you may have a big UX problem here if you need to show many similar busy screens at once to the user. I found that good, simple UX often end up in non convoluted code and good perf: A win-win situation. If you REALLY need to put your screens one after the other with a scroller, you will have to optimize them A LOT and virtualize their list parent. Virtualization only works well with highly optimized components as they get created on the fly and you don't want it to be noticeably slow; Another option is to just have a previous/next button and replace the current screen with the previous/next one, ideally just updating your model and keeping the same view.