Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
September 22, 2017, 08:54:36 PM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
Pages: [1]
Print
Author Topic: Agentscape + pureMVC  (Read 5248 times)
bforchhammer
Newbie
*
Posts: 2


View Profile Email
« on: February 18, 2010, 09:22:50 AM »

Hi,

I have been looking at PureMVC for a current agentscape-based project which I'm working on. AgentScape is an agent operating system; in short it supports large-scale agent systems with multiple agents in different location which can communicate by sending messages to each other.

My project is about creating a web-based presentation "framework" for agent-based systems, and I feel that an MVC-based approach would generally fit nicely. The idea so far is to create a version of PureMVC which allows the different main components (commands, proxies, mediators) to be independent agents in the system.

I am not sure about a few things, 2 questions:

1) Is there a recommended way of working with Request/Response based UIs? As far as I understand, with flash it's possible to adjust individual user interface components as soon as changes are necessary; But with the Request/Response mechanism the whole interface (layout) usually needs to be re-constructed every time and only served to the client once complete.

2) How tightly coupled are different parts of the system? How much do they need to about each other? Notifications I can convert into inter-agent-messages when necessary I think, but I'm not sure about cases when e.g. mediators directly instantiate proxy-classes...

Thanks,
Ben
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW
« Reply #1 on: February 18, 2010, 01:53:07 PM »

Quote
The idea so far is to create a version of PureMVC which allows the different main components (commands, proxies, mediators) to be independent agents in the system.
Why are you of the mind that you need a special version of PureMVC?

On the AgentScape website it says:
Quote
Agents are active entities in AgentScape that interact with each other by message-passing communication.

Well, the PureMVC actors (mediators, proxies, commands) are already have their own way of communicating (notifications). But usually these actors work together to perform the work of a core or an application. I imagine a modular approach where PureMVC cores are the agents of the system is more likely what you want.

Quote
1) Is there a recommended way of working with Request/Response based UIs? As far as I understand, with flash it's possible to adjust individual user interface components as soon as changes are necessary; But with the Request/Response mechanism the whole interface (layout) usually needs to be re-constructed every time and only served to the client once complete.
It would depend on your widget toolkit how you do this in the language/platform you're working with. From the AgentScape site, I'm assuming you're using Java.

You want to encapsulate much of the UI behavior in the component itself as possible. With Flex, it is possible to do this with Flex view states. So you can have a component receives data and change its visual aspect to display or edit data.

For instance, a view component might contain a list and when you select an item and click a button, it fetches the detail data for that item and displays it. You might have the view component have a 'FETCHING' state that is displayed after the button is pressed. It would no longer have the 'View Details' button, but in its place would appear an indeterminate progress bar saying 'Fetching item'. Then when the service returns the data, the proxy sends a notification that the mediator hears and sets the data on the component. When the data is set, the component might go into a 'VIEW_DETAIL' state where the progress bar is gone and an 'Edit Details' button appears. 

The PureMVC apparatus mostly just shuttles data between the View and Model tiers. How you manage view behavior is entirely in the view component and not a matter of the framework. With the StateMachine utility, you can have application-wide states, but you still need to reconcile your individual view components states with the overall application state. This is a matter of the mediator for each component listening for application state changes and telling their view components to hide, show or reconfigure themselves appopriately.

Quote
2) How tightly coupled are different parts of the system? How much do they need to about each other? Notifications I can convert into inter-agent-messages when necessary I think, but I'm not sure about cases when e.g. mediators directly instantiate proxy-classes...

Mediators don't often instantiate proxy classes. That is usually handled at startup of the application in a command. That's not to say they couldn't they just usually don't. According to the MVC concept the view may update the model, and so mediators often retrieve and cache a reference to frequently accessed proxies when they are registered. After all, the view has no other purpose in life than to display and let the user interact with the model, so it is understandable that the view will have some dependencies on the model tier actors.

The separation we want to be most careful about is from the model to the view. The Proxies should not know anything at all about the rest of the application. Always assume that some or all of the model tier will be reused in another application. This will keep you from making dependencies on the Mediators or Facade or Notification names of this app. It is also why Proxies don't listen for notifications. It would be too tempting to make dependencies on the app.

Many people choose to separate the view from the model with the aid of the controller. That is instead of having a mediator retrieve a proxy and make a call on it, they instead send a notification, which is mapped to a command, which retrieves the proxy and makes the call. This is perfectly fine, but not necessary. If it makes you feel cozy that there is a one to one relationship commands and model interaction initiated from the view, then by all means go for it. But, it can also be seen as adding unneeded complexity. If you are making the same call from 5 places in your app, then sure pushing that into a command and sending 5 notifications is probably called for.

Basically, things are as loosely coupled as they need to be to implement MVC.

-=Cliff>
Logged
bforchhammer
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: February 19, 2010, 06:11:25 AM »

Wow, thanks - that's very helpful! Smiley

Quote
Why are you of the mind that you need a special version of PureMVC?
Oh, what I meant was actually not "a special version" but rather an extension to the existing framework (btw. yes, I'm working with Java). For example I was thinking that I would create a ProxyAgent which extends the Proxy class and adds in agent-specific code that allows the proxy to be run separately (possible in a different agentscape location), without needing to be concerned about which concrete applications make use of it.

Quote
Well, the PureMVC actors (mediators, proxies, commands) are already have their own way of communicating (notifications). But usually these actors work together to perform the work of a core or an application. I imagine a modular approach where PureMVC cores are the agents of the system is more likely what you want.

The basic idea is to have different agents for data (~> proxies), presentation (~> mediators ??) and "applications" (~> facade+controller). I might have to rethink this and use different cores for each... it's a work in progress. ;-)

Quote
You want to encapsulate much of the UI behavior in the component itself as possible. With Flex, it is possible to do this with Flex view states. So you can have a component receives data and change its visual aspect to display or edit data.

So, if I understand this correctly I would for example - depending on the component library - have a LayoutComponent, which contains all my other ui-components (which in turn are controlled by their own mediators?), and which I would "request to be rendered". And that would then (probably somewhere inside to the component library) populate the response object respectively..?

(I am mainly asking because I have not decided on a component library yet, and have been trying to directly use a servlet's HttpRequest and Response object...)


Thanks for the extensive answer to my second question, it makes things much clearer!

Cheers,
Ben
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW
« Reply #3 on: February 22, 2010, 10:25:09 AM »

Quote
So, if I understand this correctly I would for example - depending on the component library - have a LayoutComponent, which contains all my other ui-components (which in turn are controlled by their own mediators?), and which I would "request to be rendered". And that would then (probably somewhere inside to the component library) populate the response object respectively..?
Well the view components would have mediators listening to them, yes. And when the component sends an event that says it has some data to go off to a service, the mediator tells the proxy (or a command which tells the proxy, your choice) to take the data it plucked from the view component and do something with it. The proxy takes it from there, sending the data to the service.

If a view component requested some data by sending an event, the mediator requests the data from the proxy by method call and then is later notified by the proxy that the data has come back. The mediator takes the data from the notification and stores it on the view component.

90% of MVC is all about pingponging data from the Model to the View and visaversa while maintaining loose coupling.

As long as the view component doesn't know where the data comes from, it's loosely-coupled and can be reused by another app. As long as the classes that talk to the services (Proxies) don't know anything about the view components or the rest of the application they're in, they are also loosely-coupled and can be reused in another app.

-=Cliff>
Logged
Pages: [1]
Print
Jump to: