datetime_select
A chunk of code (just like the one above) was throwing an exception that said:
ArgumentError: wrong number of arguments (1 for 2)
date_or_time_selectthat was being invoked; inside the
datetime_selectmethod.
attr_lockedwas doing it via
alias_method_chain. The problem was that, this overwrite didn't provide the correct number of parameters for the Rails 2.1 version (the Rails 2.1 version of
datetime_selectaccepts an extra hash parameter called html_options). We made some little changes to the current implementation and it worked as expected.
Hope you can get some benefits from this patch
]]>Recently, one of our customers wanted to have a mockup of an application. We thought at first to use Rails to make this mockup, but suddenly we realize that it was overkilling to create models and controllers when the requirements are not clear enough.
Once we decided not to use Rails to do this task, we did study some Ruby CMS around the Web. The different options we came around were:
As you may guess, I went to the option of Webby, it seems the more middle-size CMS made in Ruby that offers a lot of options and is easy to configure.
If you want to provide more observations on the comments section, is highly appreciated, I did not make a deep study on the others CMS, so maybe I'm missing some pros on each of them.
]]>TypeError: $$("#admin__operator_details-update-151-form a.cancel").first().link is undefined$$("#admin__operator_details-update-151-form a.cancel").first().link.close_with_refresh();The issues is already reported as #553
The summary is that the problem lies within the deprecated getElementsByClassName function in the active_scaffold.js.
To fix (thanks to Eric Bjorkvall) just replace in files:
/public/javascripts/active_scaffold/default/active_scaffold.js/vendor/plugins/active_scaffold/frontends/default/javascripts/active_scaffold.jsInstead of replacing the original assets of ActiveScaffold I skipped the change on /vendor/plugins/active_scaffold/frontends/default/javascripts/active_scaffold.js and just comment the /vendor/plugins/active_scaffold/init.rb in order to avoid the copy assets on plugin initialization.
Reorganize your view structure if the project doesn't follow the Rails golden path
A lot of people tries at all costs to adapt their code to the Rails organization, that shouldn't be always the case. There will be times when you will have a same partial, shared in more than one controller. This normally causes some questions about why the partial is in this controller and not in the other, the simple answer to that question would be: "the partial is in the controller X because it was the first one who used it".In this cases, you should keep a shared folder inside the views folder, this way you'll know that the partial doesn't belong to any controller at all, is just a shared view between lot's of controllers. If you notice that your shared folder is starting to get fat, organize partials that have common purposes in sub-folders, this way you won't be lost when looking for a shared partial with a particular purpose.
Then, when rendering a partial, you would do something like
Here we have shared partials that are being used in the header sections of lot's of controllers. This way you keep an order in your views that is more comfortable and more understandable.
In your partials, use helpers as much as you can
When you have partials, is probably because you repeat the same view in a lot of places. The thing is that you normally would like the partials to behave differently in some cases, say you want the URL's of the partials of a profile to point somewhere else or not to point anywhere at all (when you have a public profile for example). In this cases the best thing you can do is use helpers for returning the URL's.
You shouldn't bother with lots of if's and else's when the sweet polymorphism can do the job quite easy, just overwrite the method in the controller's helper and the partial will behave differently on each controller it is called1.
So for example, Imagine we have a profile section, and you have 2 versions of this profile, the public version, and the private version. This versions have a lot of things in common in the view side, but when we are in public profile, all the links points to a link of a public section, while when on private profile, the links point to private sections.
The view on the partial (shared/header/month.html.erb) would be something like
Now, when we are on the public controller, the helper should behave like
And on the private controller, the helper should behave like
Here we are letting the polymorphism of the helpers solve the view repetition, by just providing a method that behaves differently depending on where we are standing.
Parametrize... ALWAYS
Programmers are lazy, and there is nothing wrong with that, but sometimes this laziness can give us some nasty moments, it all starts with: "why pass it as a parameter? Just access it via the current_user, or the @instance_variable and you won't have to pass parameters every time you invoke this helper/partial".
This will give you more problems than benefits at the end, just imagine what would happen if the helper method/partial would work for every user we would like to, but it only calls the current_user?. This is when refactoring comes along and we change the current_user for a parametrized user, the thing is that you call this refactored method like 150 times. There is when you say... "damn, it would be easier if I just passed the user as a parameter from the beginning". Always keep in mind that the more you use your global environment, the less reusable is your code.
Don't to use instance variables in the partials (change them with the :locals option), nor to use instance variables on the helper modules if they are not being used only in the module for private logic (pass the objects as parameters to the functions).
I hope this 3 tips can help you get a better start when coding views.