Subversion repository up and running!
Dreamhost really does have a lot of extremely useful features. Aside from rails support and the one click install/upgrades for wordpress and phpbb, they have one thing you rarely find — Subversion support! You can create as many repo’s as you want. By default when you create a repository you can specify public or private. Public means that only users you create and commit to it, but anyone can read. Private requires authentication to view, and everyone that can view can commit. So for the little project I’m working on I decided to create a public repository. Right now i’m using Eclipse/CFEclipse/Adobe Flex Builder/Subclipse for the development, and I’m considering buying a Flex 2 license. Perhaps later on I’ll be able to get a little help, or maybe some tips, but I’m far from the code review point. If you’re interested in seeing the most incomplete Model Glue Unity site out there, check out the svn repo at http://svn.adamfortuna.com/public/.
Right now I’m working on the security layer, which is pretty standard at this point. It extends Reactors validation and expands on it for my site specific validation, which turned out to be a breeze. For instance, when a user is created, a lot of basic validation on the username is required. Was a username entered (assuming it’s not null)? Is it under 50 characters, or whatever the database columns maxlength is? It is full of acceptable characters for this field? All of these are handled by Reactor just by making it a varchar(50) not null in the database, but there’s a few more things I want to validate in the username. Reading over the Reactor Mailing List, the solution that seemed the cleanest was to override the validateusername method in the MemberValidator and in it call the super() function. Here’s what it looks like now. Email address is also validated in this file to be sure it’s unique in about the same way:
[cfm]
[/cfm]
There is one thing I’m sure there’s a better way of doing, but I haven’t been able to wrap my head around the best way just yet. When a user registers they enter their password as well as their password confirmation. The way I have it make sure that these passwords match is such a hack. Basically, to the Model Glue GenericCommit event I added…
<message name="ModelGlue.genericCommit"> <argument name="recordName" value="MemberRecord" /> <argument name="criteria" value="memberID" /> <argument name="object" value="Member" /> <argument name="properties" value="password,passwordConfirmation,username,email" /> <argument name="validationName" value="MemberValidation" /> </message>
The passwordConfirmation part indicates that there will be a variable passed in called that, and in the Member object there will be a method called setPasswordConfirmation. Since this object is created by Reactor, I added a few things to the MemberRecord.cfc to handle this. You can probably see the problem — my setPasswordConfirmation also sets a flag to say that the password confirmation has been set. Probably could explicitly set this bit, but still i don’t like the idea of keeping a “changed” bit active. The reason it’s there at all is because in the validation methods you’ll really only have passwordConfirmation set if the user is changing their password or signing up, and it won’t be set by default when the Member record is grabbed from the DB. I’m sure there’s a better way of handling this, just need to research it a bit.