"-j" parameter to select vendor javascript library when starting new Rails app

[siong1987]

so, for now, we have a "-d" parameter when starting up a new Rails
application with options like "mysql", "sqlite3", etc.

do you all think that is it a good idea to have a "-j" parameter that
could get options like "jquery" and "prototype" so that the preferred
javascript library is used when starting up a new Rails app?

siong.

[Lailson Bandeira]

This would be great!

--
LAILSON BANDEIRA
http://lailsonbandeira.com/

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

[Teng Siong Ong]

how others think about it? if someone from the core team could verity this issue, i will go ahead and implement it.

[Teng Siong Ong]

patch added: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/5613-adding-j-parameter-for-rails-new-command

for this patch, i removed the usual "--skip-prototype" parameter and substituted it with the "--skip-javascript" parameter. then, i added a new "-j" or "--javascript" parameter. this parameter accepts either "jquery" or "prototype".

btw, the default javascript library now is still "prototype".

siong.

[Yehuda Katz]

Can you submit this as a pull request on GitHub?

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

[radhames brito]

Great!!!

[Teng Siong Ong]

pull request sent.

side note: i actually asked this question in the irc channel, in future, should we keep using the old school patch way or the github pull request way to patch?

siong.

[Yehuda Katz]

I can't speak for the rest of the core team, but I personally am keeping a close eye on pull requests, which are much easier for me to work through than dealing with patches on LH (which require saving the patch, seeing if it applies, then reviewing, etc. etc.). Pull requests telescope the first 5 or 6 steps of reviewing patches on LightHouse into one step.

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

[Teng Siong Ong]

i actually +1 for github pull request. they just made it a lot easier to use now. btw, my pull request has already been sent in. feel free to leave comments there. :)

siong.

[Michael Koziarski]

> i actually +1 for github pull request. they just made it a lot easier to use
> now. btw, my pull request has already been sent in. feel free to leave
> comments there. :)

The most important thing for pull requests to get right is to make
community members (e.g. non committers) able to comment / review a
pull request. It seems the latest github release has done a pretty
good job with that.

--
Cheers

Koz

[Teng Siong Ong]

btw, let's get on the topic here. it seems like we should discuss about whether we should include jquery as one of the default options in rails. if you actually look at the commit i did. the commit doesn't actually complicate the code much.

and, one obvious thing that everyone should have noticed recently is that more and more people prefer to use jquery as the default javascript library for rails. and, i think that is one of the reasons why the introduction of "config.action_view.javascript_expansions" in the latest rails 3.

so, i really think that this patch should be committed. i really want to see how other core members think about this.

siong.

--

[Ryan Bigg]

Bonus: Github pull requests aren't full of spam like the lighthouse. I don't see what lighthouse offers that github issues doesn't.

[Ryan Bigg]

Whilst it's obvious now that jQuery is the preferred library, there are a lot of applications already using prototype. I think because of this reason, the default should stay as Prototype.

Your patch to pass an option to switch to jQuery for a new application is fantastic.

[Chad Woolley]

On Sat, Sep 11, 2010 at 6:03 PM, Ryan Bigg <radarl...@gmail.com> wrote:
> I don't see what lighthouse offers that github issues doesn't.

Search that actually works?

[Yehuda Katz]

Just to be clear, I'm in favor of pull requests for patch management;
don't have a strong opinion about bug reports (yet)

Sent from my iPhone

[Rodrigo Rosenfeld Rosas]

Github (or Gitorious) is certainly better for dealing with patch
reviews, but I would rather prefer Redmine over LH for issues
management. And it also have good integration with git repositories...
Furthermore there are plugins for dealing with Scrum or Kanban with
great interface. Redmine also supports sub-projects, several kinds of
reports and lots of great features and useful plugins...

Maybe we should create a new topic on this subject and another one for
discussing the default Javascript library...

Best regards,

Rodrigo.

[Teng Siong Ong]

since when this has become a discussion about LH vs Github? man, stay focused! : )

Jose Valim has closed the issue, maybe we should seriously think about the "-j" parameter for the "rails new" command.

http://github.com/rails/rails/pull/16 < let's start the Github reviewing party here. : )