Comparing revisions for RegisterAction

Additions:
>>==See also:==
Documentation: ""RegisterActionInfo"".>>This is the development page for the Register action.::c::
Current version: 0.2
~-Added welcome stuff for first login;
* @version 0.2
if ($this->GetConfigValue("allow_new_users") == "0") {
print $this->Format('//User registration is disabled on this wiki//');
} else {
if ($user = $this->GetUser()){
// is this the first time the user is logged in?
if ($_GET['reg'] == 'ok') {
// first login welcome stuff
print $this->Format('--- **Registration successful!** --- --- You are currently logged in as '.$this->GetUserName());
} else {
// print user information
print $this->Format('--- You are currently logged in as '.$this->GetUserName());
} else {
print "<script type=\"text/javascript\"><!-- \nfunction hov(loc,cls){ \n if(loc.className) loc.className=cls;\n}\n //-->\n</script>\n";
if ($_POST) {
if ($_POST['name']) $name = trim($_POST['name']);
if ($_POST['email']) $email = trim($_POST['email']);
if ($_POST['password']) $password = $_POST['password'];
if ($_POST['confpassword']) $confpassword = $_POST['confpassword'];
// todo: add icons on non-valid fields
if ($this->LoadUser($name)) {
$error = 'Sorry, this username already exists. Please choose a different name.';
} elseif ($this->ExistsPage($name)) {
$error = 'Sorry, this username is reserved for a page. Please choose a different name.';
} elseif (!$this->IsWikiName($name)) {
$error = 'Please fill in a valid username (formatted as a ##""WikiName""##).';
} elseif (!isset($email)) {
$error = 'Please specify an email address.';
} elseif (!preg_match("/^.+?\@.+?\..+$/", $email)) {
$error = 'That does not quite look like an email address.';
} elseif (!isset($password)) {
$error = 'Please choose your password.';
} elseif (strlen($password) < 5) {
$error = 'Sorry, password too short.';
$error = 'Sorry, spaces are not allowed in passwords.';
} elseif (!isset($confpassword)) {
} elseif ($confpassword != $password) {
} else {
"password = md5('".mysql_real_escape_string($_POST["password"])."')");
$this->Redirect($this->href('','','reg=ok'));
~-a **valid password** (min. 5 characters, no space allowed).
$form .= ' <table summary="Form to provide registration data: username, email and password">';
=== Implemented modifications ===
$form .= '<label>Confirm password:<input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></label>';%%
~~&
~~& %%(php;128)
CategoryDevelopment
Deletions:
>>**See also:**
~-UserAccountModules
~-Documentation: ""RegisterActionInfo""
~-Test: RegisterActionTest
~-Related: Nils' UserRegistration.
>>This is the development page for the Register action.::c::
''[2005-02-25] action uploaded on this site as a beta feature: RegisterActionTest (you'll need to logout to test it)''
Current version: 0.3
~-Added redirect to WelcomeUser for first login (in the future redirect page will be configurable - see RedirectOnLogin);
~-Variable initialization and constants section;
* @version 0.3
// constants
define('MIN_PASSW_LENGTH', '5');
define('DEFAULT_REDIRECT_TO', 'WelcomeUser');
if ($this->GetConfigValue('allow_new_users') == '0')
{
print $this->Format('//User registration is disabled on this wiki//');
} else
{
if ($user = $this->GetUser())
{
// initializing variables
$name = '';
$email = '';
$password = '';
$confpassword = '';
$error = '';
// is this the first time the user logs in?
if ((isset($_GET['reg'])) && ($_GET['reg'] == '1'))
{
switch ($this->GetConfigValue('allow_new_users'))
{
default:
case 0:
// print first login welcome screen
print $this->Format('--- **Registration successful!** --- --- You are currently logged in as '.$this->GetUserName());
break;
case 1:
// redirect to welcome page
$this->Redirect($this->href('', DEFAULT_REDIRECT_TO));
break;
case 2:
// redirect to referrer page
$this->Redirect($this->href('', DEFAULT_REDIRECT_TO));
break;
} else
{
// user is already logged in: print user information
print $this->Format('--- You are currently logged in as '.$this->GetUserName());
} else
{
if ($_POST)
{
if (isset($_POST['name'])) $name = trim($_POST['name']);
if (isset($_POST['email'])) $email = trim($_POST['email']);
if (isset($_POST['password'])) $password = $_POST['password'];
if (isset($_POST['confpassword'])) $confpassword = $_POST['confpassword'];
if ($this->LoadUser($name))
{
$error = 'Sorry, this username already exists. Please choose a different name.';
} elseif ($this->ExistsPage($name))
{
$error = 'Sorry, this username is reserved for a page. Please choose a different name.';
} elseif (!$this->IsWikiName($name))
{
$error = 'Please fill in a valid username (formatted as a ##""WikiName""##).';
} elseif (!$email)
{
$error = 'Please specify an email address.';
} elseif (!preg_match("/^.+?\@.+?\..+$/", $email))
{
$error = 'That does not quite look like an email address.';
} elseif (!$password)
{
$error = 'Please choose your password.';
} elseif (strlen($password) < MIN_PASSW_LENGTH)
{
$error = 'Sorry, password too short (min. '.MIN_PASSW_LENGTH.' chars).';
$error = 'Sorry, spaces are not allowed in passwords.';
} elseif (!$confpassword)
{
} elseif ($confpassword != $password)
{
} else
{
"password = md5('".mysql_real_escape_string($password)."')");
$this->Redirect($this->href('','','reg=1'));
~-a **valid password** (min. '.MIN_PASSW_LENGTH.' characters, no space allowed).
$form .= ' <table summary="Form to provide registration data: username, email and password">';
$form .= ' <caption>Registration form</caption>';
if (isset($error))
{
$form .= ' <th align="right" scope="row"><label for="name">Your username:</label></th>';
$form .= ' <td><input name="name" id="name" size="40" value="'.$name.'" title="Choose a valid username (formatted as a WikiName)" /></td>';
$form .= ' <th align="right" scope="row"><label for="email">Your email address:</label></th>';
$form .= ' <td><input name="email" id="email" size="40" value="'.$email.'" title="Fill in a valid email address"/></td>';
$form .= ' <th align="right" scope="row"><label for="password">Your password:</label></th>';
$form .= ' <td><input type="password" name="password" id="password" size="40" title="Choose a valid password (min. '.MIN_PASSW_LENGTH.' chars, no space)" /></td>';
$form .= ' <th align="right" scope="row"><label for="confpassword">Confirm password:</label></th>';
$form .= ' <td><input type="password" name="confpassword" id="confpassword" size="40" title="Type again your password for confirmation" /></td>';
$form .= ' <td><input type="submit" value="Register" title="Register" /></td>';
''See RegisterUserIpAddress for a small (security-related) modification. --JavaWoman''
=== Discussion ===
$form .= '<label>Confirm password:<input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></label>';%%::c::
~
~~
~~& %%(php;127)
%%::c::
~~~&I think you are (respectfully) wrong. That you may intepret a submit button as "data" is stretching the //very notion of data in my opinion//! ;) In this particular case the table is not providing **any** semantic information that could not be more elegantly be provided by removing the redundant table tags. It is being used as a presentational aid and that is wrong: "Tables should not be used purely as a means to layout document content" (W3 HTML 4 documentation). To provide semantic "sections" within forms, there is <fieldset/> expressedly for that purpose, along with <legend/> for titling. --IanAndolina
~~~~&Using a **data** table to **structure data** (inside or outside of a form) is not using it as a representational aid, but using it exactly for what data table markup is intended for. Marking up form content (a form with more than a single field at least) this way is also helpful for people using screen readers, precisely because it //is// a //data// table (and not a //layout// table): they can choose to browse the content in table mode (representing the data structure, to get an overview of the content) as well as in form mode (to enter or modify the data). I know there are such things as field sets, etc. - but they can't do what the data table is doing here: presenting the **data structure**. Arranging a data structure in rows and columns (and more complicated variants of that) is precisely what data tables are for - and precisely for that reason the markup I've used is **not** a that of a layout table (which uses //nothing but// ##table##, ##tr## and ##td## elements) but that of a data table (with a ##summary##, a ##caption##, and table header cells (##th##) associated with their corresponding data cells (##td##) - none of which are even allowed in a layout table). If you would merely **present** these data, you //would// use a data table. Making those same data editable by means of a form does not suddenly rob it of its data structure: so the data table markup is equally applicably to data that is merely presented and to data that is editable: it is the same data structure after all, with an extra facility (editablility) added to it! --- I know there are "schools" trying to get rid of //all// tables - but that is (respectfully) the wrong approach. Data tables provide a rich markup to present data structures which is not preempted by using a form but can work in conjunction with it. The result provides both visually explicit structure (for those who can see it) as well as a markup structure for those who use assistive technology and like to explore the data structure before (possibly) entering or modifying data. It gives people using assistive technology a choice (corresponding to "scanning" the rows and columns of a form by those who can see) that would simply be missing if data table markup weren't used. While this isn't required by accessibility standards, it definitely isn't wrong either; in fact it's appreciated by most, and it doesn't get in the way for those who want to use only "form mode". --- When you say that a submit button is not data, you are right, of course. :) A refinement of my code (I did say it was not in a final form...) would be to take the submit button outside of the form, leaving the data table to only structure the //data// in the form (and not the form itself). --- If you browse this site, you'll see I always advocate not using tables for layout (that's why the still somewhat experimental new [[WikkaBetaFeatures category action]] is no longer using a table!) but vice versa I also advocate using **data** table markup - instead of **layout** table markup - when presenting an actual data structure (see JwCalendar, for instance). --- The markup presented here conforms not only to the XHTML (1.0, and even 1.1) standard, but to WCAG as well. You may not like it - but it's not wrong. --JavaWoman---
~~~~~&--- ---I have //no// problem with tables being used for __**##tabular##**__ data (and I've seen your many positive contributions in regards to semantic markup here)! The issue here is that you stretch your definition of a select box for example to be data which is not ##**tabular**## at all. A table by definition (derived from the latin for board, //tabula//) is composed of rows and columns; where does the 3rd dimension of a select box come into such a 2-dimensional structure, or the variable state switching of radio selects? The answer is they don't fit cleanly into a clearly defined understanding of what tabular data marked up in rows and columns is. And if you can say a select box is data, then Mr. Frontpage Designer can retort so is his 10px mauve spacing graphic; it is visual data that fits more cleanly into the rows and columns of tabular data than radio selects ever will…--- --- Let me put it another way, I suggested we use fieldsets, which are standard HTML //designed for forms// and markup your form elements using clearly defined labels wrapping form element (or using the for attribute as you have done). The semantics of such a form is clear, well-defined and I simply don't understand //why// you need to try to impose tabular constraints on such a thing; it is superfluous.--- --- "Everything should be made as simple as possible, but not one bit simpler." — Albert Einstein --- --- I am curious to know what is the table bringing us that a well built-form isn't? For assistive technologies, the semantics of <fieldset><lable><element/></label></fieldset> are clear. For the next generation of CSS powered small-screened devices, tables are treated differently to form markup, and thus rendered differently (thus tables should stick to tabular data at all times). There is no need for the table; all information that is needed about relationships in the form for assistive technologies are inherent to its design already. As the table is adding a lot more underlying mark-up and weight, **it is for the table to prove its worth in this situation not the other way round! ;)** --- --- As a final point, why are you using **align="right"** in the table, //that is presentational!// This brings me to my final point, that both forms and tables should be styled using CSS **always**. Using your table as table OR table as form data organiser you need to include extra classes to give your CSS traction and thus litter your mark-up with the oft seen CSS disease of //classitis//! :) Using forms for forms and tables for tables simplifies the task of styling using CSS, as well as simplifing the underlying markup; it makes things easier!--- --IanAndolina---
~~~~~~&Well, I think we have to agree to disagree on the usefulness of using a data table both for presenting data and for editing the same data... :) BTW, you must have missed my remark that the code was not finished, and that the alignment of the prompts would better be handled with a stylesheet. That said, alignment attributes in a **data table** are //not// presentational (or they would be deprecated - which they are not, while they are almost everywhere else. If you think about it, I'm sure you can understand there's a reason for that. ;-)) Still, if you style the form and its enclosed table for the data structure, **no** extra classes are needed at all; contextual rules can do all you need. --JavaWoman ---
~~~~~~& OK, agreeing to disagree a done deal! ;) I apologise for not picking up on your earlier mentioning of align="right" going into CSS. But you will find that align probably **will** be deprecated in [[http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-tables.html#s_tablesmodule XHTML 2]], so it is still deemed a presentational throwback that they weren't brave enough to expunge in 1.1! If you have any links to articles defending the use of tables in forms, I'd be interested, leave them on my page here. Thank you for the interesting discussion, even if you are wrong :p (that is the stick-out tongue smiley just in case!), take care, --IanAndolina
~~~~& After ActiveDirectory, were we have "user_identification" => "wikka/activedirectory", i thought about a slightly different structure, which would allow to usse another programm for registration:
~~~~& %% "user_registration" => "wikka/(other program)/off" %%::c::
~~~~& and %% "registration_requirements" %%::c:: (anybody with a better name?) %% => "none[this is the normal registration], "no double account" [only one account per e-mail], "registercode" [which requieres another entry]. %%
~~~~& --NilsLindenberg (nice work, btw :)
Much better... a few more comments:
~1)The variables are still not being initialized. If a user does not provide a value when submitting the form, the variable won't be set - and then you're trying to use the unset variable(s) as parameters to functions and values for form fields. Try **not** excluding E_NOTICE in php's error reporting and submit an empty form - and see what you get...
~~& Humm, ok, I'll try to fix this;
~1)What's the mysterious JavaScript for? Do we even need it?
~~& No idea, inherited from ##usersettings##: I left it because I didn't know what it was needed for, I guess we can drop it...
~1)I don't think the submit button can do anything with a size attribute (missed that the first time) ---
~~& Oops, another thing inherited from ##usersettings## - will fix it.
--JavaWoman
CategoryDevelopmentActions
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki