Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve handling of extension attributes from running steps #4
Florent wrote: http://markmail.org/message/ivfpsyvyb3hxinle
Thanks. That solves the problem for XSteps. But most of the
I guess a simple and convenient solution is to add a method
or preferably a more dedicated one like:
DefaultStep's already have access to the XAtomicStep in the 'step' field. And there's already a getExtensionAttribute() method that will return the extension attributes on the step.
I added getStep() to the XAtomicStep so that you could say:
Input input = step.getStep().getInput("source")
Without the ability to get at the underlying step, you couldn't get the Input object to get the extension attributes off of it.
So I think we're good. Reopen if you disagree.
But that code is legal from within the class deriving from DefaultStep, not from external code using such a step, right?
So yes, Load could access the extension attributes, but the goal is to access them from code outside of Calabash code base. A method receiving a Load object (e.g. XMLCalabashConfigurer.loadDocument(Load)) cannot access those attributes, because it does not have access to the protected member 'step'.
That's why I suggested to provide the underlying step, or probably more sensible only the extension attributes, through a new method on DefaultStep.
Did I miss something?
PS: I cannot reopen the issue, perhaps because I hadn't create it myself?
By the way, sorry I haven't think about it before, but if you
Look at the method loadDocument(Load step). For now, it is