I have a few months of experience with Ruby on Rails and really loved it from the beginning on. Now, for work, I was asked to code in Grails and although I first had some objections, I now think it's a very decent framework.
One thing that really impressed me in Grails are Taglibs because they make frontend modularity so much easier.
I would really like to do something with Rails.
Is there anything like Taglibs for Rails?
If not, what are the best practices for accomplishing this kind of view modularity (and, in essence, making my life easier)?
You can build your own helpers and the views can access those helpers. Take as an example formtastic, which provides extra methods/tags to build forms.
Strictly speaking, formtastic is a rails plugin, but it follows the same principles.
Related
Like most rails folks my restful controllers stick to a very consistent pattern, and any changes are rarely more than an extra line or two.
I like to test (using RSpec) fairly thoroughly, and that includes assigns, responds, redirects etc in controller tests.
The thing is, 75% of my controller specs follow the exact same pattern, and an obvious step seems to be to refactor them into a method/set of methods that I can call from each spec....either with a single (for example) 'restful_controller_specs' call, or individual 'restful_index_specs', 'restful_show_specs' etc for actions if the resource isn't completely standard.
And yet, when looking at other people's projects, from what I can see nobody else really seems to do that.
So in short, am I missing a good reason as to why not to agressively refactor restful controller specs?
I think most rails developers have learned programming by learning rails, which is not the ideal way to learn how to program, so things like refactoring are not a concept they have learned or encountered. Many people don't realise that files like config/routes.rb and db/migrate/* are just ruby code, and you can add loops and arrays and classes and subclasses into them as you need, just like any ruby program.
To all the rails coders out there: learn ruby! learn it well! It's a real programming language! Rails is made entirely of ruby.
I have a rails app that has pretty standard things, except for two pages that require a lot of JS.
I was wondering if it's a good choice to use ember just for those two pages while keeping Rails standard for everything else? Or should I rewrite everything in emberjs + rails as API backend?
This is really a case-by-case situation. Why do those two pages require a lot of JS? The answer is probably "because of an implementation decision you made." Adding Ember to the mix is probably going to prompt you to revisit a lot of implementation decisions to reconsider which tools are appropriate to use in which places.
I have a project going on, and I am in charge of the front-end design, whereas my developers will work on the back-end with Ruby on Rails.
I do not know Ruby on Rails, and am designing front-end using XHTML, CSS, jQuery, 960.gs CSS Framework. My developer is supposed to take my design and connect the elements of back-end to it, with Ajax too.
What are the things that I should know while designing the template/view so that I won't kick my developers' asses with my design? How to help the connecting of elements painless? I understand I must avoid . Some Ruby on Rails developers also prefer Blueprint CSS Framework over 960.gs.
Any guidance? Thanks.
Generally the Rails templating system is quite flexible and will enable developers to create even complex designs. The CSS framework should not make such a difference. However if they are using Rails 2.x it is markedly easier to use Prototype instead of jQuery. However Rails 3.x is also agnostic to javascript library.
A relatively good overview is the official guide. You might also try out this tool for cutting up your views and layouts.
I can speak from the developer point of view.
The things that piss me off are too complicated css structures, keep it simple and abstract as you can.
The other things is naming classes and ids, in general try to find out what models the developer is using and name your classes and ids accordingly. E.g. for a blog with posts:
#posts .post for a post in the index view and #post for a post in the show view.
I never care what css framework the designer uses, as long as it works.
And lastely, if you design different html pages, be aware that we often have only one or two layouts, that's eg. /views/layouts/application.html.erb and we usually try to keep that number low as possible.
jQuery is find, ever been my preferred choice over rails' own prototype.
I have been spending some time creating what I called a framework.
It was aimed at the creation of quiz likes games. It was supposed to have two players syncronized and present them a question to solve, etc.
I would like it to be fully customizable so I tried to develop components that can be put in or out of the pages. In the end the elements became slim ruby methods to add a whole bunch of Javascript and CSS to the pages.
Still the Javascript needs to connect to Ruby so methods supporting it are created but they will only be present when the component is present. Some components depend on one another making everything overly complex.
And after this attempt I wonder, is there is not a better and easier way to make a framework aimed to one kind of application on RoR? Or is the concept flawed or RoR in some way flawed?
Ruby on Rails is a framework on its own accord and is "opinionated software". This means that the writers of Rails looked at what would make most sense for creating a web application to them. Many people support the original developers views and so use Rails for their projects as well.
I think your concept of creating a quiz is a good one, but first you need to understand the rails stack. Depending on what you need exactly, you can create either an engine, plugin or whatever.
What I have seen a lot is that you specify what you need in your controller. (How you do that is up to you). All that information is stored in a class variable and transferred to the view where you can render everything you need with some helpers. The hard part is making it all generic enough to be reusable.
But, maybe Rails isn't the right tool for you. Maybe you need something more lightweight like Merb or even Sinatra.
There is no 'flaw' in Rails. Rails is not the 10**1000-in-one tool Java is. It's a framework that tries to do one way very good in a particular way. I think Rails can be the right tool for you, but you need to be skilled enough to wield the tool :)
I'm looking for a way to modularize Rails applications. As I've seen there is no built-in way of accomplishing it. I've found different plugins/core hacks but I feel untrusted about the way they work and their maturity.
Do you have any experience on this?
So far I found this ones:
Desert: http://github.com/pivotal/desert
Rails engines: http://rails-engines.org/
Rails engines are part of the current stable rails 2.X and so aren't really "hacks" anymore. They seem like a good fit if you want to add fairly course-grained application functionality to an application - a good example might be adding a blog or CMS-style functionality to another application. Checkout the railscast on engines here: http://railscasts.com/episodes/149-rails-engines
If you're looking to modularize on the front end - more "widget" style, you might want to look at cells: http://github.com/apotonick/cells/