Getting the structured data out of the server response isn't really a
problem. The main question is, what handles that? Well, a function
obviously. Is this a function on an object? What does that object represent?
If it's some metaphorical page controller object, what level of abstraction
does it operate on.
For example, say I have a products index page. I've just edited a product
via an inline form, and submitted the result. The PUT request to the server
tells me that it was successful, and returns the up to date JSON object for
the product. I think I want to see code a bit like:
= remote_form_for @product, :success => "page_controller.productUpdated",
:failure => "page_controller.ProductUpdateFailed"
(maybe it'd handle success and failure here, or maybe that logic would be in
the javascript page controller)
var ProductsController = Class.create({
productUpdated: function(json_product) {
....
}
productUpdateFailed: function(json_product, errors) {
....
}
});
That's prototype, not jquery, but you get the idea.
The Products controller in this example seems to want to respond to high
level messages ("like CRUD messages to do with products"). I wouldn't want
to mix that up with button click events, requests to trigger loading
graphics, etc. Whatever the pattern is that is used to organise my
javascript code should ensure that each object operates at a fairly
consistant level of abstraction. One level that I want to emphasis is CRUD,
relating to the model on the page. Maybe there's more than one model on the
page. Maybe there's more than one client side resource controller to handle
them.
This should all sit nicely on top of rails. Convention over configuration
should link it all together. Maybe, because there's a json product being
passed around, I can declare a javascript Product class, and it'll
automatically be used to extend the json response, allowing me to add
methods. It should also all be optional. The great thing about rails AJAX
functionality is that you can slowly put it into a rails app with no ajax.
So, client side controllers should be totally optional, and you could slowly
add them into an existing rails app as it became more client heavy. This
seems quite different from using other frameworks.
Haml in javascript sounds like an awesome tool, thanks for pointing that out
guys.
Sammy looks interesting. Seems to be using a HTTP metaphor for mapping
javascript event handlers to routes. I'm not convinced that this is the
right pattern to be using for this. I think we should be thinking more about
client/server desktop apps, and the patterns that we use there.
Craig
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
