hitfox / foxinator-generator Goto Github PK

this gem is maintained, in oposite to https://github.com/pluginaweek/state_machine

Example:

      resources :workflows, only: [:show, :index] do
        member do
          Workflow.state_machine.events.map(&:name).each do |event_name|
            patch event_name
          end
        end
      end

should look like:

      resources :workflows, only: [:show, :index] do
        member do
           statemachine_member_actions only: [], except: []
        end
      end

this should look like:

class CommentMailer < ApplicationMailer

  def admin_mention(comment)
    @comment = comment

    mail(to: @comment.admins.pluck(:email), subject: t('.subject'))
  end

end

This is more of a question than an issue.

• If Comfy is essential to the Foxinator gem, it should be a dependency.
• If Comfy is not essential to the Foxinator gem, it should be completely separate.

Could you explain what the relationship here is?

If there's a dependency between the two, shouldn't our gems be versioned/tagged?

For the CMS, so that nested models are nicely displayed:

Grandparent > Parent > Child

After going through all the steps of foxinator:setup and running the migrations manually, opening the rails app just gives an error. I would expect the setup to

• Generate a site skeleton
• Generate an admin use

@DemitryT I was thinking if it makes sense to expect foxinator to "work out of the box" or if "works out of the box" is only a requirement for the suspenders.

If comments are activated, the label for the comment input field ("message") is not translated.

Our Admin interface has a hidden feature: write as a comment "[email protected] is a super cool guy" and if an admin with email [email protected] exists, he will be notified via email that he was mentioned in a comment.

Well, that works of course only if we include the "CommentMailer" into the project upon setup, which seems to be missing. When setting up a new app, we must add the following files:

'app/mailers/comment_mailer'

class CommentMailer < ApplicationMailer
  def admin_mention(comment)
    @comment = comment
    mail(to: @comment.admins.pluck(:email), subject: t('.subject'))
  end 
end

'app/views/comment_mailer/admin_mention.html.haml'

%pre= @comment.message.html_safe
%br
= link_to t('.comment_link'), admin_admin_url(@comment.commentable, locale: I18n.locale), target: :blank

then add to the translations:

en:
  comment_mailer:
    admin_mention:
      comment_link: Take me to the comment
      subject: You were mentioned in a comment

