Revision history for RegisterAction


Revision [23028]

Last edited on 2016-05-20 07:38:44 by JavaWoman [Replaces old-style internal links with new pipe-split links.]
Additions:
$intro = $this->Format(' --- If you are a **new user** you can register an account using this form (if you already have an account, please go to the [[UserSettings | login page]]). --- --- To register, the following fields are required:
~~~~&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---
~~~~~~& 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
Deletions:
$intro = $this->Format(' --- If you are a **new user** you can register an account using this form (if you already have an account, please go to the [[UserSettings login page]]). --- --- To register, the following fields are required:
~~~~&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---
~~~~~~& 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


Revision [18561]

Edited on 2008-01-28 00:11:57 by JavaWoman [Modified links pointing to docs server]

No Differences

Revision [10142]

Edited on 2005-07-19 18:09:53 by JavaWoman [adding ref to RegisterUserIpAddress]
Additions:
''See RegisterUserIpAddress for a small (security-related) modification. --JavaWoman''


Revision [9806]

Edited on 2005-07-05 15:58:54 by DarTar [adding seealso box]
Additions:
>>**See also:**
~-UserAccountModules
Deletions:
>>==See also:==


Revision [8598]

Edited on 2005-05-28 15:48:35 by JavaWoman [move to subcategory]
Additions:
CategoryDevelopmentActions
Deletions:
CategoryDevelopment


Revision [6651]

Edited on 2005-03-10 18:15:34 by DarTar [Slightly improved version (0.3)]
Deletions:
print '(from: '.$HTTP_REFERER;


Revision [6650]

Edited on 2005-03-10 18:10:39 by DarTar [Slightly improved version]
Additions:
Current version: 0.3
~-Variable initialization and constants section;
* @version 0.3
* - define welcome page where new users must be redirected;
// constants
define('MIN_PASSW_LENGTH', '5');
define('DEFAULT_REDIRECT_TO', 'WelcomeUser');
print '(from: '.$HTTP_REFERER;
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>';
=== Discussion ===
Deletions:
Current version: 0.2
* @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());
// ...or forward
$this->Redirect($this->href('','WelcomeUser'));
} 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 ===


Revision [6346]

Edited on 2005-02-26 17:51:33 by IanAndolina [final reply to JavaWoman — phew!]
Additions:
~~~~~~& 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


Revision [6345]

Edited on 2005-02-26 17:35:33 by JavaWoman [final? reply to Ian about using data tables for forms]
Additions:
~~~~~&--- ---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 ---
Deletions:
~~~~~&--- ---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--- --- ---


Revision [6344]

Edited on 2005-02-26 16:54:30 by IanAndolina [reply to JW regarding table semantics ;)]
Additions:
~~~~&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--- --- ---
Deletions:
~~~~&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
~~~


Revision [6335]

Edited on 2005-02-25 23:00:09 by JavaWoman [reply to Ian]
Additions:
$form .= '<label>Confirm password:<input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></label>';%%::c::
~
~~
%%::c::
~~~~&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
~~~
~~~~& %% "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]. %%
Deletions:
$form .= '<label>Confirm password:<input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></label>';%%
~~&
~~~~& %% "user_registration" => "wikka/(other program)/off" %%
~~~~& and %% "registration_requirements" %% (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]. %%


Revision [6334]

Edited on 2005-02-25 19:49:05 by IanAndolina [reply to JavaWoman regarding validity of using tables for presentation of forms.]
Additions:
~~~&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


Revision [6332]

Edited on 2005-02-25 18:33:22 by NilsLindenberg [comment]
Additions:
~~~~& 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" %%
~~~~& and %% "registration_requirements" %% (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 :)


Revision [6327]

Edited on 2005-02-25 16:51:03 by DarTar [Reply to JW]
Additions:
~~& Humm, ok, I'll try to fix this;
~~& No idea, inherited from ##usersettings##: I left it because I didn't know what it was needed for, I guess we can drop it...
~~& Oops, another thing inherited from ##usersettings## - will fix it.


