Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

destroy administrate:views not working #310

Closed
masciugo opened this issue Dec 9, 2015 · 2 comments
Closed

destroy administrate:views not working #310

masciugo opened this issue Dec 9, 2015 · 2 comments
Assignees
@c-lliope
Milestone
v0.1.3: Generator...

Comments

@masciugo
Copy link
Contributor

masciugo commented Dec 9, 2015

it seems that generate and destroy do the same thing:

masciugo@macbookpro ~/dev/ffm $ rails generate administrate:views Course
      create  app/views/admin/courses/index.html.erb
      create  app/views/admin/courses/_collection.html.erb
      create  app/views/admin/courses/show.html.erb
      create  app/views/admin/courses/new.html.erb
      create  app/views/admin/courses/_form.html.erb
      create  app/views/admin/courses/edit.html.erb
   identical  app/views/admin/courses/_form.html.erb
masciugo@macbookpro ~/dev/ffm $ rails destroy administrate:views Course
   identical  app/views/admin/courses/index.html.erb
   identical  app/views/admin/courses/_collection.html.erb
   identical  app/views/admin/courses/show.html.erb
   identical  app/views/admin/courses/new.html.erb
   identical  app/views/admin/courses/_form.html.erb
   identical  app/views/admin/courses/edit.html.erb
   identical  app/views/admin/courses/_form.html.erb
@c-lliope
Copy link
Contributor

c-lliope commented Dec 9, 2015

@masciugo interesting. I haven't used the destroy command before. I assume it's intended to delete the same views that the generate command creates?

@masciugo
Copy link
Contributor Author

ya. It magically works for the other adminstrate generators

@c-lliope c-lliope added the ready label Dec 15, 2015
c-lliope added a commit that referenced this issue Jan 20, 2016
@c-lliope
Let users undo the administrate:views generator
3870e47 
Fixes #310

Problem:

Rails provides a way to undo the effects of generators,
by running the command `rails destroy GENERATOR_NAME`.

With the way that we had set up our hierarchy of generators,
Rails did not know how to undo the effects of sub-generators.

For example, with the `administrate:views` generator,
we were calling `Rails::Generators.invoke("administrate:views:index")`.

Whether the generator was run with the `generate` or `destroy` command
did not make a difference -
the index generator would always be invoked
as if it were run with `generate`.

Solution:

Rails generators use the `@behavior` instance variable to keep track of
how the generator was run.
This variable can be either `:invoke` or `:revoke`.

Pass this variable as an option to the sub-generators
to ensure they have the same behavior as the parent.
c-lliope added a commit that referenced this issue Jan 20, 2016
@c-lliope
Let users undo the administrate:views generator
aaec23f 
Fixes #310

Problem:

Rails provides a way to undo the effects of generators,
by running the command `rails destroy GENERATOR_NAME`.

With the way that we had set up our hierarchy of generators,
Rails did not know how to undo the effects of sub-generators.

For example, with the `administrate:views` generator,
we were calling `Rails::Generators.invoke("administrate:views:index")`.

Whether the generator was run with the `generate` or `destroy` command
did not make a difference -
the index generator would always be invoked
as if it were run with `generate`.

Solution:

Rails generators use the `@behavior` instance variable to keep track of
how the generator was run.
This variable can be either `:invoke` or `:revoke`.

Pass this variable as an option to the sub-generators
to ensure they have the same behavior as the parent.

Minor changes:

Extract `Administrate::GeneratorHelpers` to store common
generator-related methods.
@c-lliope c-lliope mentioned this issue Jan 20, 2016
Merged
@c-lliope c-lliope self-assigned this Jan 20, 2016
c-lliope added a commit that referenced this issue Jan 20, 2016
@c-lliope
Let users undo the administrate:views generator
c78edcb 
Fixes #310

Problem:

Rails provides a way to undo the effects of generators,
by running the command `rails destroy GENERATOR_NAME`.

With the way that we had set up our hierarchy of generators,
Rails did not know how to undo the effects of sub-generators.

For example, with the `administrate:views` generator,
we were calling `Rails::Generators.invoke("administrate:views:index")`.

Whether the generator was run with the `generate` or `destroy` command
did not make a difference -
the index generator would always be invoked
as if it were run with `generate`.

Solution:

Rails generators use the `@behavior` instance variable to keep track of
how the generator was run.
This variable can be either `:invoke` or `:revoke`.

Pass this variable as an option to the sub-generators
to ensure they have the same behavior as the parent.

Minor changes:

Extract `Administrate::GeneratorHelpers` to store common
generator-related methods.
c-lliope added a commit that referenced this issue Jan 22, 2016
@c-lliope
Let users undo the administrate:views generator
1146204 
Fixes #310

Problem:

Rails provides a way to undo the effects of generators,
by running the command `rails destroy GENERATOR_NAME`.

With the way that we had set up our hierarchy of generators,
Rails did not know how to undo the effects of sub-generators.

For example, with the `administrate:views` generator,
we were calling `Rails::Generators.invoke("administrate:views:index")`.

Whether the generator was run with the `generate` or `destroy` command
did not make a difference -
the index generator would always be invoked
as if it were run with `generate`.

Solution:

Rails generators use the `@behavior` instance variable to keep track of
how the generator was run.
This variable can be either `:invoke` or `:revoke`.

Pass this variable as an option to the sub-generators
to ensure they have the same behavior as the parent.

Minor changes:

Extract `Administrate::GeneratorHelpers` to store common
generator-related methods.
@c-lliope c-lliope removed the ready label Jan 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@c-lliope c-lliope

Labels
None yet
Projects
None yet
Milestone
v0.1.3: Generator improvements
Development

No branches or pull requests
2 participants
@masciugo @c-lliope