I'm creating my first Rails application and I'll be integrating a few other apps, like Mandrill, Xero and such.
I'm just wondering what best practises are on storing instance variables globally. For example, I don't want to configure my Mandrill wrapper instance in each of my controllers. I want to do it in one spot and make a call to it whenever I need to send an email out.
Is application_helper.rb the spot to do this?
I would create a service for that. As the matter of fact you can check http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ which is a great way to do your applications flexible, testable and easier to maintain.
Related
I've come across two scenarios with regards to creating a REST API in Rails and I wonder which one is preferred. Usually
if you know that you're required to have a REST API for your application at start. Does it make sense to have it in a namespace and thereby duplicating the controller logic?
I've seen examples where people have an application already and later figure they need to extend and offer a REST API. The approach to this has been to create new routes with namespacein routes.rb and controllers/api/whatever.... This still yields duplicate code though, but might be more sensible approach. The difference being a stateless machine for the REST API calls.
Can anyone elaborate on the preferred approach, thanks.
If you create a Rails application, and following the usual conventions, you basically end up with a REST API. Unless you are talking about a more specific meaning of the term (which I am not aware of), "REST API" is more a bunch of general characteristics of the API (i.e., things like statelessness, resource-based URIs if using HTTP, etc.).
So to turn the question right back to you: which case are you thinking about where a (conventional) Rails application is not by extension trivially a REST API?
I'm going to be collaborating with a Python developer on a web
application. I'm going to be building a part of it in Ruby and he is
going to build another part of it using Django. I don't know much about
Django.
My plan for integrating the two parts is to simply map a certain URL
path prefix (say, any request that begins with /services) to the Python
code, while leaving Rails to process other requests.
The Python and Ruby parts of the app will share and make updates to the
same MySQL datastore.
My questions:
What do people think generally of this sort of integration strategy?
Is there a better alternative (short of writing it all in one language)?
What's the best way to share sensitive session data (i.e. a logged in
user's id) across the two parts of the app?
As I see it you can't use Django's auth, you can't use Django's ORM, you can't use Django's admin, you can't use Django's sessions - all you are left with is URL mapping to views and the template system. I'd not use Django, but a simpler Python framework. Time your Python programmer expanded his world...
One possible way that should be pretty clean is to decide which one of the apps is the "main" one and have the other one communicate with it over a well-defined API, rather than directly interacting with the underlying database.
If you're doing it right, you're already building your Rails application with a RESTful API. The Django app could act as a REST client to it.
I'm sure it could work the other way around too (with the rest-client gem, for instance).
That way, things like validations and other core business logic are enforced in one place, rather than two.
A project, product, whatever you call it, needs a leader.
This is the first proof that you don't have one. Someone should decide either you're doing ruby or python. I prefer ruby myself, but I understand those who prefer python.
I think starting a product asking yourself those kind of questions is a BAD start.
If your colleague only knows prototype, and you only know JQuery, are you going to mix the technologies too? Same for DB? And for testing frameworks?
This is a never ending arguing subject. One should decide, IMHO, if you want so;ething good to happen. I work with a lot of teams, as a consultant, Agile teams, very mature teams for some of them, and that's the kind of stuff they avoid at all cost.
Except if one of you is going to work on some specific part of the project, which REALLY needs one or other of the technologies, but still think the other one is best for the rest of the application.
I think, for example, at a batch computing. You have ALL your web app in ror or django, and you have a script, called by CRON or whatever, computing huge amounts of data outside the web app, filling a DB or whatever.
My2Cts.
I notice it's used primarily for sending emails. Let's say I want to send an email after every comment is created.
Is using Observers really necessary when you could just place the Mailer.deliver_email(user) in your comments_controller.rb's create action instead?
For proper programming practices, yes. The observers decouple the code and make sure it stays maintainable.
I mean, the mvc for cairngorm and the one in rails don't overlap their functionalities? I'm not sure I understand the need for cairngorm with the rails backend..
There is no need, it's an option, Cairgorm see's the whole Rails as a model. Rails send xml instead of html so no browser-css-details headaches.
You can use rails as a REST layer and put your business logic in flex.
You can use cairgorm as a candy cover over a complex but well tested rails application.
You can find middle of the way solution that suits to you.
We do implement most business logic in rails but use flex/cairgorm to show each user only the right buttons/forms/controls to her task, and to do it in a nice browser-independent way.
Hope this helps you, feel free to ask any detail
Rails is MVC for the server. You still need an architecture for a sufficiently complex client application. We're using PureMVC on the client with a REST (JSON) interface to a Rails server and it's working nicely. PureMVC allows for the client's model to be independent from the client's view components, and makes it easy to update independent view components simultaneously.
I have a simple site, using restful_authentication and a simple model for the posts. I would like to use MarsEdit (or something like Ecto) to post/edit content. How would I go about this?
The XML-RPC system is rather bewildering - there's a lot of different variations (Atom, MovableType, metaWeblog, Blogger, TypePad, probably others), never mind actually implementing any of them.. The Action Web Service API in Rails, which is intended to implement such APIs, has deprecated a while ago..
Try a plugin...
http://github.com/calavera/atompub-server/tree/master
Or this library...
http://github.com/inkspot/alumina/tree/master
As a starter/prototype for what you need