Return partial from a xhr request

Hi,
I am working on a mobile device dev using javascript and I use a remote
Rails app for the backend.
I query the backend using Ajax, and I would like to know if from my
controller I can return a partial in response to the ajax request?

Greg

yep u can

index.js.erb

and in it, render your response

buts its worse idea, return json, and build dom

Ivan N.
[email protected]

Ivan N. wrote:

yep u can

index.js.erb

and in it, render your response

buts its worse idea, return json, and build dom

Ivan N.
[email protected]

I’m not sure to understand.
You think it’s better to return json and than build the dom from the
javascript?

Andy J. wrote:

It’s faster/lighter to do it that way.

However, you often break DRY* as you have two sets of logic used to
create
markup from a dataset (one in Rails and one is JS). So I’m not sure I
agree
with Ivan.
Cheers,
Andy

If you don’t agree how would you do it?

You think it’s better to return json and than build the dom from the
javascript?

It’s faster/lighter to do it that way.

However, you often break DRY* as you have two sets of logic used to
create
markup from a dataset (one in Rails and one is JS). So I’m not sure I
agree
with Ivan.

Cheers,

Andy

yes
its better choise

Ivan N.
[email protected]

Hi Greg,

On Thu, Jun 3, 2010 at 8:05 AM, Gregory M. [email protected]
wrote:

Hi,
I am working on a mobile device dev using javascript and I use a remote
Rails app for the backend.
I query the backend using Ajax, and I would like to know if from my
controller I can return a partial in response to the ajax request?

If you’re asking if you can return it specifically from the controller
rather than through an rjs template / view, the answer is yes.

render :update do |page|
page.which_ever_method_you_need
end

But I tend to agree with Ivan. If you’re trying to get html to your
javascript app, it’ll probably be easier in the long run to send json
and build the html on the client.

HTH,
Bill

I’d do it as the OP requested, have a partial used in both places and
return
that.

It depends on the amount of data/size of partial to be displayed - but
as
it’s a mobile device I can’t imagine it will be huge…

Cheers,

Andy

people
not use rjs, its ugly

Ivan N.
[email protected]

I’d do it as the OP requested, have a partial used in both places and
return that.

Sorry, just realised you were the OP :slight_smile:

In particular I’d use jQuery’s load method to load the URL in to an
element
(the original page’s container for this section):

http://api.jquery.com/load/

And from within the controller just render the partial:

render :partial => “my_data”

(having a view called _my_data.html.erb).

Cheers,

Andy

mm, u can do it
but

  1. u should write yet anothe action at controller, its not like REST
  2. its will be more slower, than render at mobile device, from json

Ivan N.
[email protected]

Andy J. wrote:

Sorry, just realised you were the OP :slight_smile:

In particular I’d use jQuery’s load method to load the URL in to an
element
(the original page’s container for this section):

http://api.jquery.com/load/

And from within the controller just render the partial:

render :partial => “my_data”

(having a view called _my_data.html.erb).

Cheers,

Andy

This is exactly what I planned to do until you said it would be better
to return json

This is exactly what I planned to do until you said it would be better
to return json

Ivan said it would be better, not me :slight_smile:

I said that it is faster/lighter weight - but not better and said I
disagreed with him.

Cheers,

Andy

mm, u can do it
but

  1. u should write yet anothe action at controller, its not like REST

No reason why you should…

def show
…blah…blah…blah
if request.xhr?
render :partial => “whatever”
end
end

  1. its will be more slower, than render at mobile device, from json

How much slower is a big thing though. If you can cache the response
then
it should remove the load from Rails, if the content is small/gzipped
over
the air time should be negligibly larger than JSON and if it takes a few
milliseconds longer than JSON parsing/DOM creation on a client device
it’s
not the end of the world.

Optimal performance isn’t necessarily the only criteria in success…

Cheers,

Andy

if request.xhr?
render :partial => “whatever”
end

if developers, from my team, write this, i curse too much for such)

How much slower is a big thing though. If you can cache the response then it should remove the load from Rails, if the content is small/gzipped over the air time should be negligibly larger than JSON and if it takes a few milliseconds longer than JSON parsing/DOM creation on a client device it’s not the end of the world.

