Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 28 19:23
    cllns labeled #1084
  • Oct 28 19:23
    cllns assigned #1084
  • Oct 28 17:19
    GeorgesFlatlooker starred hanami/hanami
  • Oct 27 18:24
    cllns commented #1084
  • Oct 27 18:24
    prio101 starred hanami/hanami
  • Oct 27 18:23
    prio101 closed #1084
  • Oct 27 18:23
    prio101 commented #1084
  • Oct 27 14:26
    adam12 commented #1084
  • Oct 27 12:58
    prio101 opened #1084
  • Oct 27 12:54
    timriley opened #335
  • Oct 27 12:53

    timriley on unstable

    Introduce security settings fro… Remove unneeded require Add security-related headers to… (compare)

  • Oct 26 16:09
    yptayo starred hanami/model
  • Oct 25 15:35
    bitberryru starred hanami/hanami
  • Oct 24 23:52
    MatheusRich starred hanami/router
  • Oct 23 08:08
    oscarada87 starred hanami/model
  • Oct 22 12:46
    timriley commented #182
  • Oct 22 12:43
    timriley synchronize #182
  • Oct 22 12:43

    timriley on configure-part-namespace-on-application-views

    Add parts_path application conf… (compare)

  • Oct 22 12:43
    depfu[bot] labeled #588
  • Oct 22 12:43
    depfu[bot] opened #588
Eric
@ericplezi

this is what I have in the config.ru file:

console = ActiveSupport::Logger.new($stdout)
console.formatter = Rails.logger.formatter
console.level = Rails.logger.level

Rails.logger.extend(ActiveSupport::Logger.broadcast(console))

run Rails.application

the log-level is set to :debug
somehow it doesn't print the http request info (duration, params, ip address, etc). is there a middleware to add?

