As far as things I'd like to see, I've always found permissions/access to be poorly organized in most applications. I've often thought about using the container concept to inject validations and access policies dynamically on a per-request basis, but I would be curious what strategies you've found for appropriately isolating those concerns in an extendable way.

@timriley Going by a typical "roles & permissions" paradigm: after authorizing the user, a role-specific container would be used for the remainder of the request. If user-level permissions were present, I suppose that might affect the specific injections provided in that container.

@garrettlancaster ahh, interesting take. Perhaps rather than providing different containers, what might work instead Is providing a "resolver" for a specific role that returns a bunch of role-specific objects to use...

@timriley Sorry, my thinking is a bit unclear as this is unfamiliar territory. So are you suggesting that rather than injecting e.g. MyContainer['validate_article'] I would inject MyArticleValidationResolver.new into any operations that needed it?

@timriley and then the operation itself would do something like validator = validator_resolver.(params); validator.(params)

Dinner time, gotta run but will check back later. Thanks again for all the great work you guys are doing, it's the first hint of a practical feeling solution to all of the Rails woes we're all too familiar with.

The other day someone answered a question on "inheriting" a base validation schema and adding additional rules. Now I want to do that too, but I can't find the answer again (gitter search is terrible!). Anyone who can help me out? (What I actually want to do is have a base "AddressSchema" and then a "TemporaryAddressSchema" with the same rules but also require a start and a stop date.)

but that has a bit more implicit knowledge to most Rubyists, I think; methods by those names are used in other libraries and carry plain-English connotations for the meaning of "success" and "failure". Left and right are navigational terms, not logical terms

If I get a response from an api that returns something like this {data: [{_type: 'user', ...}, {_type: 'group', ...}]} is there a way to get dry-types to pickup on the _type property for each returned entity and properly deserialize the json into the correct objects?

Using dry-result_matcher and dry-monads, how would you handle two different failure scenarios? For example, say that you are updating a record and you need to retrieve the record from the DB before updating it. If the record is not found you want to return a 404 status code and if the update is not successful, you want to return the status code 422 + error payload.