I have a design question that I hope someone can help shed some light
on.
I have a view file which generates a chart. Before it can generate the
chart, it needs the input from an XML file.
I have a method in my controller which will generate the XML file and
write it on to the disk.
What I'm struggling with is how to accomplish these two steps with one
link/button click from the view file.
In other words, when I click the link, it will take me to the
controller method which generates the XML file, write to the disk and
then pass the control to the view file that will generate the chart
and present the view.
Where I am at:
When I generate the XML using the Builder Template (rxml), it will not
only write the XML output to the disk but also output the content to
the view. I can't think of a way to pass the control to another view
(rhtml) file that will generate the chart. And also I would like to
suppress the screen output of the XML file from the Builder template,
so that the generating of XML file will be transparent to the user.
Essentially what should happen is a user click the link, he/she gets
the chart back, and will not see the XML output.
You've run into the fundamental difference between web applications
and desktop applications. Where desktop applications have a run loop
that continually monitors an event queue, web applications have a
request-response cycle. In a run loop events can be generated from
multiple sources, user input, system generated events, etc. In a web
application the web server responds to an event, "wakes" the
application to process the request and return a response, then the
application "sleeps" waiting for the next request.
Once you have returned a response you have no way to inject another
request from within your application. My suggestion is to make use of
AJAX (a.k.a. remote) requests to do what you want. Then you have a
client-side program in JavaScript that can have a type of run loop and
can make multiple request to accomplish your task.
There’s a Rails plugin called ZiYa that does XML based charting. It uses Flash (actually the SWF/Charts product) and it’s really, really nice. Maybe look into that too.
Once you have returned a response you have no way to inject another
request from within your application. My suggestion is to make use of
What I got from his description is that the link should reference the
first action that writes XML to a file, and then redirect to the
action that renders the view with the chart.
The redirect_to doesn't work in this situation because I have to
render the rxml template in order to get the xml output. (at least the
limitation might be my ROR knowledge level. I'm still pretty new to
ROR).
Robert,
Perhaps Ajax might be a way of doing it. I have not got into Ajax yet,
Maybe this might be the time to jump into it.
Brian,
Thanks for the tips. At quick glance, it certainly look interesting.
Will definitely check Ziya out.
By the way, perhaps a bit more information on what I'm trying to do.
I'm basically trying to see if I could implement Simile Timeline in
ROR. Other than this problem that I have encountered, I have also
encountered other issue incorporating Timeline into ROR. So it is
still an uphill process for me. Definitely a good learning exercise.
Fundamentally, you just need to decouple the XML generation and
writing to the disk from the rendering of the view. Thinking about it
some more, you shouldn't even need a redirect. Of course, this assumes
that you're hosted on one server, not a cluster
I'm short on time, so all i can offer you is some pseudo-code
def action
xml = Builder::XmlMarkup.new(:indent => 2)
craft the xml doc, just like you would in an .rxml template
File.open(RAILS_ROOT+"/myfile.xml", 'w+') do |f|
f.write xml.target!
end
# render or redirect, doesn't matter
end
There's also both render_to_string (http://caboo.se/doc/classes/
ActionController/Base.html#M004346) and erase_results (http://caboo.se/
doc/classes/ActionController/Base.html#M004362) that would allow you
to perform the first render and then redirect or render a second time.
But, I do believe that Obie's direction of decoupling the xml
generation is the right idea.
