Τα profile properties αφορούν χρήστες του Membership. Εξάλλου αφορούν κάτι εντελώς διαφορετικό από αυτό που συζητάμε: πως θα αποθηκεύσεις επιπλέον πληροφορίες για κάθε χρήστη. Αυτό που συζητάμε έχει να κάνει με το πως θα εκτελέσεις παραγγελίες για όσους δεν είναι μέλη.
Η αλήθεια είναι ότι η ερώτηση είναι λίγο περίεργη. Προφανώς και μπορείς άνετα να δείξεις μία φόρμα όπου οι πελάτες θα συμπληρώσουν τα στοιχεία της παραγγελίας. Η φόρμα αυτή δεν χρειάζεται να συμπληρωθεί παρά μόνο όταν κάποιος φτάνει στο checkout. Το θέμα καταρχήν είναι αν θέλεις να ολοκληρώσεις την παραγγελία χωρίς να φτιάξει ο άλλος username/password. Αν για παράδειγμα θέλει να δει την εξέλιξη της παραγγελίας του πως θα το κάνει? Λύσεις υπάρχουν, π.χ. να σου στείλεις ένα URL με ένα κλειδί για την παραγγελία του, αλλά θα πρέπει να σκεφτείς πως θα τον προστατέψεις αν παραπέσει το URL (π.χ. εμφανίζοντας περιορισμένα στοιχεία).
Αν αυτός ο πελάτης που δεν χρησιμοποιεί username επιστρέψει, δεν θέλεις τα στοιχεία του? Θα πρέπει να τα ξανασυμπληρώσει όλα? Θα τον καταχωρήσεις ως νέο πελάτη στη βάση? Ακόμα και αν το ονοματεπώνυμο ενός πελάτη είναι το ίδιο με κάποιου άλλου, δεν μπορείς να θεωρήσεις ότι είναι το ίδιο άτομο.
Αν αυτό που σε απασχολεί είναι να μην χρειάζεται ο χρήστης να δημιουργήσει άλλο ένα username/password, μπορείς να χρησιμοποιήσεις OAuth authentication και έτσι να του επιτρέψεις να χρησιμοποιήσει το Google ή το Facebook account του.
Όσον αφορά το membership, δεν υπάρχει κάποιος λόγος η παραγγελία να εξαρτάται από το Membership. Μάλιστα θα έλεγα ότι είναι λάθος μεγάλο να μπει αυτή η εξάρτηση. Κανονικά οι πίνακες παραγγελιών, πελατών κλπ θα πρέπει να είναι εντελώς ανεξάρτητοι από το Membership. Το κλειδί του πελάτη θα πρέπει να είναι το κλειδί του πίνακα των πελατών, όχι το username ή το Membership ID. Το κλειδί αυτό μετά μπορείς να το αποθηκεύσεις ως profile property για το χρήστη και να το φορτώνεις όταν αυτός κάνει login.ω
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos