It's an interesting point. We don't really want to maintain two sets of
templates. Thus, we either tend to do our templating on the server side, or
the client side. Us rails folks do it on the server side, but that means we
do suffer from a number of disadvantages, the obvious one being our tendency
to use AJAX when it wasn't really necessary to contact the server. Sharing
templates between the client and server is hard without a shared language
(not just a shared templating language). You can see why google generates
their javascript from Java, to solve that problem.
Obviously it'd great if we could run ruby in the browser.
I'm not quite willing to use javascript on the server side, not even for
consistency's sake.
Maybe the solution is to keep any given template *either* on client or
server, but not both.
For example, I write a products list app in rails. The products
index.html.haml (or erb, or whatever) contains a list of products, each
rendered using _list_product.html.haml. Then decide that product is getting
fairly dynamic, and I want to move it to the client. I can do so one CRUD
action at a time, but as soon as I want to move the concept of "showing" a
product in the index (ie, after an insert or update), then I *have* to move
to the template to the client side part of the framework.
So, _product.html.haml goes away (from the app dir at least), and instead
the products index has some line like:
= render_client_resource_collection @products
Which converts the products to json, and asks the client side resource
controller to render them. The template is now in
/client/products/_list_product.jshaml or something, and it obviously
contains inline JS, not ruby.
I can't think of a nice clean way to use the same template for both ruby and
JS code, even though the template is HAML, hence why I'm suggesting an
approach of using it in one or the other, to avoid duplication.
That still has some advantages over having to pick between a server side or
client side only framework. You get the choice on a case by case basis,
perhaps getting the best of both worlds.
Craig
On Tue, Dec 8, 2009 at 1:56 PM, Julio Cesar Ody <julio...@gmail.com> wrote:
> That's an architecture discussion, and like every discussion of that
> nature, there's many ways to skin this cat, all of which will give you
> the expected result, with tradeoffs, minus of course the plain wrong
> ones. The approach you pointed out with Prototype is fine in my
> opinion, minus the Rails ajax helpers which I think should be replaced
> by plain regular HTML plus JS hooks trapping the appropriate events
> and firing requests.
>
> On the matter of JS templates, and JSON-only based server
> communication, while that's great because it means your web client
> will get the same API as any other client would among other reasons,
> what now happens is you have to write/maintain your markup in
> jaml/js-haml/whatever-other. If you're of the opinion that that's less
> work than "real" Haml or even HTML, then fine. I for one am not. And
> for that sole reason I haven't yet found myself yet using any of that
> in a project that has a lot of templating involved. That will surely
> change in time but I don't think that time is now.
>
>
>
>
> On Tue, Dec 8, 2009 at 1:44 PM, Craig Ambrose <cr...@craigambrose.com>
> wrote:
> > 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 rails-ocea...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > rails-oceania+unsubscr...@googlegroups.com<rails-oceania%2bunsubscr...@googlegroups.com>
> .
> > For more options, visit this group at
> > http://groups.google.com/group/rails-oceania?hl=en.
> >
>
> --
>
> 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 rails-ocea...@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-oceania+unsubscr...@googlegroups.com<rails-oceania%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>
>
>
--
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 rails-ocea...@googlegroups.com.
To unsubscribe from this group, send email to
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
