As I promised in part 3 of this series, this piece will be about user registration and login with all that it brings with it in the form of validation and so on.

The requirements for this part are:
1.) We have to put as much power into the hands of designers, project managers and others to enable them to do as much work by themselves as possible. Having them come to us for small inconsequential changes all the time is going to drive us insane. The main workhorse here will be Smarty.
2.) The registration has to be validated through user interaction, in effect clicking a link which we will send to her email address.
3.) Since the users will be paying through their phones we also need to validate their phone numbers. We will do this by sending them a four digit code with the help of our SMS gateway.
4.) Extra features like sending forgotten passwords and resending validation codes are also needed.

Unfortunately I’ve run in to the dreaded 404 wordpress mega bug. Therefore I will publish the code separately and refer to sections in it instead. It sucks but is better than nothing.

cms_part4_code.zip

Let’s begin by taking a look at the function responsible for rendering the registration in UserController, it’s section 1 in the source code. GetCityOptions() and getPhoneOptions() will return arrays with cities and prefix numbers respectively. We have to draw the line for maximum membership age somewhere and a hundred years should be enough. 🙂

Section 2 is the user_register_form template. I’ve left less interesting parts of it out for brevity. The holes have been marked with three vertical dots. The insert function calls at the top is a way of making requirement #1 happen. I fervently hope that a lot of non technical people will be able to manage the control of validation without a lot of explaining on my part. I got some inspiration from how it works in Flex here. However, in Flex the validators are set as attributes of each input field which is a hell of a lot cleaner. I suppose some kind of Smarty plugin could have been created to accomplish the same thing but I’m on a schedule here so that won’t happen. Besides, having all of them in one place is a good thing in itself.

insert_val() is section 3.

Common::checkMethod is section 4.

UserController->insertVal(): Section 5.

The way we work here is highly chaotic. New requirements can come any time and that is why I’ve intentionally made the fields array two dimensional even though at the moment the assignment might just as well have looked like this: $this->session->fields[$params[‘field’]] = $validation. So there is a lot of unused “space” here that we could use for other things if we wanted.

Let’s check validationToArr() in section 6.

Here we basically sort more complicated stuff like “int, atleast-5”. You might also notice that we do not have a terms and conditions page yet. At the moment we just link to the frontpage.

So let’s pretend we have filled the form with some data and hit submit. Apparently that will call a method called save() in UserController in section 7.

That section is filled with a lot of method calls, lets start with validatePost() and validateField() in section 8.

Note that I call validatePost() with “insert” as the last parameter. This parameter has currently no function. Yet again I’m trying to think ahead of various erratic decision makers. At the moment the only validation in the login form is to check if a user with the entered information actually exists, I have no other specs. However, at some point in the future someone might decide that we have to validate this input too before we query the database. If that happens I could pass “login” or something instead and have the validation script validate in a different way based on that parameter, if need be.

Another noteworthy thing is that we call $smarty->get_template_vars() to load various validation errors from a language file. As you might have noticed already, this project is multilingual. It makes sense to separate copy from view in any case as it enables total cave men – that don’t even understand what HTML is – to be productive in the project.

Upon successful validation we generate a 4 digit code and call sendPhoneCode(), we also generate a unique id and call sendMail() in section 9.

Note the use of config loading with the help of Zend_Config_Ini().

I’m not going to show the login template, there is only one interesting thing there which will be explained soon, let’s jump to the login functions instead in section 10.

We make use of a row object in valEmail() which enables us to keep hassle to a minimum since all the database connection information is stored in the object itself. We simply change member variables and call save() to update, awesome.

In passwordSend() for instance we assign this: $this->smarty->assign(’email_error’, ‘yes’). In the template this information is used like this:

{insert name=”getText” yesno=$email_error text=#email_resend_error#}

And the insert function can be found in section 11.

The whole point of this is to avoid something like this inside the template itself:
{if $email_error eq ‘yes’}
{#email_resend_error#}
{/if}

Designers are notoriously allergic to code, it is my belief that the insert way is easier to handle by their own instead of having them do conditionals.

And that my friends wraps it up, the code solves all our requirements and the extra Smarty candy we have created will hopefully be helpful to a whole slew of people that cringe at the sight of the slightest bit of the underpinnings.

Related Posts

• Smarty + Doctrine = Smoc
• ZF Community/CMS Bugfixes
• Writing a CMS/Community with Smarty and the Zend Framework: Part 10
• Writing a CMS/Community with Smarty and the Zend Framework: Part 9
• Writing a CMS/Community with Smarty and the Zend Framework: Part 8