yep, if u will be cache the render time, will be good. but data with u
send, will be huge.
Insert big html into dom, is slower then build its in js.

Optimal performance isn’t necessarily the only criteria in success…
yep agree with u

code readability, and understandable to developers, probably two main
factors

Ivan N.
[email protected]

On 3 June 2010 15:17, Ivan N. [email protected] wrote:

if request.xhr?
render :partial => “whatever”
end

if developers, from my team, write this, i curse too much for such)

If a developer from my team makes a judgement/technical direction based
on
incomplete facts I’d curse too much too :slight_smile:

Out of interest, what’s your problem with the above code?

yep, if u will be cache the render time, will be good. but data with u
send, will be huge.
Insert big html into dom, is slower then build its in js.

That’s the important fact - we don’t know how much data/html will be
returned. I’m assuming it will be relatively small (the OP said mobile
device), you’re assuming it will be huge.

Neither of us know, so I’d prefer to go with the simpler solution (that
keeps display logic/markup generation in one place) and optimise to a
JSON/DOM insertion later IF it’s found to be required. Premature
optimisation is the root of all evil…

Cheers,

Andy

Out of interest, what’s your problem with the above code?
its crutch, for incomprehensible thing

Premature optimisation is the root of all evil…

yep, but i’m thinking, that write 1-10 LOC in js, witch will be build
partial for each json element, its not optimisation, its “by default”
use case,
this is my opinion
of course, i will not be try to convince u)

Ivan N.
[email protected]

Out of interest, what’s your problem with the above code?

its crutch, for incomprehensible thing

Sorry, I don’t understand - could you rephrase…

Premature optimisation is the root of all evil…

yep, but i’m thinking, that write 1-10 LOC in js, witch will be build
partial for each json element, its not optimisation, its “by default” use
case,

The problem is we don’t know how complex his logic is that converts the
data
structure to HTML. I think you have a fairly simple display if it’s
only 10
LOC in JS to build it.

This shows how we’re obviously working on different projects :slight_smile:

In my world the logic to display data is large/complicated but the data
displayed (per page) is relatively small.

this is my opinion
of course, i will not be try to convince u)

I’m happy for you to convince me, I’m also happy to debate it (debates
help
everyone clarify their own thoughts/opinions). And I don’t necessarily
disagree with you that your solution is faster (for the client) and may
be
better (if a large data set and simple display logic), but it’s just
that
it’s not the first step I’d take, I’d go with a partial first and
optimise
to JSON/JS rendering if required later.

Cheers,

Andy

and in its view call render, but with js escape

Fair point. I don’t often do this… :slight_smile:

The problem is we don’t know how complex his logic is that converts the
data structure to HTML. I think you have a fairly simple display if it’s
only 10 LOC in JS to build it.

10LOC, yep its for simple results, such twitter post, github notify, or
something else
in my project, we use haml, we can simplify use jshaml tools, for simplify
create dom elements in js

In my project we have very complex display logic (major sports betting
site), so I certainly wouldn’t want to rewrite the 15-20 classes that
determine display logic in to JS :slight_smile:

This shows how we’re obviously working on different projects :slight_smile:

I would say, as far as we are working on projects with a completely
different level of thoughtfulness interface :wink:

Not sure how to take that, but as there’s a smiley I assume you meant
no
offence…

Cheers,

Andy

Out of interest, what’s your problem with the above code?

its crutch, for incomprehensible thing

Sorry, I don’t understand - could you rephrase…

U should not insert if request.xhr?
u can create view, with build js ( show.js.erb)
and in its view call render, but with js escape

The problem is we don’t know how complex his logic is that converts the data structure to HTML. I think you have a fairly simple display if it’s only 10 LOC in JS to build it.

10LOC, yep its for simple results, such twitter post, github notify, or
something else
in my project, we use haml, we can simplify use jshaml tools, for
simplify create dom elements in js

This shows how we’re obviously working on different projects :slight_smile:

I would say, as far as we are working on projects with a completely
different level of thoughtfulness interface :wink:

I’d take, I’d go with a partial first and optimise to JSON/JS rendering if required later.

in phase of prototyping, i thing we can completely remove all ajax,
calls if we can.

Ivan N.
[email protected]