PureMVC for Flex Components ?

[younes]

Hi,
I'm currently working on Flex components Set for Red5 and, I'd like to know if PureMVC Framework can be used to design a components architecture.
For suggestion/comments don't hesitate
Thanks

[puremvc]

Younes,

PureMVC is intended to adapt components to an ActionScript application. I can't really think of a useful role for it in the definition of the components themselves.

-=Cliff>

[julien]

This is actually a good question.
I had the problem recently where I was refactoring a Cairngorm application (actually just the start of an application) with http services
I wanted to create an auto paginated DataGrid made of a flex component (datagrid+paginator) + a mediator + a remote proxy object.
I wanted this datagrid to be an independent and "self-standing" component, able to be dropped as an xmxl tag into another mxml component or application
Moreover, this grid had to be generic in respect to the data type (value objects) that it was connected to (http request returned generic collections of different Vo classes) (done at the decoder level)
Finally, I wanted to specialize the grid into actual VO collections, so that I have the appropried columns and renderers in a final specialized datagrid component.

Finally,
I did something that may break a little the patterns of PureMVC: the component creates itself its mediator (that is generic), initializes it with himself some specfic parameters, and thats all.
What do you think of this technique ?
Thanks for reading this
Kohinoor

[puremvc]

Kohinoor

It does diverge from the goal of keeping the view components transportable by keeping them ignorant of PureMVC classes. But whether to take or leave such a goal is entirely up to the implementor.

By building the component in this way, you have simply accepted that A) you're only ever going to use this component with PureMVC, OR B) if you do decide to use it outside of a PureMVC app, you're going to have to modify it to run elsewhere.

The key is being conscious of these decisions when you make them. And, if you're in an enterprise or otherwise writing code someone else will maintain, documenting the fact and why the decision was made to go against the best practice. Maybe it was a time constraint. Too long to figure out the solution that fits with the practice. Maybe there was some other extenuating circumstance. Whatever it was, capture it early so that future generations get a clue why things are the way they are.

-=Cliff>