On 03.11.2010, at 20:59, Lukas Kahwe Smith wrote:
>
> On 03.11.2010, at 14:44, Bernhard Schussek wrote:
>
>> The last solution is to have two properties in your class of which one
>> contains the plain text password (which is not persisted) and the
>> other the persisted hashed password.
>>
>> class User
>> {
>> /**
>> * @validation:MinLetters(1)
>> */
>> protected $password;
>>
>> /**
>> * @PersistMe
>> */
>> protected $hashedPassword;
>>
>> public function setPassword($password)
>> {
>> $this->password = $password;
>> $this->hashedPassword = hash_me($password);
>> }
>> }
>>
>> IMO that last solution is the cleanest one, because it works
>> regardless of whether you call setPassword() from a form or from
>> somewhere else.
>
>
> right .. i agree. and this was actually the first thing i wanted to do when
> i realized how the validation currently works. but i dont like doing this
> work inside the entity, since its already done inside the EM. of course you
> can say its better to keep the entity independent of the EM.
>
> anyway, i found that lifecyclecallbacks do not get this information passed to
> them .. only if you register a listener do you get the fetched version of the
> data to do this kind of comparison and this is of course way to heavy in
> terms of code written and code executed.
err actually nevermind. the approach bernhard explains is different from what i
am describing. i was talking about being able to compare the version of the
data as it was fetched from the database with the version that is being
submitted to the database to determine if additional processing is necessary.
and bernhard is suggesting to always set the raw version on a property that has
the validation and then set another property which is persisted on which the
additional processing is done.
i do see some benefit in what bernhard is doing, the only draw back is that the
processing will even be triggered if the validation fails. i can see that
sometimes the processing is expensive in terms of cpu cycles or potential fees
having to be paid or both.
regards,
Lukas Kahwe Smith
[email protected]
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
