Lets talk about the Server Side

[puremvc]

I want to work with people to pioneer the best practices of server-side use of the framework. My work in Java on the server side leaves me with some clear ideas, and some general thoughts.

As we expose methods like
 
façade.startup() (http://forums.puremvc.org/index.php?topic=85.msg283#msg283)

to the Flex Application as an entry point into the PureMVC apparatus, the Façade would be the gateway for service calls. It would be the RemoteObject that the client manipulates, exposing the methods that are the API of your services. From there, Notifications triggering Commands that talk to Proxies that retrieve data from the db (perhaps with a DAO).

On the View side, it gets a little fuzzy. I don't know the immediate use for Mediators except if View Components of the system are template objects, into which properties are set and output extracted.

There's the possibility you're doing classic template munging for web or text output. For instance, you could write an FAQbot that listens to an IRC channel, (is the socket I/O class a 'view component' surrounded by a Mediator?) learn responses to topics, store them to a database and regurgitate them on command. That would help someone managing the IRC channel (that we don't have yet) the ability to quickly direct the FAQbot to direct the appropriate entry to the user in question.

HelpGuy34: 'FAQBot, learn MVC http://en.wikipedia.org/wiki/Model-view-controller '

…

JRandom: Hello, can anyone just tell me what MVC means, please?

HelpGuy34: 'FAQBot, tell JRandom MVC'

FAQBot: 'JRandom see http://en.wikipedia.org/wiki/Model-view-controller '

 

There's the possibility of synchronous or asynchronous behavior patterns to consider as well.

I'd like everyone with a server-side language to chime in here with thoughts about this. We need to devise demos and get a clear understanding of how the framework works in the server side environment. Do a little perusal of other server side MVC engines to see how they split the responsibility. I don't want to come up with a different set of basic actors if we don't need them and the existing patterns make sense.

-=Cliff>

[Rhysyngsun]

I could also see views being used to render out HTTP request to XHTML, XML, JSON, etc. The Mediator receives an event containing Proxy data to render out an RSS feed. The Mediator sets the view's public properties based on the data. The RSSView then renders out the appropriate RSS in XML.

Using the view like that you could easily build a very robust and extensive CMS system. Once all your views have rendered their XHTML, you simply stop processing. You could even add Ajax functionality to provide user events to a server-side view.

The only thing would be, that having the view persist server-side would bog down the server. But since HTTP requests are stateless anyway, there's really no need too since the client knows its state.

EDIT: Just noticed you had suggested this in email yesterday. Don't mean to steal your thunder on it, but wanted to add this for completeness of the discussion.

[puremvc]

Just a note to all reading this thread. Nathan has recently submitted an excellent demo that shows that the PureMVC framework is totally capable of rocking the server side house.

See his PureMVC Python / Google App Engine Blog demo; a classic web application scenario:
http://trac.puremvc.org/Demo_Python_GoogleAppEngine_Blog

Essentially everything remains the same except that the view components that the Mediators manage are the output templates that are the server responses. In the demo these are HTML templates for viewing, adding or editing a blog's entries.

Whether you know the Python language (I currently don't) this is highly readable code, which you should be able to easily understand and translate to your own server side platform.

-=Cliff>