don’t think that can work just like that because without the varargs interface, BOTH the ValidationHookFactory AND its client (i.c. DataManager) would need to be changed. The varargs interface makes it more flexible on 1 side, but the caller side still needs to deal with the actual values required for the actual parameters.
I prefer to keep the proposal as it is for now, unless someone thinks it would be better or clearer to just use a fixed argument list instead.
Maybe it’s better about the ValidationFactory, can be provided a default one and if specific one required, subclass it. If the ValidationFactory can be injected as the ValidationHook to DataManager then at least no need to change DataManager, that would be great.
But no clear if will work, I have no clear on the actual parameters for the actual use case and also no idea what others can be required. If makes sense for you about ValidationFactory, seem a good option. Otherwise if no possible actual proposal seem fine, at least the validation custom code is not inside DataManager.
if Jeeves were adapted to allow for defining >1 ValidationHook, it could also gather which parameters are needed for each from there, e.g.
But you’re right, still a code change in DataManager would be required to actually provide the specific values for each of the implementations. The advantage of the varargs interface is that this is the only code change that would be necessary for it (otherwise, also ValidationFactory would need to be changed to accomodate for each implementation). I think the DataManager code change is unavoidable, as the parameters will have to be supplied from somewhere.
Once we have Spring dependency injection that could be addressed by injecting a subclass of DataManager instead of the vanilla one, that overrides postValidate(), I think.
Ok, but my concern is that then if supported >1 ValidationHook (and seem each can require different parameters) then also DataManager code requires to be changed, so no that pluggable.
@François: this user wants to store information about the results of the validation inside the metadata itself;
@Jose: it is still only possible to define 1 hook, as I didn’t change Jeeves to make it possible to have >1 element with the same name in (or to have elements with a different strcuture than they do now). Even so, an implementation using different parameters will need to change the invocation of ValidatonHookFactory.onValidate() in DataManager.postValidate(). If it were possible to define >1 ValidationHook then they all should be invoked from there, with whatever parameters they require.
Just one question about the params (Object… args) for onValidate. If I understand well the new method postValidation will invoke onValidate for all hooks configured, so in that case the arguments should be the same for all hooks, no? In that case, I think better to explicit define a fixed list of params required.
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
+1 from me.
It sounds like this can be extended further in the future, so it looks good to me as a starting point now.
Jeroen
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.
_________________________Jeroen Ticheler
GeoCat bv
Veenderweg 13
6721 WD Bennekom
Tel: +31 (0)6 81286572
don’t think that can work just like that because without the varargs interface, BOTH the ValidationHookFactory AND its client (i.c. DataManager) would need to be changed. The varargs interface makes it more flexible on 1 side, but the caller side still needs to deal with the actual values required for the actual parameters.
I prefer to keep the proposal as it is for now, unless someone thinks it would be better or clearer to just use a fixed argument list instead.
Maybe it’s better about the ValidationFactory, can be provided a default one and if specific one required, subclass it. If the ValidationFactory can be injected as the ValidationHook to DataManager then at least no need to change DataManager, that would be great.
But no clear if will work, I have no clear on the actual parameters for the actual use case and also no idea what others can be required. If makes sense for you about ValidationFactory, seem a good option. Otherwise if no possible actual proposal seem fine, at least the validation custom code is not inside DataManager.
if Jeeves were adapted to allow for defining >1 ValidationHook, it could also gather which parameters are needed for each from there, e.g.
But you’re right, still a code change in DataManager would be required to actually provide the specific values for each of the implementations. The advantage of the varargs interface is that this is the only code change that would be necessary for it (otherwise, also ValidationFactory would need to be changed to accomodate for each implementation). I think the DataManager code change is unavoidable, as the parameters will have to be supplied from somewhere.
Once we have Spring dependency injection that could be addressed by injecting a subclass of DataManager instead of the vanilla one, that overrides postValidate(), I think.
Ok, but my concern is that then if supported >1 ValidationHook (and seem each can require different parameters) then also DataManager code requires to be changed, so no that pluggable.
@François: this user wants to store information about the results of the validation inside the metadata itself;
@Jose: it is still only possible to define 1 hook, as I didn’t change Jeeves to make it possible to have >1 element with the same name in (or to have elements with a different strcuture than they do now). Even so, an implementation using different parameters will need to change the invocation of ValidatonHookFactory.onValidate() in DataManager.postValidate(). If it were possible to define >1 ValidationHook then they all should be invoked from there, with whatever parameters they require.
Just one question about the params (Object… args) for onValidate. If I understand well the new method postValidation will invoke onValidate for all hooks configured, so in that case the arguments should be the same for all hooks, no? In that case, I think better to explicit define a fixed list of params required.
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands http://GeoCat.net
–
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands http://GeoCat.net
–
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net for details.
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands http://GeoCat.net
Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/