On 7.9.2015 11:46, Niclas Hedhman wrote:
The value in the annotation is solved by field/constructor injection and is
not an issue (I think).
Currently in Zest, (AFAIK) the constraints can't have any injections.
That is IIRC because they are not managed from composite-wide instance
pools (since some injections require 'taking ownership' of the fragment,
since they are not thread-safe, or value varies depending on which
composite instance is currently using fragment).
The same goes for Qi4CS: constraint instances are pooled on whole
application level.
If you guys get to implement this without running into any issues or
problems, I might do the same in Qi4CS as well.
Been thinking about this for a while, and allowing injections on
constraints as well would make things nicely symmetric and orthogonal,
since now constraints are a little 'special snowflakes' in Zest/Qi4CS
world.
On Sep 7, 2015 16:41, "Paul Merlin" <[email protected]> wrote:
Niclas,
Just some thoughts ...
Niclas Hedhman a écrit :
Thinking a little bit outside our current box....
public interface Abc
{
void doSomething( @URL String url );
}
module.values( Abc.class ).for( URL.class ).constrainWith( url ->
checkUrlFormat(url) );
module.for( URL.class ).constrainWith( new UrlChecker() );
I have started to experiment a little around this... More follows later.
Ok, after digging in this for an hour or so, I have discovered more
features...
The above is the default implementation, and it is then possible to throw
other implementations at the composite, and in that way override the
Constraint check declared in the annotation. There is also the Composite
Constraint feature (which I want to replace with factory instead)
The mechanism uses the fact that the Constraint implementation contains
the
Annotation type as a generics argument, and that is how they are matched.
IF I go with Predicate, there is no such possibility, unless the
Predicate
itself is annotated (I think not so nice).
Having a handle to the annotation in constraint implementations also
allow access to values of the constraint annotation parameters. Eg.
@Min( 3 ).
So, the immediate question is; How desirable is this "override" feature?
Is
there any other way to achieve the same functionality?
I understand this "override" feature as "changing the constraint
implementation referenced by a constraint annotation at assembly time".
I have no usecase in mind.
/Paul
