Open marten opened 10 years ago
I think the second one would work better with the helper syntax, and removes the need for a seperate create and call statement. I think we would want to add some syntax to support this though.
Liking the second option too.
actually you can do the first one by just treating the callbacks as parameters, right?
Yeah, and with the 1.9 syntax it's not even that ugly.
Agree on the second one.
Righto, I'll try to whip something up for the second style then.
Should we do it explicit like that though, or should we do it rails controller style:
def execute
if rand > 0.5
success post
else
failure post
end
end
Oh, yeah I want to have some supporting DSL. We currently have "succeed!" and "fail!", but I'd rather make it a bit more generalized and support arbitrary callbacks. Possibly we also want to support returning multiple objects, to support something like https://gist.github.com/marten/9e659cd7629cd2e5d93e#file-interactor-rb-L22 where we have a bunch of things we want to know during rendering, but we couldn't think of a sensible containing model name.
I'd like to vote against fail!
though, since that's way too similar to fail
Agreed about something for multiple return values, we sometimes need to do that as well (and currently use tuples)
I don't want fail!
. It doesn't align with succeed!
. :P
Okay, did some work on return object and multiple return values, no callbacks yet. Also, obviously not backwards compatible or anything.
class Interactor
include Pavlov::Operation
def call
hash = super
self.class.return_object.new(hash)
end
def self.returns(*args)
return_object.send(:attribute, *args)
end
def self.return_object
@return_object ||= Class.new do
include Virtus
end
end
end
module Interactors
class SelectMeasurement < Interactor
attribute :current_patient, Patient
# ...
returns :protocols
returns :measurement
# ...
def execute
protocols = query(:available_protocols_with_measurements)
# ...
return {protocols: protocols,
measurement: measurement,
questionnaires: questionnaires,
respondent_type: respondent_type}
end
end
end
Hmm, I'm not to happy about instantiating new classes all the time. Or openstruct for that matter (which would be a logical replacement). Can we think of a way where we do not need to clear the method lookup cache (runtime)?
Haha, oh that's definitely not what I'm proposing. That was just the easiest way to get the example implemented and passing the interactors' tests, and a way to check how difficult the implementation of such API would be :) I didn't even commit this in RoQua.
Right now RoQua adds callbacks to interactors, which are used to communicate result state and execute bits of controller logic (
redirect_to @post
for success vsrender action: :edit
for failure):We could add it like that to Pavlov, but another way would be to support returning "status objects" from interactors:
For us, both would work equally well. Which would be your preference?