[eluser]boltsabre[/eluser]
Quote:code first before design
Ha, I like that, it's a bit like trying to write a book before you even have an idea!
As for how much you "design", it really depends on what you are trying to code... if you are making a 5 page static website for a plumber, you can more than likely get all the design elements done in an hour at the most.
However, if you are planning a larger, more complex, "dynamic" website, then without a doubt you must do A LOT of planning.
I'll just pick on example. A register/login/logout system. Sounds easy enough right!
But lets look at it a little more...
Who are your users?
Obviously the people will be logging in/out. But what about "admins" to do manual password resets, or editing user data, or deleting account, or blacklisting, or "watch", etc etc. Damn it... all of a sudden you now have 2 user groups interacting with it in different ways, already creating headaches.
What data do you need?
Sounds easy again right! First name, last name, email, password, username. They would be the most basic. But wait... does username have to be unique? If so then you have to work this into your "register" form. What about email? Unique as well? Will you check that it's a valid email address? If so how... using some stupid function (trust me, it's virtually impossible to code a complete "is this a valid email address function), so that leave the "two step" registration where you send them an email with an account activation email. But now you have "registered_not_confirmed" users and "reistered_and_confirmed" users.
What about date of birth? Do they have to be over 18? If so, then you'll have to work out some validation function to check for this. Drivers licence number? Social security number. Address? Postal Address? Work Address? Phone number, ph.num 2, mobile number, mob.numb2, fax, website, etc etc. What validation rules doe they all have to match.
What are the use cases.
Register... okay, a register form, easy! Ummm. no. Not only do you have to work out all the data you need and the validation rules as mentioned above, but you will need that "2 step register" use case as well.
Now you have to work out how to handle all that together.
Login... again, no so easy. You'll have to work out how you'll store it in the session. Can they only log in by email address, or with a username, or both? What security related measures must you consider?
Okay... if only parts of the site are restricted and a user gets to a restricted part and see's the login/register page, where do you redirect them after successful login/registration. Not as easy as it sound to redirect them back to the page there were previously on.
Logout... pretty simple...
Okay, so now you have register, activate account, login, and logout. But you'll more than likely want an view, edit, and delete profile... when they edit their username/email, you'll have to make sure that it's still unique. When they delete an account, how do you handle this? What happens when they come back and create a new account with the same email....if the DB has a "deleted=1" for their old account they wont be able to, because the email wont be unique as it already exists in the db.
And I could go on and on and on about this register/login/logout/profile manager stuff for hours, it's a MASSIVE subject (but luckily there are existing well implemented auth libraries out there!)
Without some pretty hefty planning at the start, you can see how this would have ended up a complete mess, more than likely full of security holes, bugs, and all kinds of horrible things.
If you are planning on starting a complex dynamic website, I suggest you go and research some UML, website/software design life cycles (waterfall, RAD, JAD, Agile, just to name a few, but just start with waterfall if this is your first time and it's a 1 person project).