Revision [6326]

Edited on 2005-02-25 16:46:01 by DarTar [Adding links]
Additions:
~-Documentation: ""RegisterActionInfo""
~-Test: RegisterActionTest
~-Related: Nils' UserRegistration.
>>This is the development page for the Register action.::c::
Deletions:
Documentation: ""RegisterActionInfo"".>>This is the development page for the Register action.::c::


Revision [6324]

Edited on 2005-02-25 16:40:55 by JavaWoman [praise, more comments]
Additions:
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...
~1)What's the mysterious JavaScript for? Do we even need it?
~1)I don't think the submit button can do anything with a size attribute (missed that the first time) ---
--JavaWoman


Revision [6323]

Edited on 2005-02-25 16:39:46 by DarTar [RegisterAction v.0.2]
Additions:
''[2005-02-25] action uploaded on this site as a beta feature: RegisterActionTest (you'll need to logout to test it)''
~~& %%(php;127)
Deletions:
''[2005-02-25] action uploaded on this site as a beta feature: RegisterActionTest''
* - define welcome page where new users must be redirected;
~~& %%(php;128)


Revision [6321]

Edited on 2005-02-25 16:35:13 by DarTar2 [RegisterAction v.0.2]
Additions:
~-Added redirect to WelcomeUser for first login (in the future redirect page will be configurable - see RedirectOnLogin);
// ...or forward
$this->Redirect($this->href('','WelcomeUser'));
Deletions:
~-Added redirect to WelcomeUser for first login;
// or forward
$this->Redirect($this->href('WelcomeUser'));


Revision [6319]

Edited on 2005-02-25 16:27:12 by DarTar [Register action v.0.2]
Additions:
''[2005-02-25] action uploaded on this site as a beta feature: RegisterActionTest''
~-Added redirect to WelcomeUser for first login;
// print $this->Format('--- **Registration successful!** --- --- You are currently logged in as '.$this->GetUserName());
// or forward
$this->Redirect($this->href('WelcomeUser'));
Deletions:
~-Added welcome stuff for first login;
print $this->Format('--- **Registration successful!** --- --- You are currently logged in as '.$this->GetUserName());


Revision [6318]

Edited on 2005-02-25 16:11:58 by DarTar [Register action v.0.2]
Additions:
=== The action ===
Current version: 0.2
Done:
~-Added labels and semantic markup for registration table as per JavaWoman's and IanAndolina's suggestion;
~-Removed useless hidden fields (inherited from ##usersettings##);
~-Expanded ##elseif## validations to allow further actions;
~-Added welcome stuff for first login;
~-Added done/failed icons (using menulets currently installed as beta features on this server);
To do:
~-CSS to style form;
~- (optionally) drop WikiName restriction on usernames;
~- use core functions to validate fields;
~- use central error handler for printing error messages;
~- decide best strategy to link hardcoded login/logout page;
~- define welcome page where new users must be redirected;
~- (optionally) add option for email-confirmation of registered users.
* @version 0.2
* @output form for user registration
* - CSS to style form;
* - decide best strategy to link hardcoded login/logout page;
* - (optionally) add option for email-confirmation of registered users.
if ($_GET['reg'] == 'ok') {
// first login welcome stuff
print $this->Format('--- **Registration successful!** --- --- You are currently logged in as '.$this->GetUserName());
// print user information
print $this->Format('--- You are currently logged in as '.$this->GetUserName());
if ($_POST) {
// todo: add icons on non-valid fields
if ($this->LoadUser($name)) {
$error = 'Sorry, this username already exists. Please choose a different name.';
$validname = $this->Action('failed');
} elseif ($this->ExistsPage($name)) {
$error = 'Sorry, this username is reserved for a page. Please choose a different name.';
$validname = $this->Action('failed');
} elseif (!$this->IsWikiName($name)) {
$error = 'Please fill in a valid username (formatted as a ##""WikiName""##).';
$validname = $this->Action('failed');
} elseif (!isset($email)) {
$error = 'Please specify an email address.';
$validname = $this->Action('done');
$validemail = $this->Action('failed');
} elseif (!preg_match("/^.+?\@.+?\..+$/", $email)) {
$error = 'That does not quite look like an email address.';
$validname = $this->Action('done');
$validemail = $this->Action('failed');
} elseif (!isset($password)) {
$error = 'Please choose your password.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
} elseif (strlen($password) < 5) {
$error = 'Sorry, password too short.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
} elseif (preg_match("/ /", $password)) {
$error = 'Sorry, spaces are not allowed in passwords.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
} elseif (!isset($confpassword)) {
$error = 'You need to confirm your password.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
$validconfpassword = $this->Action('failed');
} elseif ($confpassword != $password) {
$error = 'Sorry, passwords do not match.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
$validconfpassword = $this->Action('failed');
} else {
$this->Redirect($this->href('','','reg=ok'));
$form .= ' <table summary="Form to provide registration data: username, email and password">';
$form .= '<tr><td colspan="3" align="center"><span class="error">'.$this->Format($error).'</span></td></tr>';
$form .= ' <td>'.$validname.'</td>';
$form .= ' <td align="left">'.$validemail.'</td>';
$form .= ' <td align="left">'.$validpassword.'</td>';
$form .= ' <td align="left">'.$validconfpassword.'</td>';
=== Implemented modifications ===
~& Try to use SemanticMarkup if this is going to be rewritten anyway, instead of:
~& %%(php)
~&use:
~&%%(php)
~&It is more elegant, semantically clean and frees some bytes to run free in forests! --IanAndolina
~~&While I agree that ##label## should always be used for form control prompts, I **don't** agree with dropping the table. A form as a series of label-data constructs (i.e., name-value pairs) is semantically also a **data** table, especially since a form can be used not only to //enter// data but also to //(re)view// and //modify// it.
~~&But when a table is a **data** table, it should be marked up as a **data** table, with proper header cells related to the data cells, a caption, and a summary.
~~&The hidden "register" field is also superfluous, since the submit button can take care of that.
~~&
~~&We'd end up with something like this (this serves just as an example, not meant as the "final" code):
~~& %%(php;128)
~~& Note that I've also removed the if clauses for $name and $email - the fields should simply be initialized and can then directly be used in the form (moving towards a templating mindset :)).
~~& Preferably the ##align="right"## on the header cells (and maybe other styling) should be taken care of by some special "form table" rules in the stylesheet (contextual rules will be all that's necessary, no need for extra classes or id - and this will enhance a consistent layout of forms). Both right-aligning labels and a consistent layout for all forms will be helpful for usability.
~~& --JavaWoman
~~~& Thanks for your feedback, guys! I'll patch the action with your suggestions asap. I was thinking that maybe we might want to add more options related to user registration in ##wikka.config.php##.
~~~& E.g.:
~~~& %% "allow_new_users" => "0",%% Disables new users registration
~~~& %% "allow_new_users" => "1",%% Enables new users registration
~~~& %% "allow_new_users" => "2",%% Enables new users registration with confirmation procedure
~~~&I'd also like to have Nils' opinion about this, since he had been working on an improved action for user registration with a confirmation code.
~~~& -- DarTar
Deletions:
* @version 0.1
* - add done/failed icons for each field after form is posted;
* - define strategy to link hardcoded login/logout page;
if (isset($_REQUEST['action']) && ($_REQUEST['action'] == 'register')) {
print $this->Format('--- **Registration successful!** --- You are currently logged in as '.$this->GetUserName());
print $this->Format('--- You are currently logged in as '.$this->GetUserName());
if (isset($_REQUEST['action']) && ($_REQUEST['action'] == 'register')) {
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.';
elseif (preg_match("/ /", $password)) $error = 'Sorry, spaces are not allowed in passwords.';
elseif (!isset($confpassword)) $error = 'You need to confirm your password.';
elseif ($confpassword != $password) $error = 'Sorry, passwords do not match.';
else {
$this->Redirect($this->href());
$form = $this->FormOpen();
$form .= '<input type="hidden" name="action" value="register" />';
$form .= ' <table>';
$form .= ' <td align="right">Your username:</td>';
$form .= ' <td><input name="name" size="40" value="';
$form .= (isset($name))? $name : '';
$form .= '" title="Choose a valid username (formatted as a WikiName)" /></td>';
$form .= ' <td align="right">Your email address:</td>';
$form .= ' <td><input name="email" size="40" value="';
$form .= (isset($email))? $email : '';
$form .= '" title="Fill in a valid email address"/></td>';
$form .= ' <td align="right">Your password:</td>';
$form .= ' <td><input type="password" name="password" size="40" title="Choose a valid password (min. 5 chars, no space)" /></td>';
$form .= ' <td align="right">Confirm password:</td>';
$form .= ' <td><input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></td>';
$form .= ' <td align="right"></td>';
$form .= ' <td><input type="submit" value="Register" size="40" title="Click to register" /></td>';
Try to use SemanticMarkup if this is going to be rewritten anyway, instead of:
%%(php)
use:
%%(php)
It is more elegant, semantically clean and frees some bytes to run free in forests! --IanAndolina
While I agree that ##label## should always be used for form control prompts, I **don't** agree with dropping the table. A form as a series of label-data constructs (i.e., name-value pairs) is semantically also a **data** table, especially since a form can be used not only to //enter// data but also to //(re)view// and //modify// it.
But when a table is a **data** table, it should be marked up as a **data** table, with proper header cells related to the data cells, a caption, and a summary.
The hidden "register" field is also superfluous, since the submit button can take care of that.
We'd end up with something like this (this serves just as an example, not meant as the "final" code):
%%(php;90)
Note that I've also removed the if clauses for $name and $email - the fields should simply be initialized and can then directly be used in the form (moving towards a templating mindset :)).
Preferably the ##align="right"## on the header cells (and maybe other styling) should be taken care of by some special "form table" rules in the stylesheet (contextual rules will be all that's necessary, no need for extra classes or id - and this will enhance a consistent layout of forms). Both right-aligning labels and a consistent layout for all forms will be helpful for usability.
--JavaWoman
~& Thanks for your feedback, guys! I'll patch the action with your suggestions asap. I was thinking that maybe we might want to add more options related to user registration in ##wikka.config.php##.
~& E.g.:
~& %% "allow_new_users" => "0",%% Disables new users registration
~& %% "allow_new_users" => "1",%% Enables new users registration
~& %% "allow_new_users" => "2",%% Enables new users registration with confirmation procedure
~&I'd also like to have Nils' opinion about this, since he had been working on an improved action for user registration with a confirmation code.
~& -- DarTar


Revision [6311]

Edited on 2005-02-25 11:58:29 by DarTar [Reply to JW and Ian]
Additions:
{{lastedit}}
~& -- DarTar
Deletions:
-- DarTar


Revision [6309]

Edited on 2005-02-25 11:36:24 by DarTar [Reply to JW and Ian]
Additions:
~& Thanks for your feedback, guys! I'll patch the action with your suggestions asap. I was thinking that maybe we might want to add more options related to user registration in ##wikka.config.php##.
~& E.g.:
~& %% "allow_new_users" => "0",%% Disables new users registration
~& %% "allow_new_users" => "1",%% Enables new users registration
~& %% "allow_new_users" => "2",%% Enables new users registration with confirmation procedure
~&I'd also like to have Nils' opinion about this, since he had been working on an improved action for user registration with a confirmation code.
-- DarTar


Revision [6305]

Edited on 2005-02-25 08:26:40 by JavaWoman [don't dump tables: use them properly!]
Additions:
Note that I've also removed the if clauses for $name and $email - the fields should simply be initialized and can then directly be used in the form (moving towards a templating mindset :)).
Preferably the ##align="right"## on the header cells (and maybe other styling) should be taken care of by some special "form table" rules in the stylesheet (contextual rules will be all that's necessary, no need for extra classes or id - and this will enhance a consistent layout of forms). Both right-aligning labels and a consistent layout for all forms will be helpful for usability.
Deletions:
Note that I've also removed the if clases for $name and $email - the fields should simply be initialized and can then directly be used in the form (moving towards a templating mindset :)).
Preferably the ##align="right"## on the header cells (and maybe other styling) should be taken care of by some special "form table" rules in the stylesheet (contextual rules will be all that's necessary, no need for extra classes or id - and this will enhance a consistent lay out of forms). Both right-aligning labels and a consistent layout for all forms will be helpful for usability.


Revision [6304]

Edited on 2005-02-25 08:23:52 by JavaWoman [don't dump tables: use them properly!]
Additions:
While I agree that ##label## should always be used for form control prompts, I **don't** agree with dropping the table. A form as a series of label-data constructs (i.e., name-value pairs) is semantically also a **data** table, especially since a form can be used not only to //enter// data but also to //(re)view// and //modify// it.
But when a table is a **data** table, it should be marked up as a **data** table, with proper header cells related to the data cells, a caption, and a summary.
The hidden "register" field is also superfluous, since the submit button can take care of that.
We'd end up with something like this (this serves just as an example, not meant as the "final" code):
%%(php;90)
$form = $this->FormOpen();
$form .= ' <table summary="form to provide registration data: username, email and password">';
$form .= ' <caption>Registration form</caption>';
$form .= ' <tbody>';
$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. 5 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></td>';
$form .= ' <td><input type="submit" value="Register" size="40" title="Register" /></td>';
$form .= ' </tbody>';
Note that I've also removed the if clases for $name and $email - the fields should simply be initialized and can then directly be used in the form (moving towards a templating mindset :)).
Preferably the ##align="right"## on the header cells (and maybe other styling) should be taken care of by some special "form table" rules in the stylesheet (contextual rules will be all that's necessary, no need for extra classes or id - and this will enhance a consistent lay out of forms). Both right-aligning labels and a consistent layout for all forms will be helpful for usability.
--JavaWoman


Revision [6298]

Edited on 2005-02-24 23:14:37 by IanAndolina [fix suggestion to dump tables]
Additions:
%%(php)
%%(php)


Revision [6297]

Edited on 2005-02-24 23:13:27 by IanAndolina [suggestion to dump the table markup]
Additions:
Try to use SemanticMarkup if this is going to be rewritten anyway, instead of:
$form .= '<tr>';
$form .= ' <td align="right">Confirm password:</td>';
$form .= ' <td><input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></td>';
$form .= '</tr>';
use:
$form .= '<label>Confirm password:<input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></label>';%%
It is more elegant, semantically clean and frees some bytes to run free in forests! --IanAndolina


Revision [6294]

Edited on 2005-02-24 21:13:09 by DarTar [First draft of User Registration action]
Additions:
=====Register Action=====

>>==See also:==
Documentation: ""RegisterActionInfo"".>>This is the development page for the Register action.::c::

I've started working on a new version of an action for user registration. The motivation behind this is to replace the current ##usersetting## action with three distinct actions:

~-##register## action - handling operations related to user registration and first login;
~-##login## action - handling operations related to login/logout and password retrieval of registered users;
~-##usersettings## action - handling user preferences (See UserSettingsPanel for more info).


=== The code ===

Save the following as ##./actions/register.php## and use it as ##""{{register}}""##.

%%(php;1)
<?php
/**
* Display a form for user registration.
*
* This action allows new users to register an account, if user registration is enabled.
* All the required fields are validated before the new user is created.
*
* @package Actions
* @name Register
*
* @author {@link http://wikka.jsnx.com/DarTar Dario Taraborelli}
* @version 0.1
* @since Wikka 1.1.X.X
*
* @todo
* - (optionally) drop WikiName restriction on usernames;
* - use core functions to validate fields;
* - add done/failed icons for each field after form is posted;
* - use central error handler for printing error messages;
* - define strategy to link hardcoded login/logout page;
* - define welcome page where new users must be redirected;
*/

print $this->Format('===== Registration page =====');

if ($this->GetConfigValue("allow_new_users") == "0") {
// user registration is disabled
print $this->Format('//User registration is disabled on this wiki//');
} else {
if ($user = $this->GetUser()){
// user is logged in

// is this the first time the user is logged in?
if (isset($_REQUEST['action']) && ($_REQUEST['action'] == 'register')) {
print $this->Format('--- **Registration successful!** --- You are currently logged in as '.$this->GetUserName());
} else {

print $this->Format('--- You are currently logged in as '.$this->GetUserName());
}
} else {
// user is not logged in
print "<script type=\"text/javascript\"><!-- \nfunction hov(loc,cls){ \n if(loc.className) loc.className=cls;\n}\n //-->\n</script>\n";

// is user trying to register?
if (isset($_REQUEST['action']) && ($_REQUEST['action'] == 'register')) {

// get POST values
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'];

// validate fields
// note: all these validation checks should use core functions to preserve consistency

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.';
elseif (preg_match("/ /", $password)) $error = 'Sorry, spaces are not allowed in passwords.';
elseif (!isset($confpassword)) $error = 'You need to confirm your password.';
elseif ($confpassword != $password) $error = 'Sorry, passwords do not match.';
else {
// all required fields are valid and non-empty

// create user
$this->Query("insert into ".$this->config["table_prefix"]."users set ".
"signuptime = now(), ".
"name = '".mysql_real_escape_string($name)."', ".
"email = '".mysql_real_escape_string($email)."', ".
"password = md5('".mysql_real_escape_string($_POST["password"])."')");

// log in
$this->SetUser($this->LoadUser($name));

// forward
$this->Redirect($this->href());
}
}

$intro = $this->Format(' --- If you are a **new user** you can register an account using this form (if you already have an account, please go to the [[UserSettings login page]]). --- --- To register, the following fields are required:
~-your **username** (it must be formatted like a ##""WikiName""##, for example: ##""JuliusCaesar""##);
~-a **valid email address** (this will only be used to retrieve your password in case you lose it);
~-a **valid password** (min. 5 characters, no space allowed).
--- ---');

// build registration form
$form = $this->FormOpen();
$form .= '<input type="hidden" name="action" value="register" />';
$form .= ' <table>';

if (isset($error)) {
$form .= '<tr><td></td><td><span class="error">'.$this->Format($error).'</span></td></tr>';
}
$form .= ' <tr>';
$form .= ' <td align="right">Your username:</td>';
$form .= ' <td><input name="name" size="40" value="';
$form .= (isset($name))? $name : '';
$form .= '" title="Choose a valid username (formatted as a WikiName)" /></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <td align="right">Your email address:</td>';
$form .= ' <td><input name="email" size="40" value="';
$form .= (isset($email))? $email : '';
$form .= '" title="Fill in a valid email address"/></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <td align="right">Your password:</td>';
$form .= ' <td><input type="password" name="password" size="40" title="Choose a valid password (min. 5 chars, no space)" /></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <td align="right">Confirm password:</td>';
$form .= ' <td><input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <td align="right"></td>';
$form .= ' <td><input type="submit" value="Register" size="40" title="Click to register" /></td>';
$form .= ' </tr>';
$form .= ' </table>';
$form .= $this->FormClose();

// output intro and form
print $intro.$form;
}
}
?>

%%


----
Deletions:
=====xxxxx Action=====

>>==See also:==
Documentation: xxxxxActionInfo.>>This is the development page for the xxxxx action.::c::
//This page is a **template**. It belongs to CategoryTemplate (which contains more handy templates). To create an action development page, [[http://wikka.jsnx.com/ActionTemplate/clone clone this page]] to a page called **xxxxxAction** (where xxxxx is the (capitalized) name of the action), replace all occurrences of 'xxxxx' with the name of the action and replace this paragraph with the actual content.//

----


Revision [6293]

The oldest known version of this page was created on 2005-02-24 21:05:39 by DarTar [First draft of User Registration action]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki