I have a Rails 2.3 application which I would like to extract into a plugin, or engine. The application has user authentication, and basic cms capabilities supported by ancestry plugin.
I want to extract the logic for the application into a plugin/engine so that I can use this code for future projects, with a different "skin" or "theme" if required.
I'm not entirely sure I actually understand the difference between plugin and engine concepts, so that would be a good first point.
What is the best approach, are there any good starting points, links, explanations, examples that I should follow. Also, with the release of R3 to consider, is there anything that I should be aware of for that, with regards to plugins etc.
I am going to start off by watching Ryan's http://railscasts.com/episodes/149-rails-engines
but obviously thats over a year old now, so one of the challenges I'm faced with is finding the most up to date and relevant information on this subject.
All tips and help gratefully received.
Actually, converting an application is pretty straigtforward. Just create a plugin-folder, put an app-folder inside containing all yor model-views-controllers folders, and that's it.
You will have to manage your migrations yourself though. Also you have to define rake-tasks to copy files to your public folder. I think the railscasts is still pretty up-to-date, if anything it is now easier in rails 2.3.
Good luck!
[EDIT: for rails3] Rails 3 engines are very clean and powerful. Check this gist by Jose Valim.
You will probably be better off focusing your engine on Rails 3, as opposed to trying to make it compatible for Rails 2 and Rails 3, due to the backwards incompatible changes. Here is a more up to date tutorial for Rails 3
also the book "Crafting Rails applications" by Rails Core member Jose Valim, has a good chapter on it. Int he shows how to use his tool EngineX which generates a Rails 3 engine structure, so you can more easily create engines for your Rails 3 projects. His gem devise is also a rails engine which is also nice, because you can easily customize it by copying the templates into the application directory, and allowing you to subclass the controllers that you want to customize more.
Writing a plugin is an entirely different process than writing an app, if you already have your app code it should be straightforward converting it into a plugin.
Consider that if you use third-party plugins in your app it could get pretty messy.
Related
THE PROBLEM
First a little bit of context: I am currently working as a freelancer, developping webapps using Ruby on Rails. Because I am working solo, the need to optimize my workflow is pretty important.
That's why I have always had the same question since I begun working with Rails:
How can I share code/configuration/conventions/tests between my apps?
More precisely, I want to share:
common gems that I always use, with their configuration
common integration tests, to ensure some conventions
common view helpers, test helpers, extensions to the core classes, javascript/sass partials
common files: .gitignore, git hooks, .eslintrc, configuration files of my CI etc
Some concrete examples of what I need in all my apps:
disable turbolinks by default, to add it later if need be
use javascript instead of coffeescript
use slim instead of ERB
install/configure capistrano
install a CSS framework (bootstrap, bourbon + neat + refills)
So far I don't really have the need to share models nor controllers.
I don't want to share behavior or functional components of the system itself, I am not looking for a micro-services architecture.
I have found that so far when creating new applications, all this setup work does take me a lot of time. Also, I would like to apply it retro-actively to existing apps when I add something new.
I have done quite a bit of research, but I haven't found a lot of answers. Many people are trying to share models, but few people seem to want to share a common ground between all their apps. Finding the right keywords may have been the problem though.
It seems to me that Rails is really good at DRY within an application, not so easy when trying to DRY between applications.
POSSIBLE SOLUTIONS
1 - Rails application template
The solution I am using right now, described in the Rails Application Templates guide, using the same API than the Rails generators described in the Creating and Customizing Rails Generators & Templates guide.
That's the solution used by Thoughtbot, with their popular suspenders gem. In the case of Thoughbot though, they have years of experience to draw from, have many employees and their common setup does not change that much.
Pros:
saves a lot of time when creating a new application
really nice API
Cons:
a lot of duplication: all the apps have the same common code, with the problem of this code getting out-of-sync
not retroactive: useless to add a common feature to already created apps
heavy maintenance work: my current workflow is to go through the git log of my apps once per month, and for each commit that could be common to all the apps I have, add it to the application template, and add it to the other apps manually
So far this solution is not that bad, because I only have two applications. But once I will have more, I will suffer from more and more overhead.
A better solution would be maybe to create a generator/rake task for every common new feature, to be able to apply it quickly to existing apps, and call it directly in the application template for new apps.
I haven't tried it though, and I am not really sure it will work. For example what if I want to propagate a one-line change in an existing common file in all the apps?
2 - Rails Engine
I have tinkered a bit with the Rails Engines to share code.
I have not understood from the Getting Started with Engines guide if I should better use a --full engine or a --mountable one for this specific purpose.
Pros:
once I update the gem version, all the changes are made available to the app
DRY: all the common code is in a unique place (the gem)
Cons:
the gems I would like to share are put in the *.gemspec file, which has not as many features as the Gemfile (from what I understand)
overhead caused by the need to update the version of the gem in all the apps, migrate to the new API of helpers, etc
no way to share non-rails files (.gitignore, git hooks, .eslintrc)
This solution has too many important shortcomings.
3 - Hybrid solution: Rails Application Template + Rails Engine
Maybe the best would actually to use both the above solutions.
In the gem share helpers and tests, in the rails template share the gems, their configuration/files and other files (for git, linters, etc)
It is indeed adding more complexity and overhead...
4 - Use git subtrees
Some people use git subtrees to share folders between multiple webapps.
Cons:
one has to share whole folders, not easy to share everything I would need, in their different target directories in the rails app
seems a bit "hacky" to me
Conclusion
Is there another solution than the ones I mentionned above?
What do you think would be the best way to do it?
How about having a blank "Master" rails app in the git somewhere. With all the settings and configurations you'd like to share. When creating a new app from scratch, you can merge the "Master" into it to apply the defaults. When you have an existing app, same thing, just merge and resolve conflicts as needed.This also gives you the ability to override the merged code if needed to.
Few things I can see wrong with this approach though:
Rails application name could cause a lot of headaches
Any updates could cause merge conflicts
I created a tool to deal with this when working in nodejs projects. But the tool is really just a command line tool so you should be able to use it.
https://github.com/tomasbjerre/dictator-builder
It is a concept with creating a dictator that dictates parts of your code base.
Backbone.js website has some examples. But barring the first one others are not open source. I am looking for a fully functional (meaning it just works) Rails application to study. The app does not need to have too many functionalities. I looked at github and all the apps are broken in some ways.
Recently i found https://github.com/malclocke/fulcrum and it seems to be the best Rails/Backbone example but its not mentioned on the backbone website. Its also a very functional pivotal tracker clone.
I have been working on some non open source projects that use a Rails and Backbone.js stack. Both frameworks can be integrated fairly easily. Of course, it depends on how the application is setup and how you configure each framework to control more or less business logic.
To get both frameworks to play with each other:
Make Backbone collections and models for each Rails model
Route resources for each Rails model
Setup the URL property for the Backbone collections and models to work with your rails routes
Use fetch() and save() in Backbone to get and post data with Rails
I wrote a german language noun trainer using RAILS and backbone.js. It was done a long while ago while I was still learning but you can peek at it if you want.
https://github.com/bradphelan/ohmyderdiedas
I've been actively working on Myelin: http://sourceforge.net/projects/myelin/ (funded from a corporate source)
There are some caveats:
This is essentially a first for me with every technology in there... from rails, to backbone / jquery / rspec... you name it... it's new, so take the code with some grains of salt ;)
I didn't use the Backbone routing, and built a very simple 'router' of my own.
You'll need ganglia and rrdtool installed (macports if you're on a mac should work)
You'll need to alter the development config for sure.
The models, are (mostly) straight up backbone, and I use sync often in the controllers so those should be pretty good examples.
The views are a little more chaotic.
If anyone needs help with anything, just drop a line to me on sourceforge.
There's now a gem in development that provides generators, called rails-backbone. It's Open Source and getting better every day. As of today it's up to date with current Rails 3.1 (actually 3.2 now), esp. including Asset Pipeline, which is very relevant to backbone.js.
I see a lot of people asking about Blog Engines, but most of the questions & answers are rather old. Or if they aren't old most of the projects are old. I'm wondering if anyone knows of any Blog Engines that currently support Rails 3.1 or are at least being actively developed to support Rails 3.1.
I would also be interested in seeing any sample applications or blog posts written for Rails 3.1 Blogs. I am going to be adding a blog to one of my websites, and would prefer to simply use a Rails Engine or sample code if there are any good ones out there. I hate reinventing the wheel. Looking for something simple, and not too opinionated so I can modify easily to suit my own needs.
you might want to check out Refinery http://refinerycms.com/engines
doesn't look like they are 3.1 yet, but probably soon
https://github.com/resolve/refinerycms-blog
Your best bet would probably be to use Typo.
Typo is currently using rails 3.0.9. Rails 3.1.0 is still a release candidate so I don't know of any blogging apps using it right now. If you must use rails 3.1.0 then you may have luck grabbing the gem for 3.1.0.rc4 (the newest version) and using typo anyway. Chances are everything will still work.
Hope this helps.
Perhaps Enki is a good fit, currently at Rails 3.0 but there is a github branch with Rails 3.1 support.
http://www.enkiblog.com/
Interestingly BrowserCMS was recently made to be a mountable engine: https://github.com/browsermedia/browsercms/commit/6098699fed2e3dbd65815ac3a5ce0dd6acc103d2
Seem to have a bit of time and experience behind them. More akin to Concrete5 with an inline front end / in context editing facility for users, which can be a real plus.
Im looking into this now and Im getting to conclusion that the best way to do this would be mounting a rack-app(like sinatra) into your rails app, there's various basic sinatra blogs in github to start or copy, not to mention this is fully customizable and I guess very light-weight.. engines will likely have dependencies and may also break when updating gems, a rack app won`t
I wasn't able to find any satisfying solution with engines
other stuff I found:
mounting a rails app inside a rails app: http://blog.dynamic50.com/2010/02/22/rails-3-0-mount-multiple-apps-as-engines/ feels a bit weird(heavy?), but you could mount a fully featured app like enki...
http://planscope.io/blog/2012/03/08/mounting-a-blog-within-a-rails-3-application/ this blogpost talks about using Toto, it seems pretty nice, easy and simple... but the project is not being maintained and it doesn't seem to be able to support a lot of features...
I dunno about using git to post, it makes it really simple but I dunno if I'd like having non-code stuff in my commits
Monologue https://github.com/jipiboily/monologue . From their web:
It is a barebone blog engine for Rails. It is built as a Rails engine and with a focus on keeping very few dependencies to ease it's use in your project. You can also use monologue-markdown which will replace the default editor with a simple Markdown editor.
Seems like pretty active development also.
Some ruby gems like jekyll, toto and webby offer out of the box blog-type integration into your ruby app. Another way of developing a rich web blog-type application is to build and model the application yourself using pure ruby and rails practices. (e.g creating an Article and User model). The first offers out of the box features the 2nd option offers more customization and control.
In people's experience on Stack Overflow, which would be the best route and what would people consider when making the decision to use a gem out of the box versus going alone?
All of the gems you mentioned take static, markdown/textile/etc files and turn them into HTML websites. They take different approaches to it, with jekyll spitting out the finished website for hosting, toto doing the converting and routing on request, and webby doing the same as jekyll mostly.
If you're using Rails, it's important to note that none of these will integrate into your application well. They're built to more-or-less operate on their own.
Generally speaking, if a gem has the functionality you need, use it. They are not equivalent to plugins you find for Wordpress and Drupal where they are typically low-quality, buggy, poorly documented, etc. More often than not, gems simply add a couple modules that you can integrate into your application how you like.
On the other hand, a basic blog is pretty quick and simple in Rails, especially considering you've got a handy walkthrough guide straight from the Rails documentation on how to do it.
If you're new to Rails and want tight integration with your app, it's probably best to bake your own blog features.
This will take some time to do, but its worth it to learn how things really work.
If you're more seasoned, just look at the gem's API and documentation and decide if it does what you want it to do and if you're comfortable with how to integrate it. If so, it'll save you time.
One other consideration: who will be using the blog? Is it for internal use, and programmers will be the ones updating it? If that's the case, then you can make it very easy by not worrying about a lot of aesthetic polish in the back-end. Conversely, if you're making an app that includes a blogging component for the general public you might want it to feel more polished. In this case a gem might save you a lot of time.
It depends on your application.
Does Rails 3 have anything akin to slices in Merb, or areas in Django where there is a layer of organization above the controller? I heard at some point that they may allow hosting one rails app within another but I can't find any information on that in the pre-release material. Any hints on how to do something like this?
You're right there doesn't seem to be a lot of official documentation on it yet. But yes, you can have application slices -- they're called engines in Rails. Actually they've been available in Rails since 2.3. Currently, you basically make a plugin that has a complete application structure and set up your routes in there to "mount" your app against a specific URL. In Rails 3, engines are basically first-class objects in the Rails stack. I believe they can still be plugins but you will also be able keep it away from your application in a separate gem and require it in your application much more easily. You should be able to find stuff pretty easily on teh Google, but here's an oft-linked but informative reference: https://gist.github.com/af7e572c2dc973add221