Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
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.
This is just me having a difficult time abiding things I don't understand :laughing:
Captain Husayn Pinguin
@captainhusaynpinguin
@kaikuchn thanks for the warm welcome!☺️
Captain Husayn Pinguin
@captainhusaynpinguin
What is this fancy really about "Third party gems can be maintained by developers who want to bring frontend framework support to Hanami. Let’s say we want to build an hanami-emberjs gem."?
like you expect everyone out there to repackage every front-end library into a Hanami Package? That's beyond repeating yourself, it is repackaging strangers!
Captain Husayn Pinguin
@captainhusaynpinguin
I mean, I do appreciate developing a whole "asset" feature, but the real issue with your approach is that front-end development is a world of its own. Sure, there are a few famous packages out there that you just grab them but most front-end developers do the front-end coding their own and then you have a heavy load of modules that need to be bundled together. Your approach is beyond outdated! I have seen that in Rails but Rails was the first of its kind. But now I don't think any front end package would have a Rails-based gem.
Why aren't you doing a web-pack out of the box integration? That's the common way of managing, releasing, bundling front-end packages and there is a web-pack release for almost every library, to the point that there is a debate that many libraries' standalone JS or CSS files doesn't function properly without requiring them via web-pack or something.
Captain Husayn Pinguin
@captainhusaynpinguin
Here is an example of installation styles that a modern front-end library supports: https://vuejs.org/v2/guide/installation.html
there is no gem or Ruby. I like the separation style app folder but that without somehow embedding one or a few of these bundlers into hanami asset management capabilities ... I don't know, I really don't get the logic!
Captain Husayn Pinguin
@captainhusaynpinguin
at the moment, I'm going to go with putting Laravel Mix to produce packages I already have into the assets folder! https://laravel-mix.com
Kai Kuchenbecker
@kaikuchn

I think this was put there because at one point people wanted to work like that.. But I completely agree with you, I was never a fan of these repackaged js libraries that'd be always outdated and you didn't even get to use any of the goodness like google closure to reduce asset size.
For that matter I really don't like the asset pipeline approach at all, and I am very happy that the Ruby (on Rails) community has or is moving towards letting JS tooling handle JS.

Personally I only use Hanami for APIs (public or private, i.e., for frontends), so I have no clue what people do who go the classic route.

Edouard
@inouire_twitter
Not using complex js lib here either, so the simple approach To asset management suits me well
kristjan-brezovnik
@kristjan-brezovnik
Where to do I need to put my Slovenian.json localization file for DataTables (JQuery plugin) and how do I reference it during initialization?
Currently, it's in my I18n folder under my app's Assets, but "url": "../I18n/Slovenian.json" doesn't work. I've tried other variants, but can't get it to work. Any idea?
smarthouseprojectdotorg
@smarthouseprojectdotorg
Hi, how can I add a custom error message into params validation? I'm doing the below but always get the error:
ArgumentError: +test?+ is not a valid predicate name
What am I doing wrong? Is there an easier way? I don't need to change or extend the logic, only want a local custom message
        predicate :test?, message: 'Test' do |current|
          return false
        end
        params do
          required(:user).schema do
            required(:key).filled(:test?)
          end
        end
Kai Kuchenbecker
@kaikuchn
@kristjan-brezovnik You can put it in public, or treat it like any other asset.
@smarthouseprojectdotorg under the hood dry-validation is used. So maybe this helps https://dry-rb.org/gems/dry-validation/0.13/error-messages/
Kai Kuchenbecker
@kaikuchn
Otherwise, getting custom predicates to work with params was a little complicated iirc. But I don't remember why or what needs to be done
kristjan-brezovnik
@kristjan-brezovnik
@kaikuchn Yep, that worked. And the same solution also solved the issue of the missing DataTables arrows.:D Thanks.
Sebastjan Hribar
@sebastjan-hribar

Has anyone any idea why this:

assert page.has_content?('some value'), "Page must have content some value."

would succeed for show, but not for the update action? The spec is identical in that the before and after block are the same and I switch between

visit "/godmode/contacts/#{@contact.id}/edit" and visit "/godmode/contacts/#{@contact.id}" to compare what happens.

I can successfully puts all the text to the commandline via the spec and save_and_open_page shows all texts as well.

Wout
@wout
Hi guys, we are starting a long-running project (5+years) and after much deliberation, we chose Hanami over Rails. Preparing our codebase, there is some unclarity about the authentication approach. Tachiban looks good, but what worries us is that it is not based on Warden (which might be unjustified). Then there is hanami_id, which is based on Warden and takes an interesting approach with a dedicated app. And finally our least favourite option, rolling our very own authentication based on Warden. We have looked at rodauth, but the implementation for Hanami looks messy.
So, we are wondering, what does the Hanami community advice us to do in this area?
Benjamin Reynolds
@benreyn
:point_up: Im interested in the answer to this too FWIW. Also curious what the status of the hanami real world app is? I saw a placeholder in the github org, but no work done on it
It looks like most of the libraries for auth are pretty outdated / are not maintained
Benjamin Reynolds
@benreyn
It also looks like there were some attempts to put some documentation about this together on hanami/ecosystem#7
Wout
@wout

@benreyn That is one of our concerns too.

It looks like most of the libraries for auth are pretty outdated / are not maintained