Jason,

You might want to bring this up to a wider audience - this is not an OpenBD
question/issue, but a general cfml-one, maybe cf-talk for instance... ?

Cheers,
Hugo

--
Hugo Ahlenius
fraxinus (at-sign) oxel.net
http://www.oxel.net 




| -----Original Message-----
| From: Jason Allen [mailto:[email protected]]
| Sent: Wednesday, December 02, 2009 22:23
| To: Open BlueDragon
| Subject: How is my code for member registration?
| 
| I'm building a website that is going to require membership. I've
| designed a database structure (Microsoft SQL Server) that fits well
| for this application. I have the registration AND login process
| working. So from an end user perspective, everything functions just
| fine. You can register and login.
| 
| Now that I have this in place and I have code that gets what I need
| done, done, I want to take a second look at it, audit it, get outside
| opinions, and rebuild it if necessary. I figure that even if it needs
| to be redone, I have enough code already that most of the thinking is
| done.
| 
| Since I believe my needs for a user database are going to be very
| similar to many other sites, I'm hoping I can get some insight from
| the OpenBD crowd in exchange for what would become a valuable thread
| for others trying to do something similar.
| 
| I have the process broken into 3 parts/documents.
| 
| step1.cfm - registration form and verification
| step2.cfm - submission of form data to database
| verification.cfm - activates account
| 
| I'll include the code for each in subsequent posts. I've removed the
| lengthy display data, which is just the html that is used to display
| everything. You'll see a tag that says <div> content </div> where the
| display code would be.
| 
| With step1.cfm there is basically two parts to the document. 'Showform/
| NotShowForm'. The document starts out declaring all the needed
| variables and querying for the data it needs. There are some checks
| that determine if the form is complete or not. If it is not complete,
| or the user just pulled up the page and hasn't submitted anything,
| 'showform' will be 1, meaning the form to enter all the data needs to
| be displayed AND the supplied data (or lack of data) will not be
| submitted for verification. Once enough data is provided, showform is
| set to 0, in which this means that the user has provided sufficient
| information through the form. When show form is set to 0, it instead
| displays the data as the user submitted it, asking them to verify that
| it is ok.
| 
| Once they hit submit, the data is pass to step2.cfm, where it is
| inserted into the database, sends an email to the user (so they can
| click a link to verify the email address), and displays a 'thank you'
| message. At this point, all of the user data is setup in the database,
| and their account is flagged as 'new'. Once they get the email and
| click the link to verify, the account will be flagged as 'active' and
| they will be able to login and create a session.
| 
| The 3rd step is the email verification part, which there really isn't
| much to. It just updates the database to change the user status from
| 'new' to 'active'. If anybody can take a look and offer advice or
| approval of the code in its current state, I would be greatly
| appreciative.
| 
| Below, in the next few posts, I'll include the code I've written for
| these three files.
| 
| --
| Open BlueDragon Public Mailing List
|  http://www.openbluedragon.org/   http://twitter.com/OpenBlueDragon
|  mailing list - http://groups.google.com/group/openbd?hl=en
| 
|  !! save a network - please trim replies before posting !!

-- 
Open BlueDragon Public Mailing List
 http://www.openbluedragon.org/   http://twitter.com/OpenBlueDragon
 mailing list - http://groups.google.com/group/openbd?hl=en

 !! save a network - please trim replies before posting !!

Reply via email to