I am new to both rails and backbone, and I need help to figure out how do go about creating an app. I am trying to create a rails app that could read the contents of provided JSON file and perform the required action mention in the JSON file. My application will not have any database but JSON will act as a database (that's my current thought). AS there is no database I am confused about how to use rails model for reading JSON? Should I use rails model or should I use backbone's model to read JSON?
I am not sure of what exactly you are trying to implement.
It seems that you are trying to build a JSON RPC implementation and using an existing rpc backend will save a lot of work for you. The following link might be informative : http://json-rpc.org/
Also I do not understand that how do you plan to implement persistence without a database backend. In case the application does not require persistence the model layer is simply not required. Are you very sure that an MVC framework actually suits your requirements. It does not seem to fit in.
Related
I have a existing project in Ruby on Rails.
What is the best way to use AngularJS in Ruby on Rails app?
I want to use AngularJs for only specified modules, not for create SPA. This is good way?
What I have seen colleagues do in order to achieve this sort of integration with an existing rails app is:
Include angular.js and relevant dependencies in the specific app pages that are to be 'angularized'
Interpolate whatever data is needed to bootstrap the angular controller into the html template which contains the angular app. This might include data about the resource being operated on. I've seen this done by rendering a RABL template inside of a haml/erb template.
Using that interpolated data, call whatever API methods you need to get additional data on the fly. This is usually just a matter of implementing json handlers for routes you've already created.
I can't say whether this is best practice, but its an easy way to get started fast.
Best of luck, angular is a very enjoyable tool to work with once you get used to it.
I'm looking for the "rails" design pattern for code that fetches data from other websites.
I have a rails controller in my app that fetches data not from the database, but from external API's or scraped from the web.
Where's the "rails" place to put this code.
For quick implementation, I just stuck it in a model, but the model doesn't interact with the database - or support standard model functionality - so that feels wrong, but my understanding of rails and ruby isn't yet solid enough to know where it should go.
The way the code works roughly is
controller calls model.fetchData args
the model uses HTTParty or similar to make the call
processes data
passes it back to the controller
Any advice?
Broadly-speaking I think there are two possible ways to do this:
Create a plain ruby class to contain the methods for making requests to the API(s) and processing responses from it(them). You can include the HTTParty module in this class with include HTTParty. The usual place to put this code is in lib/ (make sure that wherever you put it, the path is in autoload_paths).
If you're doing anything really complex, or the API itself is complex, you might want to consider creating a separate gem to handle interaction with the API(s). The term for this type of gem is an "API wrapper" -- if you look around, you'll see there are lots of them out there for popular services (Twitter, LinkedIn, Flickr, etc.)
Notice I haven't mentioned activerecord. If you're not going to be saving anything to the DB, I don't see any need to even create any activerecord models. You can get by with just controllers and views, and then (if needed) pick and choose components from activemodel (validations, internationalization, etc.) to make your ruby API wrapper class feel more like a Rails model. For example, one thing that I've done in an app I'm working on is to apply validations to query strings before actually making requests to an external API, which is a bit like running validations on database queries before querying a DB. See this article by Yehuda Katz for more on how to make plain ruby objects feel like activerecord models.
Hope that helps. I answered another question very similar to this one just yesterday, you might want to have a look at that answer as well: Using rails to consume web services/apis
I have a Rails app that acts as a pass-through for an XML services API.
The main use cases goes like this:
User POSTs parameters to Rails via http://example.com/model/report. For brevity, let's say the form just submits zip_code=90010.
Rails takes zip_code and uses RestClient to query an external XML services API via a GET request: http://xmlservice.example.com/report?report_id=1&zip_code=90010
The report response is returned via XML. I want to parse the XML via Nokogiri and output a normal HTML view via report.html.erb.
I'm struggling to figure out where to put my XML (Nokogiri) code. Should I process the XML in my model or do all the parsing in the controller?
I know both methods will work, but I want to know what the best practice would be. This also is not a background XML feed grab, so it's not suited to be a delayed job that runs nightly. It has to answer dynamic requests 24/7.
Keep in mind, I've removed ActiveRecord from my app for optimization. This app doesn't touch any databases. It's basically a pass-through to the XML API that will render HTML output for the client.
I've read it's best to go with "skinny controllers" and "fat models", but most of the Nokogiri examples I see out there have doc = Nokogiri::XML(RestClient.get(myurl, myparams)) type code inside the controller.
So... model or controller?
Thanks!
I would place the code in a class which would fetch the xml and parse the xml for you.
This way its easier to Unit Test the class for parsing or any other operations you want to do on the returned XML.
The class can be placed in the lib folder or if its sort of like a Pseudo Model ( with a XML Database ) it can be placed in Models as well. Thats mostly upto what the class is and how you would like structure your codebase.
Update: a Plus of this approach, you code base can remain the same even if you swap out the service for something else, because you code base interacts with this class, the changes will have to be made only to this class. Interface advantages :)
I am new to the Ruby on Rails thing, and while I like the organization and standards provided, I am a little confused on how to make rails work for me in this specific case.
I have a Webservice that I want to use my rails application with. Making a direct connection to the database would be nice and provide me instantly with the models I need to make my Rails application work.
However, I would have to replicate all of the logic provided by the webservice(which isn't trivial). If I didn't make a direct connection to the database, how would I persist the models(such as a user model).
Would I have to make a separate database that mimics the server's DB but never actually interacts with it directly?
Thanks in advance -- let me know if you need clarification.
EDIT: Example
I have a rails app that gets on URL www.mywebservice:8080.com/users/5
Service returns JSON {name:foo,nick:bar,friend:baz}
At this point how do I tell rails to make a User object out of what it just got and then store it in the database? Or do is there a way to persist this JSON object?
ActiveResource handles your use case just fine http://api.rubyonrails.org/classes/ActiveResource/Base.html
What it does is reflect on the json returned by the service and fake out the object to make it look like it's a real object.
class User < ActiveResource::Base
end
user = User.find(1)
puts user.name
# "scott"
Why rails if you don't need any of its features? I'd recommend start with Sinatra, then add the libraries you need, as JSON, ActiveRecord(?) that Rails ships with.
You may connect to any database you want and you don't have to use ActiveRecord, however, it's hard to understand what you're really asking. How is this title related to the question? Why direct DB? You don't want to instantiate a User-object and then do a user.to_json on it?
KISS! :)
I got the following situation:
I have a rails application and two databases, one is for the Rails Application and the second database (running on the same DB Server Instance) is for a different non-web application.
My Rails Web Application may read from the (second) Database directly via SQL but it can't write to it because of security restrictions (the data has to be validated by the non-web application). So we wrote a little CLI interface based on SOAP for writing into the database.
My question is: Can I extend the ActiveRecord Model (Rails 3) in a way so that the reading goes as normal over the SQL connection but update/create/delete goes over our selfmade interface.
I think I found a good solution :)
# rtacconi: Thanks for your links but since Rails 3 you don't have to use these extensions because ActiveModel works table-less out of the box :)
I need full ActiveRecord support for reading the table but writing is done over my SOAP interface. This is because I can't validate the data in my Rails application.
So my solution is to overload the ActiveRecord::Persistence Module (can be found in activerecord-3.0.0/lib/active_record/persistence.rb.
This module is responsible for any write tasks to the DB connection. So instead of writing to the DB, my Persistence Layer calls the SOAP interface.
Best regards
Simon
You could implement a tableless model: ActiveRecord::Base Without Table or http://github.com/AnthonyCaliendo/acts_without_database
Than you can set/get data into an object using the SOAP library.