estum / growlyflash

Growl-styled flash messages for Ruby on Rails and Bootstrap
MIT License
58 stars 34 forks source link

Remotipart - upload files with ajax #16

Closed Dinuz closed 9 years ago

Dinuz commented 9 years ago

@estum I changed this issue completely, after further investigations and I am updating it now:

In the case I have an upload file that use remotipart https://github.com/JangoSteve/remotipart.git (this is the classic solution to upload files in rails using remote: true), due to the behaviour of the gem, my request will not be xhr type. Under this circumstance, unfortunatelly the growlyflash gem cannot properly work (the gem checks for an xhr request only).

If you look in the remotipart gem they have an helper that return true if the request or the submit happened due to remotipart https://github.com/JangoSteve/remotipart/blob/master/lib/remotipart/request_helper.rb

What do you think if we include remotipart helper and modify the growly flash gem in order to keep using growlyflash also after this type of request?

I mean:

included do
  helper_method :growlyflash_static_notices, :growlyhash , "the remotipart helper" if remotipart exist
end

and

  def use_growlyflash(options = {})
    append_after_filter :flash_to_headers, options.reverse_merge(if: :is_xhr_request? || "the remotipart helper")
  end

or just modify the is_xhr_request? method in order to include there a check on the remotipart submission?

This will allow us to use the growlyflash gem also under a fake xhr request as the one made by remotipart (it use Iframe).

Or maybe you have some other alternatives and I would love to hear.

Please let me know what do you think? I don't think is smart adding a dependence on the gem, but maybe adding a check could help.

Best Dinuz

estum commented 9 years ago

@Dinuz you use_growlyflash can take custom conditions such as usual after_filter method. For example:

use_growlyflash if: -> { is_xhr_request? || remotipart_submitted? }

But I am not sure that it will solve your issue.

Please, inspect "X-Message" headers of requests and compare them with expected messages. If headers are missing, then a reason in callbacks chain or middleware stack (so check when you set flashes). Otherwise, If all messages are found but not shown, it is means that remotipart unbinds growlyflash's events in js.

Dinuz commented 9 years ago

@estum I am going to try it! I can just say right now (because I checked and I am sure) The X-Message is there, and report the right message. What happen is that the js is like not active (the growly flash coffee is ignored). That obviously happen because remotipart is not an xhr request.

All the messages are there in the header, but nothing of js happens.

estum commented 9 years ago

@Dinuz remotipart readme says that it is possible to catch its requests with 'ajax:success' event, so, i think, it makes xhr request. Check your application.js to require growlyflash after jquery.remotipart. Also trace event listener at app/assets/javascripts/growlyflash/listener.coffee:

($ context).on EVENTS, (_, xhr) =>
      @stack.push_once process_from_header(xhr.getResponseHeader HEADER)
      return

I think the answer somewhere there.