Modularity - Why Shell and Canvas?

[pebanfield]

Hi -

I'm interested in using the multicore version for my AS3 only app. It looks like I can use the ModuleBase class without the overhead of Flex framework required by Module - barring this I will simply load a swf.

I've been pouring over the Modularity example and I can't quite work out why I should need both a shell and the canvas? It seems to me like there is some redundancy here and so I'm wondering what potential scaling scenario I am missing?

This seems further complicated by the Shell consisting of both a view and a mediator. I'm inclined to start with just one mediator(shell) and one view(canvas) and then refactoring when the need arises. Anyone have any thoughts on this? Thanks.

Peter

[puremvc]

The shell could be the main app/canvas. It's just a demo, and certainly npot the only way to approach it.

-=Cliff>

[pebanfield]

OK thanks Cliff. Maybe I sounded like I was being critical - didn't mean to.

Let me rephrase - in your opinion could the shell and canvas be combined? In what circumstances would you consider it helpful to have both of these classes? Can you provide an example/generalization of the kind of duties that these classes should be responsible for?

Or perhaps the focus of this example code was more on the usage of Module and I should ignore this portion of the design. Thanks!

Peter

[puremvc]

I think the responsibilities of the Shell and Canvas as shown in the demo are pretty clear, even though it might not be the most well-conceived demo of all time.

The Shell is responsible for communications with the Widgets, which just happen to be visually contained within the Shell component itself as children, though they could simply be held in an array that the Shell has access to.

Also, the Shell and the modules need not have a visual appearance.

When the Modules communicate with the Shell, the communicates their wishes to the rest of the main application. So the Canvas doesn't need to know anything about the modules or how do communicate with them. In the demo, we're adding or removing components to/from the canvas based on these communications.


-=Cliff>

[pebanfield]

The problem was not necessarily with the demo - perhaps I just wasn't getting it. I think I was over thinking the design of the example. But this last clarification helps. Thanks.