You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer, I want to fully customize how a data type is processed.
For this to be available, we could extend builder object methods to overwrite the DSL definition generated.
For example: Having a Student object that contains an Example object, besides having available the setExample we can add something like `setExampleDslPart'
Something like this would open the possibility of fully customizing how an object is managed by the library.
Also would be good to have a way to configure this behavior at the annotation level, to avoid having to repeat this assignation in each one of the '@Pact' definitions. Maybe use a new annotation that references an implementation class.
As a developer, I want to fully customize how a data type is processed.
For this to be available, we could extend builder object methods to overwrite the DSL definition generated.
For example: Having a Student object that contains an Example object, besides having available the
setExample
we can add something like `setExampleDslPart'Something like this would open the possibility of fully customizing how an object is managed by the library.
Also would be good to have a way to configure this behavior at the annotation level, to avoid having to repeat this assignation in each one of the '@Pact' definitions. Maybe use a new annotation that references an implementation class.
For example:
That referenced class should contain an annotated method that references Example.class, to indicate that is the DslPart generator method:
The text was updated successfully, but these errors were encountered: