Could we build a version of Flow without doctrine orm / database requirement


(Soren Malling) #21

Not when I look at it. A customer can be a Account of a system, and have a property (ex. the Email Address, customer number) that serves as a unique identifier (accountIdentifier). I’m not a fan of the decoupling today, because I have to take care of the account identifier 2 places, if I use the email address of a Customer as account identifier.


(Bastian Waidelich) #22

If you try to look at it a tiny little bit differently, you’ll realize that it is much easier to work with (at least in the Flow world).

You don’t need to “decouple” it. If you really have that 1:1 mapping between Customer and Account, just make it a 1:1 relation. For example like this:

/**
 * @Flow\Entity
 */
class User
{
    /**
     * @var Account
     * @ORM\OneToOne
     */
    protected $account;

    public function getEmailAddress()
    {
        return $this->account->getAccountIdentifier();
    }

    // ....

Wouldn’t that work for you?


(Christian Wenzel) #23

Just a small example: we use signup via E-Mail, Google, Facebook, Twitter. So the identifier might be a social media ID or just the E-Mail. This also allows the user to connect multiple solutions (e-mail and facebook - because that gives more options like “what your friends liked” etc.) We also use the Neos.Party Package and have the E-Mail address saved there. Yes we need to see that they don’t split apart for the E-Mail Login but i really love how easy it was to implement with Flow.


(Soren Malling) #24

And the first commit for this is in review