Forum https://discourse.hanamirb.org – Code of Conduct http://hanamirb.org/community/#code-of-conduct
Do let me know how it goes for you. (peter@trykno.com if you want to message direct). We are working on the key integrations this week. Thinking PHP, Ruby, and NodeJS are probably the most useful for now. Then hopefully we are going to be able to go back to the core widget and really focus on nailing the UX
I changed my strategy, now I am using an out-of-scope hanami consumer who is solely responsible for performing partition creation
Can someone help with translating the default validation messages? Following the guides here I provide simple translation like this:
sl:
errors:
filled?: "mora biti izpolnjeno"in the yaml file that is loaded by the I18N gem. The validations, however, don't pick the translation.
DomainValidator here, maybe that helps you in figuring out what's going on?It's possible that there is an issue here though, since not everything that's possible with hanami-validation is possible in the params validation block of hanami-controller, iirc.
handle_exceptions any exceptions that happen in the view do not appear either in the stdout or sent to HoneyBadger, but if the exceptions are raised in the controller are. Is this expected? and if so, what is the best practices for understanding view exceptions with handle_exceptions enabled?
@kaikuchn Yes, I assume the spec and the fixture as in the links above are set up to be used in an interactor, right? The main difference being the validations define messages :i18n also seen here. There is no specific path defined for messages. While there is one when the validations block is used within the Paramsclass. You can see the same here in Hanami docs.
My use case is to have the 1. default messages translated after params are validated and then 2. process them again, prepending each one with the translation of the word field to avoid dealing with inflections.
The second part is implemented, but the error messages still need to be translated. As for i18n, it's implemented across multiple apps and works with no problem (implemented as already mentioned above: https://www.bounga.org/ruby/2016/10/08/using-i18n-with-hanami/).
@kaikuchn I was overthinking it. The key issue lies with the messages method, where it should be enough this: messages :i18n. After trying a few things I went over the issues and I came across hanami/validations#129 and also the required workaround:
params do
configure do
config.messages = :i18n
end
endWith this, the validations pick up translated messages.
hi folks
my team has just started using Hanami recently for a new project. we've been meaning to use it for a long time. have a few fanboys of Hanami who were waiting for this to happen for a long time, so we're really happy so far
quick question: anyone knows of any similar initiative to brakeman that would work similarly for hanami?
Hi.. I am new to Hanami and I am finding a way to write migration to set a column with a value. For example, I have created a new column(total) in savings table and I want to run a migration to calculate the total and fill into that column for each records in the database.
What usually you do and how do you it in Hanami?
Some consider it an anti-pattern to perform data migrations through the vehicle of schema migrations. Cf. this post by thoughtbot on that issue, it is in the context of rails, but most points are valid for Hanami as well.
That begs the question what can you do? You can still perform data migrations through migration files, just make sure that you do NOT reference any code in your code base, because that code will change and potentially break the migration down the road.
Another way is to write a one-off rake task or some plain ruby script to perform the migration on your next deploy.
Heck, I sometimes even performed data migrations by logging into the database and firing a SQL statement, just do whatever works best for you and your use-case.
friends, new to hanami here. Is there a good way that I can get Hanami::Router to route requests to different controller based on the MIME type but for the same path? ex: get /foo (mime: text/html) => HTML::Foo and get /foo (mime: application/javascript) => API::Foo.
I was able to get it working by passing a proc to the routing target and having the decision happen there, but I wonder if there's a prettier way?
sample:
get "foo", to: -> (env) do
if env[:request].html?
HTML::Foo.new.call(env)
else
API::Foo.new.call(env)
end
end
One surefire way to go about this is to have someone else rewrite your paths with the mime-type. I.e.,
/foo => /foo.json and then match on that. This could be done by a very simple rack middleware that you insert before the router middleware or by a reverse-proxy like nginx that sits in front of your app.
