Default encoder implementation is great, but i think it's bundles purpose,
not component.
If we need a common encoder, lets simply write it as library & use it inside
DoctrineUserBundle or even make encoder bundle itself. And if it's not good
for end user - he will always have ability to override
I think its good in theory, but would cause confusion, since there'd be no
default implementation.
I like having default encoders, so that users can see how this could be
implemented without
looking at documentation.
On Thu, Dec 16, 2010 at 8:59 AM, Konstantin Kudryashov
wrote:
> +1 on that
> ---
+1 on that
---
http://about.me/everzet/bio
On Wed, Dec 15, 2010 at 19:17, Fabien Potencier <
fabien.potenc...@symfony-project.com> wrote:
> After reading the IRC logs about this topic (1) and the comments on the
> pull request (2), I'm in favor of the first option described by Jonhannes:
>
> "M
After reading the IRC logs about this topic (1) and the comments on the
pull request (2), I'm in favor of the first option described by Jonhannes:
"Moving encoder to the account by effectively removing all encoder
classes, and adding encodePassword(), and isPasswordValid() to
AccountInterface"
On 01.12.2010, at 14:52, Lukas Kahwe Smith wrote:
> the provider handles comparing the submitted password with the one stored in
> the provider. however in order to initially store the hashed password there
> doesnt seem to be any facility to easily figure out what password encoder is
> set fo