Kai Kuchenbecker
@kaikuchn
Right, so I just had a look into hanami/controller and it seems that it's not responsible for logging requests. I'm guessing some rack middleware does that. I'll have to further look into it.
Yeah, the hanami/hanami gem wires logging up.
It uses a common_logger component that is based on the rack/common_logger.
Kai Kuchenbecker
@kaikuchn
I.e., I suppose you could insert rack/common_logger into your middle-ware stack and you should get your request logs.
Kai Kuchenbecker
@kaikuchn
You may also consider using this: https://api.rubyonrails.org/classes/Rails/Rack/Logger.html
Which is the rails middleware for request logging.
Without knowing how you integrated hanami/controller into your rails app I'm not sure what makes sense and what doesn't :)
Eric
@ericplezi
I added rack/common_logger file in my project and added require 'rack/common_logger' in my config.ru
nothing was printed :(
Michael Trommer
@entropie
How does one access cookies from the view? Works fine from the controller, I feel I must miss something.
Kai Kuchenbecker
@kaikuchn
@ericplezi You need to insert the middleware it as well!
@entropie why would you? wouldn't it be better to expose a variable to the view?
Eric
@ericplezi
I added the middleware @kaikuchn
Kai Kuchenbecker
@kaikuchn
Ah ok. Where did you add it?
Eric
@ericplezi
in the lib folder under rack/common_logger.rb
Kai Kuchenbecker
@kaikuchn
No, I mean where in the middleware-stack did you insert it? See this guide to middleware if you're unsure on what to do.
Eric
@ericplezi
# frozen_string_literal: true

# This file is used by Rack-based servers to start the application.

require_relative 'config/environment'
require 'rack/common_logger'


console = ActiveSupport::Logger.new($stdout)
console.formatter = Rails.logger.formatter
console.level = Rails.logger.level

#Hanami::Logger.extend(ActiveSupport::Logger.broadcast(console))
Rails.logger.extend(ActiveSupport::Logger.broadcast(console))

run Rails.application
here I added it
Kai Kuchenbecker
@kaikuchn
There you simply required it. But now you also need to insert it into the middleware-stack. See the guide I posted in my previous message on middlewares / rack.
Eric
@ericplezi
yeah i'm not sure where to added it and how to include it
Eric
@ericplezi
I added config.middleware.insert_before 0, Rack::CommonLogger in the application.rb
seems to do the job
Thanks mate @kaikuchn !
Kai Kuchenbecker
@kaikuchn
:+1:
Michael Trommer
@entropie
@kaikuchn yeah probably, but I dont know how to access #cookies from the view context as well
Michael Trommer
@entropie
ok, i did a before :hook and set a variable.
Kai Kuchenbecker
@kaikuchn

but I dont know how to access #cookies from the view context as well

Well pass it from the Action via Exposure to the View, as you'd do with anything else.
If you need it to be present for every View, you can also make use of the prepare hooks in the application.rb file.

Kai Kuchenbecker
@kaikuchn
E.g.,
module Web::BakedViews
  def self.included(action)
    action.class_eval do
      exposure :cookie
      before :bake_ma_view
    end
  end

  def bake_ma_view
    @cookie = cookies[:grannys_tasty_cookies]
  end
end

# web/application.rb
# ...
  controller.prepare do
    include Web::BakedViews
  end
Hmm, actually, before might be nicer since it doesn't overwrite the call action, yeah I'll edit the above accordingly.
smarthouseprojectdotorg
@smarthouseprojectdotorg

Thanks @kaikuchn I'm using named routes. This is it

get '/clients', to: 'clients#index', as: :clients_index

Can you think of anything else to check? It's more a theoretical question though as I think it should redirect using GET but I won't use it as redirection from 'destroy' action make sense only if a form is used for calling the deletion. Using a form for this seems weird and I ended up with AJAX hence don't need to redirect now. But that raised a question about a proper way of sending DELETE in Hanami. <form>, AJAX do we we have anything else which would look as nice as link_to for 'edit' and 'new' ?

kristjan-brezovnik
@kristjan-brezovnik
Is it possible to have a JS or JSON file under assets and expose an array, then loop through that array in a template? Basically, I have a list of items, which all get the same HTML container around them, so I don't want to needlessly duplicate the code.
kristjan-brezovnik
@kristjan-brezovnik
Ah, figured it out:
<% tiles = %w[item1 item2] %>
<% tiles.each do |tile| %>
<h1><%= tile %></h1>
<% end %>
Sebastjan Hribar
@sebastjan-hribar
What would be the reason for a flash not to render? I have sessions enabled for the app and set flash as flash[:error_m] = params.error_messages. puts flash[:error_m] works and I see all messages in the server output. The template has simply this code <%= flash[:error_m] %> and nothing renders.
Sebastjan Hribar
@sebastjan-hribar
It's like the flash is not exposed, although they should be by default. I've put an if statement to the template to check for flash[:error_m] and only the false branch executes.
Sebastjan Hribar
@sebastjan-hribar
So, it works for another entity. After some comparing, I saw in the server output these two lines (overlooked them before due to long list of errors and small console):
Warning! Rack::Session::Cookie data size exceeds 4K.
Warning! Rack::Session::Cookie failed to save session. Content dropped.
Kai Kuchenbecker
@kaikuchn
@smarthouseprojectdotorg well Hanami is giving you a 302 response, the question is why the browser then sends a delete request again. So I'm guessing it's something in your client-side javascript that's behaving in a weird way?
smarthouseprojectdotorg
@smarthouseprojectdotorg

@kaikuchn no, just tested, seems it's definitely Hanami which is trying to do a redirect keeping the original HTTP method, i.e. DELETE in case of my destroy action.
This is the action code below, see I disabled halt and enabled redirect_to. Did not change anything else since I moved to AJAX for this, but the below is still OK for this test as only checking the log. clients_index_path route does work - tested separately with link_to

        def call(params)
          ClientRepository.new.delete(params[:id])
          #halt 200
          redirect_to routes.clients_index_path
        end

Result:

HTTP/1.1 DELETE 302 127.0.0.2 /admin/clients/8 5 {"id"=>"8"} 0.015793
HTTP/1.1 DELETE 405 127.0.0.2 /admin/clients - {} 0.007453
HTTP/1.1 GET 200 127.0.0.2 /admin/clients 1856 {} 0.016227

The last line is my test of the route with GET. So definitely in case of HTTP DELETE, route_to tries to do a redirect using the same DELETE method. Obviously it is not supported by my routes and hence 405. Question - is it a bug or a feature? Anyway seems reasonable if redirect_to could always use GET or had an option to specify the method.

Kai Kuchenbecker
@kaikuchn

This is how to read those logs:

  • Received DELETE Request using HTTP/1.1 from 127.0.0.2 for path /admin/clients/8, responded with 302 within 0.015793 seconds
  • Received DELETE Request using HTTP/1.1 from 127.0.0.2 for path /admin/clients, responded with 405 within 0.007453 seconds

So you are sending two delete requests, why ever you are doing this. I'm pretty sure that it's not something Hanami is doing, like 99%. The third request you send is then the get request I'd expect after Hanami had send your client a redirect response. The 2nd request is weird.

Kai Kuchenbecker
@kaikuchn
The 1% is because maybe there is some client-side javascript that hanami generated for you that does that weird request.. but that's the only explanation I can come up with where the second delete request does not come from your client-side code.
Captain Husayn Pinguin
@captainhusaynpinguin
Hi there, a stupid newbie question. How do you do dump like rails or var_dump like PHP in Hanami in the middle of somewhere?
self.body = XYZ only works in controller modules!
Captain Husayn Pinguin
@captainhusaynpinguin
[ps. I deleted the series, cuz I found the bug I was looking for, but I would still appreciate this stupid functionality!]
Kai Kuchenbecker
@kaikuchn
I don't know what you mean by dump in rails. But it's just Ruby so do what you'd do in any Ruby application.
Looking at SO it seems that people recommend Object#inspect as an equivalent to the var_dump of php..? No clue what var_dump does though.
Paweł Świątkowski
@katafrakt
more or less the same as p in ruby
Kai Kuchenbecker
@kaikuchn
Ah okay.. I personally much prefer to have interactive debugging though. I.e., pry or byebug gems are gold for debugging imho.
Btw. welcome to the chat, Captain Husayn Pinguin.
smarthouseprojectdotorg
@smarthouseprojectdotorg
@kaikuchn The second DELETE request is generated by redirect_to. It does not appear if I comment out the redirect_to line. I did not get a chance to investigate it in Hanami source yet and track the redirect_to but definitely a problem of Hanami. There isn't a nice way to send DELETE and I use AJAX for it now (no other HTTP requests are sent beside that for deletion). The mentioned issue is related to using a HTML form for sending DELETE and it does not matter for AJAX since I simply halt 200 at the end of destroy action code. Thanks anyway and I'll try to check Hanami source at some point.
Kai Kuchenbecker
@kaikuchn
I'd really like to know what's going on - but I also don't want to bother you with it if you found another way that works perfectly fine for you.
Maybe you could provide a minimal reproducible example? If you find the time and motivation to do so it would be much appreciated.