PureMVC and sockets

[oklamos]

Hello,

I have simple question about sockets and received streaming data from server, where whe socket object should be in my puremvc application ?,

The socket have event occur when data received, so i think to put the socket  in  the view  , is that right ?

where i can find sample that use puremvc with seckets in flex ? 

Thanks

[oklamos]

 

[puremvc]

Place this in a Proxy.

A quick read of the Best Practices document under the 'Docs' section of the site will give you a good idea about how things are separated in a PureMVC app. There aren't any socket demos, but the details of socket communication as opposed to ordinary service calls really doesn't affect where you'd put the code.

-=Cliff>

[oklamos]

Thanks Cliff for your replay, 

i read about the remote proxies and i think to put the socket read and write functions in a remote proxy !!!

i read also about the delegates, and now i confused where to put the socket code in remote proxy or the delegate !!!

what you i think is a good place to put socket code from your experience ?

[puremvc]

Just because a component is defined in MXML doesnet mean that adding logic to it is 'shoehorning'. Its a class like any other class - an actor whose behavior and logic should be encapsulated according to ordinary OOP principles.

In the earliest days of Flex, we couldn't ASDoc an MXML file, and this lead to a lot of folks, myself included, to argue for code-behind in the view.

But that is no longer the case, and I can see no valid reason for using code-behind to break a component's encapsulation and hamper its portability.

The view components have the highest potential for re-use, and when you unnecessarily lobotomize a view component and put its brain in a vat then you have an to take that vat along with you everywhere you go. Imagine you create a view component that does a special kind of charting. You are building it for a specific app, but you realize that it could be widely re-usabe (perhaps even marketable) if you play your cards right. In your app, maybe you're using PureMVC, but users of cairngorm, mate, swiz, fizz, floop, flop and flap do things differently. But the one thing common to us all is that we often have to take off the shelf components and adapt them to our systems. If your component is fully self contained and exposes a simple API of events, methods and properties then you'll find it easy to make everyone happy because it's dirt simple to drop in and use.   

And consider the situation being reversed. You find yourself charged with dropping someone elses component into your app and making it work. This is how most COTS components you find will work, so if you're doing code-behind in your own components, you'll be faced with a disparity in the implementation of your system when it comes to this component, you'll just wrap a mediator around it, listen for events and set data and call methods on it.

If you look at how Flex itself is built, you don't see code behind in components.You see encapsulated classes. In building upon all this why would we decide to break encapsulation of our own components?

-=Cliff>

[Jason MacDonald]

I think cliff may have accidentally reposted his reply from this thread to this one.