[Flow] Using aspects to change EmailAddressValidator

[Steffen Wickham]

I totally agree, AOP is the last solution you should looking for 
otherwise your code is "defective by design". But as mentioned that was 
the last solution I could take. Maybe I drop ElectronicAddresses 
completly and put in an easier implementation. Now I'm really happy I 
had implemented some abstraction to access the e-addresses through my 
main user class called "Referee" so it would be easier to access this data.

Yeah, I'm aware of using Person model too. As you did, I derived my 
Referee class from AbstractParty too, but use the same implementation as 
Person (please don't ask why, I really don't know). So it won't hurt 
much to replace ElectronicAddresses. I pretty sure I will replace it 
(very) soon.... ;-)

Best wishes!




Am 06.01.14 16:59, schrieb Bastian Waidelich:
> Steffen Wickham wrote:
>
> Hi Steffen,
>
>> I achieved a solution for my problem by changing the "isValid()" method
>> of ElectronicAddressValidator class of TYPO3.Party package via AOP. It
>> is no clean way, anyway it works at the moment.
>
> Good news!
> As a rule of thumb you should try to avoid AOP if you don't need it 
> because it adds a level of complexity and obscurity to your code base. 
> But in this case I don't see a better way currently.
>
> What I had in mind was an entry in Objects.yaml like:
>
>  TYPO3\Flow\Validation\Validator\EmailAddressValidator:
>   className: 'Your\Package\Validation\Validator\EmailAddressValidator'
>
> But I just realized that overriding the implementation class name only 
> works for interfaces so that won't work.
>
>
>
>> But I will have a look on the behaviour of AOP in conjunction with the
>> validatorResolver in a few days. There seems to be a bug which prevents
>> the framework to apply aspects to the called methods. Will keep you
>> updated.
>
> I'm not aware of bugs in that area. So, yes, please keep us posted.
>
>
>> Thanks guys! :)
>
> You're welcome ;)
>
>
> BTW: I tend to avoid the person model of the package for my 
> applications as its making many scenarios more complicated than they 
> need to be. If you don't need all the flexibility of multiple 
> "electronic addresses" and names I'd suggest to create a minimal 
> person model that extends AbstractParty (see [1] for an example). It 
> makes your code easier to read/maintain and you have all the power 
> over validation rules etc.
>
>
>
> [1] https://gist.github.com/bwaidelich/6292221
>