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
We were using class based projections and had a variable named vendorContactName and vendorContactEmail1 with paths vendorContact.name and vendorContact.email1 respectively. The latter would not work until I switched to an interface based projection and used @Value annotation so that I could preserve the dot notation. Now that the workaround is out of the way, how about an improvement to PropertyPath.from, so we could continue to use class based projections should we want to (without renaming our variable to emailOne, emailTwo, etc?
I think all that is needed is a RegEx change in the create method (of 4 parameters):
From Pattern pattern = Pattern.compile("\\p{Lu}\\p{Ll}*$");
To Pattern pattern = Pattern.compile("\\p{Lu}[\\p{Ll}\\d]*$");
This would allow the code to handle the trailing digits (by considering them lower-cased letters?) and actually try alternatives.
I'm not certain if digits should also be considered for upper-cased letters either. I know, digits and camel case are not good friends. But perhaps there's something for the case of, addressLine1, addressLine2, addressLine3.
Thanks for your time.
The text was updated successfully, but these errors were encountered:
We were using class based projections and had a variable named vendorContactName and vendorContactEmail1 with paths vendorContact.name and vendorContact.email1 respectively. The latter would not work until I switched to an interface based projection and used
@Value
annotation so that I could preserve the dot notation. Now that the workaround is out of the way, how about an improvement toPropertyPath.from
, so we could continue to use class based projections should we want to (without renaming our variable to emailOne, emailTwo, etc?I think all that is needed is a RegEx change in the create method (of 4 parameters):
From
Pattern pattern = Pattern.compile("\\p{Lu}\\p{Ll}*$");
To
Pattern pattern = Pattern.compile("\\p{Lu}[\\p{Ll}\\d]*$");
This would allow the code to handle the trailing digits (by considering them lower-cased letters?) and actually try alternatives.
I'm not certain if digits should also be considered for upper-cased letters either. I know, digits and camel case are not good friends. But perhaps there's something for the case of, addressLine1, addressLine2, addressLine3.
Thanks for your time.
The text was updated successfully, but these errors were encountered: