Forum https://discourse.hanamirb.org – Code of Conduct http://hanamirb.org/community/#code-of-conduct
timriley on v2.0.0.beta2
timriley on main
Prepare for v2.0.0.beta2 (#1200) (compare)
timriley on prepare-for-v2.0.0.beta2
timriley on v2.0.0.beta2
timriley on prepare-for-v2.0.0.beta2
timriley on main
Prepare for v2.0.0.beta2 (#226) (compare)
timriley on prepare-for-v2.0.0.beta2
Prepare for v2.0.0.beta2 (compare)
timriley on fix-location-of-rack-require
timriley on main
Move require for rack inside to… (compare)
I have a question about the Hanami.application
global. After digging through the code and testing it seems like this way of keeping a global reference to the app means that you can have only one Hanami instance running at once? So if I wanted to run two Hanami apps mounted at different paths in Sinatra, could I?
I'm not asking because I have that particular use case, but I am trying to solve some of the same problems that Hanami have solved and this is the final thing I'm stuck on. It might not be a problem for Hanami - normally you would just run a single instance anyway. But I'm building a REST API abstraction library and this global reference (if I understand it correctly) means that end users would not be able to have two API libraries based on my abstraction loaded at the same time - they would both try to use the global and get into a conflict, the same way you would if you tried to load two Hanami apps at once now.
Or am I missing something? :slight_smile:
new
command like I did with the rest of the options: hanami new pistachio --test=rspec --database=postgres --template=erb
UpdateUser.new.call(user)
. With this approach you can also unit-test the domain without mocking the db.
rich domain model means that the models contain the logic
Not in a functional way, you have your data and the module logic is the "owner" of this data.
That is how the rich domain is represented in functional.
Hanami allows us to design our code, takes all the advantages you can.
That's a big step comparatively of Rails that forces us in a MVC + RailswayTM
Failed to load resource: the server responded with a status of 404 (Not Found)
for a lot of assets. However, looking in the public\assets
folder the different app folders have those assets that are reported missing.
@/all Hanami v2.0.0 first beta!
hanami-api
, dry-system
and rom-rb
. I'm very happy with it. I read that hanami-api
may be dropped. It would be a shame for me if hanami-api
were to be dropped. What should I do? I don't necessarily want to migrate these projects to Hanami 2, but they should evolve. What would you advise me?Hi, we're still having issues with assets. In my dev environment everything works fine. When I deploy (still on my dev laptop) the app with Docker and using Hanami for serving static assets I get this in the console:
Failed to load resource: the server responded with a status of 404 (Not Found)
for a lot of assets. However, looking in thepublic\assets
folder the different app folders have those assets that are reported missing.
I haven't gotten any further with this. For example, one of the assets not found when running in Docker is this one: http://localhost:8091/assets/sentinel/w3-1ac375ab06574a481efcf0b7fed82b4c.css
. However, when I inspect the folder content I find it: /usr/src/app/public/assets/sentinel/w3-1ac375ab06574a481efcf0b7fed82b4c.css
. What am I missing?
hanami assets precompile
command so everything is setup as described here.
public/assets
level. We use command in the docker-compose to copy this with deploy.
I just upgraded our Hanami application from alpha8 to beta1. The project was setup using the Hanami 2 template. We now get this error when running rspec:
$ bundle exec rake
An error occurred while loading spec_helper.
Failure/Error: require "hanami/prepare"
NoMethodError:
undefined method `source_dirs' for #<Hanami::Configuration:0x000000010636bad0 @config=#<Dry::Configurable::Config ... (see full stack trace in thread)
# ./config/app.rb:13:in `<class:App>'
# ./config/app.rb:6:in `<module:MyApp>'
# ./config/app.rb:5:in `<top (required)>'
# ./spec/spec_helper.rb:6:in `require'
# ./spec/spec_helper.rb:6:in `<top (required)>'
Anyone here knowing anything about this source_dirs
, has it been renamed? I can't find anything in the Hanami changelog about this. This is my config/app.rb
:
# frozen_string_literal: true
require "hanami"
module MyApp
class App < Hanami::App
config.sessions = :cookie, {
key: "my-app.session",
secret: settings.session_secret,
expire_after: 60 * 60 * 24 * 365 # 1 year
}
config.source_dirs.component_dirs.add "serializers" # <--- crashes here
end
end
This code worked in Hanami alpha8.
Hey guys :wave:
Firstly, thank so much for hanami! I love the project :smile:
I'm currently working with a client (using hanami 1.3) on building a gem that adds a rack middleware which needs the current request path (with path variables names). Sorry if that wasn't clear but for example:
Considering a request to /users/5/posts/1
, the rack middleware needs to know that this request was to the path /users/:user_id/:id
That said, I tried to look a bit the documentation for hanami-router and found there's Web.routes.recognize(env)
from which I can get the path variables:
route = Web.routes.recognize(env)
route.params # => { :user_id => 5, :id => 1 }
route.path # => '/users/5/posts/1'
..but the path doesn't include the variable names :/ i'm looking for a reliable way to get /users/:user_id/:id
. Can anyone help me achieving that?
Hey guys :wave: another 1.3.x question incoming!
On a fresh project:
# hanami 1.3.x
hanami new hanami_dummy
cd hanami_dummy
hanami generate action web users#index
when visiting /users
, I left a binding.irb
and checked the rack env via the @_env
variable, where I see:
{
# ...
"PATH_INFO"=>"",
"SCRIPT_NAME"=>"/users"
}
I don't understand this! Shouldn't it be the opposite? Aren't they swapped?? According to the rack spec:
SCRIPT_NAME
The initial portion of the request URL's “path” that corresponds to the application object, so that the application knows its virtual “location”. This may be an empty string, if the application corresponds to the “root” of the server.
PATH_INFO
The remainder of the request URL's “path”, designating the virtual “location” of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash. This value may be percent-encoded when originating from a URL.
About the Hanami 1 -> 2 Upgrade steps: Here is the thread I'd love you all interested to continue on: https://discourse.hanamirb.org/t/hanami-1-3-hanami-2-0/702/2
Hope that helps!
cc: @Drowze @sebastjan-hribar
Hello!
I am running Hanami 2.0.0.beta.1 and trying to enable JSON parsing as it is shown in Hanami router's readme page.
I am getting the error below as soon as I add the following line in my config.ru file.require "hanami/middleware/body_parser"
ruby/gems/3.1.0/gems/hanami-router-2.0.0.beta1/lib/hanami/middleware/body_parser/errors.rb:12:in `<class:BodyParser>': uninitialized constant Hanami::Middleware::Error (NameError)
class BodyParsingError < Hanami::Middleware::Error
^^^^^^^
Did you mean? IOError
Errno
I am not sure if it is me that is missing something or it is failing to find error.rb class ?
Thanks in advance :)