I have a set of models I need to share among several rails3/sinatra/etc applications. I haven't seen anything like this yet and I'm curious what is the most effective way to go about this in a DRY manner? Can I specify a central area for models, can I create a gem that only brings in the models I need? How have other people approached this issue. I was thinking of making a smallish gem or something I don't yet know about to handle this.
I'm using Datamapper, but this is also a more general issue of structuring multiple rails/non rails ruby apps.
You might find it's easier to have a submodule in your repository that contains your models and associated unit tests than to create a full-fledged gem. This way you can patch from one app to the other instead of having to drive everything top down.
You can create public API to models you want to use in other apps.
In rails you should already have REST controllers, so you can use ActiveResource in the other apps.
You can pack your ActiveResource classes in a gem just to simplify thing and to keep things DRY.
You can check: http://api.rubyonrails.org/classes/ActiveResource/Base.html for some examples.
And it doesn't matter if you're using ActiveRecord or DataMapper.
Related
I've been looking at Administrate source code and would like to know if it's a good practice or not the use of a generic controller and what implications it would have, like code complexity, performance degradation, etc.
Sometime ago, there was a gem inherited_resources that provide this feature, but since Rails 3.0 or 3.1 has been said we no longer need them.
So, since I have some very simple models (with only two or three fields) I could create a generic view and controller to manipulate them and save a lot of lines of "duplicated" code. Although I'm afraid, by avoiding repetition I could be creating another monster.
I've been looking for a Rails way to do this, but failed, so I would thanks some advice.
Note: I'm not looking to implement or use an admin dashboard, but use in my application instead
All Rails admin-panel implementations will make you hurt when you will try to make something more complex than stupid simple CRUD-application. I recomend you not to use such solutions. I had experiece in usage three different Rails's admin-panels and all of them had bad design and a lot of limitations. They are hard to mantain and extend their functionality.
I want to build my application in a modular way: For example I might have:
Users->has_and_belongs_to_many->Projects
Users->has_and_belongs_to_many->Tasks
Projects->has_many->Tasks
Tasks->belongs_to->Project (1 task belongs to 1 project.)
Note: Projects AND tasks can have many users.
The way I was thinking of building this is by doing:
User = Gem
Projects = Gem
Tasks = Gem
Each can return either json (for ember) or html. Neither depend on each other, The idea is that each is just a detail. Rails, ember and html are all just details.
How could I go about this and at the end of the day hook them together like a puzzle? or is this even feasible?
Right now I have the user piece of this concept almost done. It contains models, tests, controllers and views. Can I bundle that as a gem or should I only bundle the controller and the models? This "User" gem would make use of friendlyId gem to make the urls look nice, infact all the "gems" (project, tasks and users) will depend on this gem.
What would you recommend to do to have the kind of modularity I want? is it good practice? bad practice?
Pivotal Labs made a presentation (Euruko 2013 in Athens) and they showed a rails engines approach similar to what you are describing. Here is the presentation http://www.ustream.tv/recorded/35107339/highlight/377037
I haven't seen it in practice though, but I would like to.
I believe use of Rails engines is the way to go.
Each Engine can be an app in itself.
For instance Devise - gem that adds a lot of authentication functionality into your app is a Rails Engine. It provides its own controllers, helpers, mailers and views that you can use from your app.
I personally was working in projects that were using Engines to plugin i18n web backends (admin page that allows entering and saving translations to Redis) into many apps and to plugin users' bug reports and Question&Answer functionality into several existing projects.
Each engine is being included in a project as a gem, it can consist of anything that normal app does - controllers, views, models, assets, other gems...
I personally haven't heard of any success stories with such approach (but I don't know if anyone tried though), so if you have a solid concept in mind maybe it will work for you.
I'm rewriting one old app - Rails 1.2.6 :)) - completely in Rails 4... so you can imagine the information overload.
It's going quite well so far but I'm currently struggling with one task that should be pretty obvious but it lacks proper documentation and there are just too many blogs with different solutions to this issue.
I have a custom class with custom text conversion functionality (using Redcloth, autolinker, Sanitize etc.), let's call it Textilize class. It's used in models as well as controllers so I guess the best solution would be to create a gem from it. I want to attack gem creation later though since it's just a simple one-file class.
So for now I just added textilize.rb file to /lib directory and added config.autoload_paths += %W(#{config.root}/lib).
It works fine and I can now use it in the app without requiring it in the models and controllers.
Is this a good practice in Rails 4? Is it thread-safe?
If not, is there a way to refactor it without creating a complete gem for now?
Thanks!
"Is this a good practice?" I think it is.
"Is it thread-safe?" I don't know
Any other way? I will use your solution if the lib is crossing Model and Controller and it is simple. If it get rather complex, I will create a plugin. If it is complex and can be extended to be useful on other apps, I will create a gem.
I wanted to separate out common models (and their migration) out to a gem. I was wondering if I should an engine, or make a library gem for this purpose.
Thanks!
Engines are great for providing a full MVC stack. If you plan on adding more than common models it is a very clever move since it will add a lot of flexibility to your application.
Otherwise you may find the workflow over head to much compare to the functionality provided.
I'm looking for any pointers on how to write a rails web app without ActiveRecord.
A doc or an example of a (not too complex) web app using storage backends other than a relational database would be greatly appreciated.
It's not clear on what should be implemented in the model classes in order to make the rails app work without the ActiveRecord layer.
Thanks,
Of course it's possible, here, for example, MongoMapper is used instead of ActiveRecord:
http://railstips.org/blog/archives/2009/07/23/getting-started-with-mongomapper-and-rails/
Note that this will seem a lot easier with Rails 3. Rails team spent a lot of efforts on ORM agnosticism when pushing to beta. They've created a public API (ActiveModel) for different ORMs to implement, so that an ORM can serve as a drop-in replacement for ActiveRecord. That way you'll just be able to define models in terms of your ORM without any extra efforts.
DataMapper already has an implementation of ActiveModel in dm-rails, and there'll be more to come.
See this post by Yehuda Katz for details.