Dan,
Agreed: we usually use a NON_EMPTY_VALIDATOR if we support the Expression Language. Which is a bit lame because that means that if you want to use the Expression Language you can’t provide configuration-time validation. This is probably a nice place to give some thoughts. I can imagine two different things that could be done to improve this: Allow configuration-time validation to occur when the EL is not used (I.e., when the user doesn’t enter an Expression). So for example, it would be nice if PutEmail supported the Expression Language but in the case that EL is not used it could validate the e-mail address against a regex. We do have some users doing this sort of thing with their own custom processors. But it’s a bit hokey to implement because the validator itself has to determine whether or not EL is being used. Maybe the framework should make this easier. The difficult part here, I think, is providing a clean API that allows the developer to specify that they want validation run always or only when not using EL, etc. Perhaps PropertyValue should support an isValid() method, so that at runtime at least the develop can say “context.getProperty(MY_PROPERTY).evaluateExpressions(flowFile).isValid()” and if not handle appropriately. This would resolve the values of the Expression and then run against the validators assigned to the PropertyDescriptor MY_PROPERTY. Perhaps we could support this by providing an ‘addRuntimeValidator’ method in addition to ‘addValidator’ on the PropertyDescriptor’s builder? Thoughts, anyone? From: Daniel Bress Sent: Monday, February 16, 2015 9:15 AM To: [email protected] Devs, I noticed that PutEmail does not validate the contents of the From/To/CC/BCC fields, so I thought I would write a regular expression to validate it, and attach it to the properties. I did this and it works great, UNLESS the user enters an expression language for the email addresses. Because then my newly added validation fails. Would it be possible to validate the result of the expression language execution, rather than the EL it's self? As it is implemented I have two questions/concerns: Is there any reason to let people add validators when using expression language? It feels like it would only make sense to have a NON_EMPTY_VALIDATOR on an EL property. It feels like this presents developers with a choice: a) support expression language, b) have the ability to validate the fields real meaning in the UI I understand this is not a huge issue, and probably requires a lot of thought(that you probably already have done), but I noticed it in PutEmail this morning and bring it up and see what everyone thinks. Thanks! Dan Bress Software Engineer ONYX Consulting Services