On the Clark project, entered
{{ cms:helper:row_8:<p class='center'>whatever ".</p> }}
into an email template that uses cms_email_snippet. After saving and trying to view the email, It causes the error wrong number of arguments (0 for 1) on the line = cms_email_snippet in the email's html template file. After that it is impossible for an admin to recover because the page is always having a template render error.

There is one partial in the base folder that is called "_right_column.html.haml". It contains code valid for all views in the admin interface and additionally renders a "_right_column_after.html.haml", which accommodates custom code for different models. Currently, each call of the foxinator create method generates a right_column, not a right_column_after. This should be changed.

Additionally, the "_right_column_after.html.haml" partial depends on a helper called "collection?", which is currently not generated by the foxinator setup command.

My choice is: https://github.com/state-machines/state_machines-activerecord
add this to Gemfile or so

gem 'state_machines-activerecord', '~> 0.2.0'

This concern should give you the referer path. It is parse through the roites of the current app.

module BackRedirectify
  extend ActiveSupport::Concern

  included do
    helper_method :back_or_default_path
  end

  def back_or_default_path(default_path)
    referer_path || default_path
  end

  def referer_path
    return if request.referer.blank?

    routing_hash = Rails.application.routes.recognize_path(request.referer)
    referer_uri = request.referer.dup.delete(['?', URI.parse(request.referer).query].join)

    request.referer if url_for(routing_hash) == referer_uri
  rescue
    nil
  end
end

After we included the concern, we can add this line to the roles controller

  def sync_and_permit
    Permission.sync_and_permit_admins!
    redirect_to back_or_default_path([current_namespace, resource_class]), notice: t('flash.success', action_name: t('sync_and_permit'))
  end

  def sync
    Permission.sync
    redirect_to back_or_default_path([current_namespace, resource_class]), notice: t('flash.success', action_name: t('sync'))
  end

change:

args.last.kind_of?(Hash) && args.last.extractable_options? ? args[-1] = options : args << options

to:

args.last.kind_of?(Hash) && args.last.extractable_options? ? args[-1] == options : args << options

When you run rails g foxinator:setup, you're prompted on screen to perform some manual steps by the devise generator:

• Ensure you have defined default url options in your environments files
• Ensure you have defined root_url
• Ensure you have flash messages in app layout

If any of these are actually necessary, can we have our setup perform them?

A lot of migrations are generated by the different steps of the foxinator:setup and I'm asked to run them manually. Can't we run the migrations automatically at the end of foxinator:setup?

This gem uses state_machine (version 1.2.0) and state_machines-activerecord (version 0.2.0) explicitly. state_machines-activerecord has a dependency on the state_machines (version 0.2.0). (Note, one is machines, the other is just machine)

So, using the current version of the foxinator generator adds two StateMachine gems, that both use the same syntax for state machines.

We do some checks if a given class includes a state machine and when using hte current version of foxinator generator, it is not clear which of the following is correct:

resource.class.include?(StateMachine::InstanceMethods)

resource.class.include?(StateMachines::InstanceMethods)

I do not really want to check for both ;) So, would it be possible to settle for either state_machine or state_machines?

//cc @declarus

Add flash messages in roles controller:

def sync_and_permit
Permission.sync_and_permit_admins!
redirect_to [current_namespace, resource_class], notice: t('flash.success', action_name: t('.sync_and_permit'))
end

def sync
Permission.sync
redirect_to [current_namespace, resource_class], notice: t('flash.success', action_name: t('.sync'))
end

with this are base sites like /en, /de meant.

generation commands for just:

• model creation
• controller creation
• test creation
• view creation

so even existing model, etc. can be expanded with foxinator generators.

maybe a structure like:

rails g foxi:model name:string:index
rails g foxi:controller admin/somethings

To fulfill its purpose the change-log shouldn't be empty. Please include the change-log for the latest version (0.0.30).
Please ensure that you write the change-log for the last version (0.0.30), not the last date that you worked on it. User's won't know when they updated a gem, but they can always check which version they have and then find out what they could gain by upgrading.

Add:

        def create_model
          table_name = name.parameterize('_').tableize
          migration_template 'migration.rb', "db/migrate/create_#{table_name.pluralize}.rb"
          template 'model.rb', "app/models/#{name.singularize}.rb"
        end

in:
https://github.com/HitFox/foxinator-generator/blob/master/lib/generators/foxinator/scaffold/model_generator.rb#L29-L32

the template:
https://github.com/HitFox/foxinator-generator/blob/master/lib/generators/foxinator/scaffold/templates/migration.rb

should be replaced with:

class Create<%= class_name.gsub('::','').pluralize %> < ActiveRecord::Migration

  def change
    create_table :<%= table_name.pluralize %> do |t|
    <%- model_attrs.each do |attr| -%>
      t.<%= attr.type %> :<%= attr.name %>
    <%- end -%>
      t.timestamps
    end
  end

end

It can be found in the models directory.

This give us the ability to count on top level collection without having any filters ot nestings applied.

  def clean_collection
    @clean_collection ||= if current_parent
      current_parent.send(resource_collection_name)
    else
      resource_class
    end
  end

https://github.com/HitFox/foxinator-generator/blob/a8ea640f74d1fbceb6cf0931098172bf5841ceb8/lib/generators/foxinator/setup/templates/cms/app/views/admin/base/_collection_actions.html.haml

t('.new', resource_name: resource_class.model_name.human)

should be:

t('new', resource_name: resource_class.model_name.human)

so only one key is needed.
The according translation then will be on toplevel and should look like:

en:
    new: 'new %{resource_name}'

this gives us scopes per state and the ability to easily check if a model has a state machine or not.

module StateMachinable
  extend ActiveSupport::Concern

  included do
    scope :by_status, -> (status) { where(state: status) }

    state_machine.states.each { |state| scope state.name, -> { where(state: state.name.to_s) } }
  end

  class_methods do
    def state_machine?(name = :state)
      respond_to?(:state_machines) && state_machines[name].present?
    end
  end
end