Validating properties that also support Expression Language

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Validating properties that also support Expression Language

Dan Bress
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
Reply | Threaded
Open this post in threaded view
|

Re: Validating properties that also support Expression Language

Mark Payne
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: [hidden email]





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
Reply | Threaded
Open this post in threaded view
|

Re: Validating properties that also support Expression Language

Brandon DeVries
Dan,

     Also, in this case just note that validating email addresses with a
regex isn't trivial:

http://www.regular-expressions.info/email.html

     We would probably want to err on the permissive side...

Brandon

On Mon, Feb 16, 2015, 9:55 AM Mark Payne <[hidden email]> wrote:

> 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: [hidden email]
>
>
>
>
>
> 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