Rails Generator --singleton

err typo. Should be 'loading up /post' (not posts)

I've attached a patch that removes <%= link_to 'Back', posts_path %> from the edit and new actions' views when using the generator with the --singleton option for master.

It includes tests for this specific change and some tests for running the generator with the --singleton option, since they didn't exist yet.

There were some unnecessary tests in test_singleton_scaffold_on_invoke that I directly copied from test_scaffold_on_invoke and some trailing whitespaces in my previous patch. Here's a new one. :)

Aaand another one. This is the same as the previous patch, but adds parentheses around the arguments of the assert_match calls to avoid warnings when running the tests (Like I did for the rest of the scaffold_generator tests in #4872 "ambiguous first argument" warning in `test/generators/scaffold_generator_test`). :)

Thanks José, I've updated my patch and changed the views like you explained in your first note. The previous way of doing it was to keep the generated view exactly the same as before, but I think I like your approach more after all.

About your second note: I'll check that out and will create a new ticket if find something, but that doesn't really have anything to do with this patch, right?

Oh, now I see why you used the previous syntax, to keep the generated view pretty. Maybe we could do it inline? Something like this:

<%%= link_to 'Show', @<%= singular_name %> %><% unless options[:singleton] -%>  | <%%= link_to 'Back', <%= plural_name %>_path %><% end -%>

Sorry that I missed it earlier. :(

And about the paths, it's related to this patch, because if the following is not valid for a singleton resource:

<%%= link_to 'Edit', edit_<%= singular_name %>_path(@<%= singular_name %>) %>

It means it should output this instead:

<%%= link_to 'Edit', edit_<%= singular_name %>_path %>

I actually found out some more bug with it, will provide another patch soon ..

Urgh.

I actually stumbled across the usability bug of this patch on the controller side. Consider this snippets generated:

class TopicsController < ApplicationController

  # GET /topics/1
  # GET /topics/1.xml
  def show
    @topic = Topic.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render :xml => @topic }
    end
  end

  # GET /topics/new
  # GET /topics/new.xml
  def new
    @topic = Topic.new

    respond_to do |format|
      format.html # new.html.erb
      format.xml  { render :xml => @topic }
    end
  end

  # GET /topics/1/edit
  def edit
    @topic = Topic.find(params[:id])
  end

  # POST /topics
  # POST /topics.xml
  def create
    @topic = Topic.new(params[:topic])

    respond_to do |format|
      if @topic.save
        format.html { redirect_to(@topic, :notice => 'Topic was successfully created.') }
        format.xml  { render :xml => @topic, :status => :created, :location => @topic }
      else
        format.html { render :action => "new" }
        format.xml  { render :xml => @topic.errors, :status => :unprocessable_entity }
      end
    end
  end

  # PUT /topics/1
  # PUT /topics/1.xml
  def update
    @topic = Topic.find(params[:id])

    respond_to do |format|
      if @topic.update_attributes(params[:topic])
        format.html { redirect_to(@topic, :notice => 'Topic was successfully updated.') }
        format.xml  { head :ok }
      else
        format.html { render :action => "edit" }
        format.xml  { render :xml => @topic.errors, :status => :unprocessable_entity }
      end
    end
  end

  # DELETE /topics/1
  # DELETE /topics/1.xml
  def destroy
    @topic = Topic.find(params[:id])
    @topic.destroy

    respond_to do |format|
      format.html { redirect_to(topics_url) }
      format.xml  { head :ok }
    end
  end
end

There're some issues from this generated controller:

1. On the show and edit option, the params[:id] would not be assigned, as the URL for it would be /topic. So, what would be the best record to shown here? Topic.last?
   
2. On the destroy action, what should we redirect the user to after destroyed? I mean, I know everybody will change it, but what would be the best? redirect_to '/'?

I'd love to discuss more about this. ;)

BTW, I've found out there's a bug in the _form.html.erb generated by the generator. I've attached the replacement patch to fix it.

Hey Prem! Nice work!

About the controller, I don't think there is anything we can do to make it work by default. Usually, singleton resources are nested or depend on something in the session. That said, maybe we could show a message to the user saying that singleton only provides a stub, he still needs to work on controller + tests in order to have it working.

What do you think?

Urgh ..

So, after a long discussion with José, it turned out that we should remove the --singleton option for the time being. Because of:

1. Singleton resource usually tied to another resource. For example, User has_one Profile. The controller generator doesn't actually know how should it find profile object. So, the test will be failed.
   
2. I've tried to add argument to the --singleton option, to be --singleton=current_user. It turned out to be more ugly, and there're too many conditions going on in the controller file itself, make it hard to maintain.
   
3. I've also tried stub out the find method as José suggest, but then the test case provided with the scaffold will be fail. This is not good, as some user expects the test cases to be pass after they generate the scaffold.

I've proposed to make another generator as well, such as rails g singleton_generator current_user profile fullname:string, but then I don't think it would be welcomed by the core team. So maybe it could come as the plugin.

So, thanks to everybody who's involved in this ticket, especially Jeff. I'm sure we'll find out the best solution soon.