saturnflyer/surrounded

Create encapsulated systems of objects and focus on their interactions

surrounded's Issues

Context nesting

I have an Authorizing context that accepts an AccessToken, a Permissions object, and an arbitrary sub-
context. The Authorizing context coordinates among those objects to figure out if the sub-context is allowed to be executed.

Then in my sub-context, I have access to context.access_token, access_token being a role in the top-level context. The reason for nesting is so that I can execute a sub-context in the context of being authorized or by itself, so not authorized.

I'm have two questions.

First, is context nesting the right way to go or should I just create multiple sub-contexts (auth and not auth) and pass what is needed to them from the Authorizing context?

Second, if nesting is ok, then I run into an issue when I need contexts to be nested three or more levels deep (which maybe is a bad sign). If they are nested three levels or more, then I end up having to know to call context.context.access_token, which ends up not working if the third level sub-context is ever used as a second level sub-context. Maybe I'm missing something in the gem or doing it wrong. Is there a way to access other roles from parent contexts other than going through the context method in the role methods?

Allow roles to raise an error on method name collisions

Contexts should provide an option to raise errors when objects have methods that match the names of the other roles in the context. #23 has comments about related problems

Context setup does not define arity

The setup method does not define the arity for the initialize method. It should.

automatic shortcuts

consider automatically providing shortcuts so that a trigger method defined will make a class method of the same name taking the same arguments as initialize and run the trigger immediately.

Surrounded vs Casting

Hey Jim, one more quick question. I was checking out Casting as well, and thinking about when you'd use that vs Surrounded. Here's what I came up with. Can you let me know if this rings true for you, or if you have anything to add:

1. DCI style programming can be done with either Surrounded or Casting
2. Casting is a "smaller buyin" approach, in that you don't have to touch your domain objects at all (vs Surrounded, where you have to "include surrounded" in them).
3. For this reason, Casting can be considered more of a library approach, vs Surrounded, which might be considered more of a framework approach. That is, if you use Surrounded on a project, "Surrounded" stuff is going to be in both your domain objects and your use-case objects/modules. With Casting, it's not really in either, other than a few calls to cast_as
4. The flip side of point 3: With surrounded, you get more sugar and convenience methods that clearly map to the higher level concepts of DCI.

Is this all fair? Anything I'm missing?

Cannot assign object to role using map_roles

Hi @saturnflyer

I want to assign a couple of roles using a block in keyword_initialize like so:

 keyword_initialize :controller, :purchase_order, :params do
    it = ::Item.create!(
      name: params[:name],
      quoted_price: params[:quoted_price],
      delivery_on: params[:delivery_on]
    )
    map_roles(item: it)
  end

The :item role is definitely included in @role_map in the context and #role_player? :item returns true. However, when attempting to use :itema NameError is thrown. This is not the case for :controller or :purchase_order. Can you suggest what is going on? I have used this technique before and managed to make it work, albeit with a little fiddling...

Role is returned as nil

Hello,

I have a very simple context set up with two roles as below:

 class ValidatingPostcodes
    extend Surrounded::Context

    require 'going_postal'

    keyword_initialize :country, :postcode

    trigger :validate do
       postcode.validate_postcode
    end

    role :postcode do
      def validate_postcode
        country_code = country.alpha_2 #country is nil
        if valid = GoingPostal.valid_postcode?(code, country_code)
          self.code = valid
        else
          errors.add(:code, "This is not a valid postcode for #{country_code}")
        end
      end
    end
  end

My tests fail when country.alpha_2 is called. I have checked that country is present at the time that the trigger is called, which it is, however it doesn't seem to have made it into the role. This error appears in both surrounded and surrounded-rails.

I really it hope it isn't anything obvious, but I cannot see where things are going wrong!

Running on ruby 2.1.5 and rails 4.2.4

additional information about allowed triggers

consider adding methods to check for trigger access

context.allowed?(:some_trigger)
context.allows?(:some_trigger)
context.some_trigger_allowed?

content.disallowed?(:some_trigger)
context.some_trigger_if_allowed #=> turns to a no-op if not allowed…?

Implement trigger keyword like private, accepting a list of symbols

I had implemented set_methods_as_triggers but I think a better case would be to remove that and allow you to specify methods as triggers so you could opt-in with just the ones you want.

Desired syntax:

class Something
  extend Surrounded::Context

  def some_method
    #…
  end
  trigger :some_method

  trigger def other_method
    #...
  end
end

Allow initialize to take defaults

I'd like to be able to initialize a context with default values. For example

class UserActivation
  extend Surrounded::Context

  initialize :admin, :user, :category => 'Normal'
end

Bug found in Ruby 2.1.0…?

https://travis-ci.org/saturnflyer/surrounded/jobs/16268509

Calling super from inside the new method of Surrounded::Contextual seems to trigger the error.

provide more helpful access error with line number

currently Surrounded::Context::AccessError will only report the message, but not the line of the error.

Make it compatible with rbx

Extending classes with Surrounded::Context makes all native methods unavailable in the class where extend Surrounded::Context is used.

Is this something you know about? Something you or I can fix or should we call in the rubinius team? You are doing some meta stuff that might rely on MRI behavior that shouldn't be or something crazy like that.

I would love to switch my apps over to rubinius but I love surrounded 👍

allow role types to be extended

remove the case statement for checking roles and add a place to hook in other options

What is the best way to test the methods defined in roles?

Since all methods defined in the roles are private, what is the best way to test them?

Ruby 2.2.1 Error

Hi there,

we have a strange error happening only in 2.2.1 and maybe 2.2.0.

We have may DCI Contexts in our app and all is running smooth with ruby 2.1.5

But now all tests fail with this error:

 RuntimeError:
   can't modify frozen NilClass
 # /Users/dmasur/.rvm/gems/ruby-2.2.1/gems/surrounded-0.9.1/lib/surrounded.rb:31:in `surroundings'
 # /Users/dmasur/.rvm/gems/ruby-2.2.1/gems/surrounded-0.9.1/lib/surrounded.rb:35:in `context'
 # /Users/dmasur/.rvm/gems/ruby-2.2.1/gems/surrounded-0.9.1/lib/surrounded.rb:39:in `method_missing'

It is possible that it happened with this change: https://bugs.ruby-lang.org/issues/8923

When this error happens @surroundings is nil and frozen.

When i find time i will investigate this a bit more, but at the moment i only have a private project with this problem.

Why no `require 'surrounded/context'`?

Just wondering what the reasoning behind that is. I spend a few minutes trying all kinds of require before I had to go to the source code to check what I needed to require namely require 'surrounded/context'. In my view this file could be automatically required when we do require 'surrounded'. Right or wrong?

Is surrounded still in active develpment?

Hey Jim, Just curious if you are still actively maintaining this project and using it in your own projects in production? Thanks.

Can rbx 2.1.1 use interfaces?

The best and most awesome way to use surrounded is with interfaces (ruby 2 only version). I believe rubinius 2.1 is actually ruby 2 compatible so shouldn't that feature be available for rubinius as well?

dissallow syntax does not apply roles

the new disallow blocks do not map roles to objects. behaviors are not applied when evaluating the block

Alternative access to roles

I'd like to have the objects inside the context be the only ones who can access the other objects.

For example, we use context.respond_to? in our method_missing code but what we really need is something like context.role_for(role_name, self) where self is the object requesting the role, and only objects that exist inside the context are given the role (the object they want). All other objects NOT inside the context, would get nil... or an error.