LAN party web UI - basic structure
Hello everyone, and welcome to a new episode of critical-web. Today our subject will be basic applications structure, particularly for our LAN party web UI (I know I promised we'd talk about our database, but I think this merits attention first). Before we get started, every worthwhile project needs a code name during development. Let me think here... Bambi? No, too cute... Freddy? Too evil... I got it! Project Arcturus! A good pat on the back for the first one who gets the reference.
Even though, originally, Project Arcturus is planned to be a rather simple application, I want to keep my doors open for flexibility and modifications. Who knows? This could become the next big OS! Humor aside, we can't predict every possible add-on or extension we could append to our project, so let's stay flexible in our application building.
The best way to do this is OOP. With OOP, every part of our application is an abstract object. In this situation, we would have a distinct object for:
- Users;
- Games;
- Calendar and events.
These objects are nice and great, but if we really want to push the OOP envelope, here are a couple of things we could abstract:
- Login and access validation;
- Form validation;
- Much more to come!
I'll detail these objects over the next couple of days. In the mean time, here are a couple of examples why these objects will make our life easier during development:
User creation / modification
Generally, when you want to create a new user, here is what you would want to do:
<CFquery name="myQuery" datasource="myDSN">
insert into users (myColumnList) values (myValues)
</CFquery>
With OOP, here is what you could have:
Now, you could be saying: Wait a minute, there's no difference here! You still have to have a cfquery to insert those values! To this, I would answer: You are entirely correct. However, I would ask you to consider this possibility: What if I want to update my user? In procedural, here is what I would do:
<CFquery name="myQuery" datasource="myDSN">
update users set newValues where user=currentUser
</CFquery>
The same thing, but in OOP:
The advantage here is that, within our application, all we do is call the update method of our users object, regardless if we are creating or modifying our user. The logic between inserting or updating resides entirely within our object.
The same applies to our other objects. In our next entry, we'll explore these distinct objects in detail.
There's more than meets the eye... with you...
There are no comments for this entry.
[Add Comment]