Setting up the ladder table

So... Ladder... What do we need as info. This is a part of information I have been strugling with for quite a few days

now. Since basically it comes to this:

The results of matches defines the way the ladder changes. The ladder itself is pretty much "stupid" as information

wise. Since the only thing we really need is:

- Game
- Position
- Team
- Team Streak (how many wins in a row)
- Team Wins
- Team Losses
- Status (defending, attacking, protection,vulnerable)

This could be just be defined inside a single table with the fields as described. However, here comes the tricky part.

- Position is defined by the wins/losses and who got challenged from the matches
- Teamstreak is defined by the wins of the latest matches of the team
- Team wins gets defined by the wins of the matches
- Team losses gets defined by the losses of the matches
- Status gets defined by the last pending match AND the previous match

So at some point it is fair to say that the ladder gets updated on different points:
- When a match gets accepted (status change)
- When a match gets declined by both teams (status change)
- When a match is finished (Team Streak/ Wins / Losses updates / Position)

This above section needs to be done through one function (it needs to be centralized), since in that way I am able to rebuild the complete ladder when needed

Shitting up the ladder

Ehm... setting up the ladder I mean. Basically, the ladder is what makes the system tick at some point. Its an overal table that shows the progress over whats happening during the complete season.

Overal, it comes down to positions inside the ladder. Since this drives the ladder. And as far as I discussed it previously it comes down to that a team inside the ladder has a few states:

- position (rank)
- invulnerable
- protected

Position is the place where the team is at inside the complete ladder. This position will eventually determine which teams he can challenge. In basic terms it comes down to that you can only challenge the teams above you, not below you.

When a challenge has occured, this leads to a match (which is defined by the match system which is implemented).

After the match has taken place there are a few states which are the results:

Option 1. Team 1 wins - Team 2 loses
Option 2.Team 1 loses - Team 2 Wins
Option 3. Both teams rejected the match

The last part is database wise implemented (Since there is a handshake inplace where both teams can decide to reject the match or reschedule). Still... there needs to be a place where this can be entered. But we'll get to that one later.

However, the point where I want to focus on first is the whole ladder (since rescheduling a match has nothing to do with the ladder eventually, since its just a matter of checking a box, and setting up a new match).

So this leads me with option 1 and option 2.
With option 1, Team 1 will get the status of protected, team 2 will get the status of invulnerable
With option 2, Team 1 will get the status of invulnerable, team 2 will get the status of protected

With option 2 however, something different will occur. Team 2 takes the place in the ladder of Team 1, and Team 1 moves one spot down in the ladder.

The states of invulnerable and protected isn't that hard to implement, since it is a matter of setting a flag next to the teams and say if they are invulnerable or protected... nothing special about that part.

Its the positioning that troubles me at this point. A basic ladder could be defined by a simple table where it just says:

Ladder
Team, Position, Status

Thats it basically... However, what if... something goes terribly wrong with the Database system? Is there a way we are able to 're-calculate' what the ladder would look like. I mean, a database is a file... and things are being saved into the file. And a file can... when things go really wrong get corrupt at some point.

Sure, this can happen at some other points aswell, but thats damage which can be restored at some point. But with the ladder as I just described as above, there is no backup on how the ladder is being calculated and so on.

There is however one backup plan that sticks in the back of my mind: The Matches!
The matches contain all the info on who won etc. So using that as a backend for the complete ladder to be rebuild (when needed) I could eventually rebuild the complete ladder from the ground up.

Even better yet, I could even say: Show me what the ladder looked like on 20 december 2010. Ok, show me what the ladder looked like on 11 Januari 2011.

So eventually, using the matches as a reference point, I could use this as a "tracking" mechanism to show a ladder from that given point.

I eventually want to take it THAT far. However, this requires some tinkering and thought process on how to calculate the whole ladder. Since this is the part which requires a lot of testing and simulations to mimic this effect.

I will give it some thought, and work out the details somewhere tomorrow. Since I think (at the current state I am at right now) this is the ideal method to make it work... its a safety net more or less... Just in case things go really wrong.

The technical datasheet

(Click on it to zoom in... Its a pretty big picture ;))

Here's the technical datasheet on where we are at right now. The white parts are the parts that are existing (and might be fine tuned in a later stage), the red parts are the parts that needs to be developed.

Date acception

Seems like that the date accepted is fixed by now. The next thing I want to try to sort out now is the edit match. Since there are still a few issues wrong with that page. Let me try to explain this part.

The game selection is an ajax call. And when selecting a game, it sends out a request to fetch the information for that game. While creating a match this seems to be working properly since I am more or less "manually" triggering that ajax call to take place (since it happends when i select a game)

However, when requesting the same page back (after pressing save for instance) this manual process is not there at that time. So, my assumption at this point is that the ajax call does not take place, thus it can not fill in all the bits and pieces like Mode, Map etc since the game is just not there yet.

So thats the next thing I need to fix here and there just to make the edit process a bit more 'logical' and understandable what is really happening at that point.

Edit1:
Well, my first assumption seems to be correct. After the form submit take place the ajaxcall is not being triggered. The cool thing though is that the whole result of the ajaxpage is just a part of a form. So... if I can just include that part of the form when I am editing it, I should be halfway there.

Edit2:
So yeah, that should sort it. I am including the same form as the ajax call but now as a PHP Include file. This leads me with a new issue (which I just sorted). Since an ajaxcall is nothing but a new php page request. So it does not have any database connection etc.

While this is all being included from one configuration file, and this config file has one perticular function that only exists in this config file for setting up the database connection, i am simply using 'function_exists' to test if this page is used for an Ajax call, or just being included directly inside the form itself

Now, the thing I do know by now is that a form submit has a post array, while the ajax call does not. With that in mind I am able to tell the difference between if its an form include or an ajax call...

You still follow me? I hope not...

Edit3:
So now i need to grab the values for those parts which are being handled through the ajax part. Which are in this case:

- map1
- map2
- map3

So that should sum up that part i think. Lets implement this one while we are at it.

Edit4 (last one for now I think):
I also changed the same thing with the Dates and Times. Since those never received a default value which was entered by the user. This should be fixed by now

Upcomming matches

Right, next up is listing up the upcomming matches I think. This one shouldn't be that difficult I think, since its just a list of matches that have been accepted and are in the future...

Yes... it is that simple



Ok, view pending matches is there. I am using a little "hover" over effect I have been experimenting with earlier on to display the time till the match. Its a nice gizmo since its not always there. It only shows when you are putting your mouse over the dates etc.

Also it should give some additional information about what "TBA" stands for, why its there etc.

However, this leads me to another issue I just encountered. Apperently the status of the accepting dates is not working properly. At least, I had 3 matches made. Accepted them all (set a date) and for some reason it still gives the status "pending".

So what happened there, I do not know yet. But i'll figure that one out later on.

Developments have been slow the last 2 days

Now that i just wrote down the initial post about logging. I like to add that in the last 2 days developments might look like they have been going rather slow at some point.

There are some minor parts I am trying to fix here and there, which is probably not really new worthy to write down (hence the lack of updates in the last 2 days).

Also I like to add that I am currently on some form of medication which puts myself in a very 'drugged' state. Its known as PCH in the netherlands. This means that I am asleep most of the time, and I when I am awake, I do code a bit here and there but it doesn't go as fast as it has been going in the last few days.

I thought I would just mention this one aswell. I am still working on it, but in a more 'slow' state.

Logging

Just a thought I need to write down here, since I am thinking about it. And I don't want to forget this one eventually. Eventually I want to come to a point where I'll log everything thats happening inside the system. And as far as I can come up with there are currently 2 different logs i need to setup

- player log
- team log

These logs can later on be used for 'nice' tools in a later stage. Since it could show a complete history of a player, or of a team. It could show the recent activity from a user. Which teams he has been and so on.

combine that with some nice statistic graph (I am thinking fusion charts in this case), it could turn into a more visual aspect making it look interesting at some point, even while its not even 'that interesting'. It's just more a toy...

Handshaking part 3

like the handshake parts on the team level is implemented by now. Initially I am going for the Team 1 Challenges Team 2. Which is probably the hardest part of the system. Setting up an Admin for team1 vs team2 is only extending the system with a few parts (which is going to be easy).

Initially I had to remodel the database structure once more, since there were 2 things that I felt the need to remodel again. Which is the status field on Dates and Maps.

Eventually I had a similar approach on how I did the whole Match setup, where each team had their own field inside the match table. Now I have extracted the team from the dates and maps and made it their own field.

So maps looks like:

- Id
- MapId
- MatchId
- TeamId
- Status

Dates look like:
- Id
- MatchId
- TeamId
- Status

The reason why I am choosing this method is because it makes it easier to fetch the whole date and maps list. I don't need to worry who is belongs too now since that is just the TeamId in ever table.

This leads me with having the option of an Admin adding a match (since this one was really going to be a bitch with the previous method I setup). In anycase, the status will determine if a 'record' is accepted, declined, pending, or new.

So from an admin point of view, I only need to add the status "New" in there and I am done. For a team challenging another it means that all the dates/maps etc are accepted for Team 1, however they get the New status for Team 2 (since they still need to accept one).

If one is accepted, then THAT specific one gets a new state, the rest just gets ignored. Simple as that.

So the process as it currently goes with the "challenge Team 1 vs Team 2" goes as followed, I as team 1 select my own team. Since I am able to have more then one team, I still need to select which team I am going to pick.

Next up, I need to challenge someone. This is where Team 2 needs to be selected.

Last bit, I have 3 fields to pick from where I can input "potential" dates (which are NOT final) where I think the match can take place.

Also, I have to pick 1 till 3 maps to play (since the other team needs to accept at least one of them). And lastly we have the server bits. Which is in this case optional, and can be altered in a later stage.

I fill in this form, and we have ourself a pending match. At this point, I might add that the "SAVE" button DOES save all the information, however it does not show it after I pressed save. This is something I still need to fix.

When I log out and log in as the team captain I just challenged, I'll see this notification at the lower left corner:

Offcourse, this needs to be tweaked and all that. But at least it keeps track of the amount of pending matches that I have in my "inbox" more or less. So that part of the system is more or less working. But needs a fine tune somewhere. We'll get back to that one.

Anyways, to popup the pending matches, I have used the Team Control panel to show most of the important stuff about the team. This might lead to some confusion in the long run (since the team control panel shows alot of info).



There is a section called "PENDING MATCHES". There is will display the once that have been accepted, declined, pending or are new. Eventually this part needs to have a fine tune moment aswell, since there is no date involved yet (so the list just becomes bigger). But that will come in time.

But anyways, by clicking on the match details (which is in this case "TITLE", and has the status NEW) I can bring up the match details and see what dates the other teams have suggested for the match to run.



At this point it has a few different sections:

- Team vs Team
- Dates
- Maps
- Match information
- Player lineup

The last part is not visible on this picture, but in simple terms it just shows a list of all the players belonging to both teams.

The team vs team still needs to be finished, since I haven't gotten around to the inputs of the scores yet. As soon as I get there, and have a ladder/tourney, I can start adding losses/wins (hopes that makes sense).

The dates section is the dates that were recommended by the other team who challenged me. In this case I can only choose from 1 of the 3 dates. If someone enters 2 dates, I can only select 1 date from 2.

Same goes with the maps. We have 3 maps to choose from, and we need to select at least one.

The rest (match info, player line up) is just additional info which tells us what type of game,map, who made the challenge bla bla etc.

in this case, I'll select 1 feb 2011, and go with the map "Kaboom" (does that map even exists? I don't know).

After pressing the "Accept the match" I'll get the same screen, but... without the optional dates.



In fact, it tells me now that the match takes place on 1 feb 2011 19:00, i have 1 week 1 day, 12 hours and 35 before this match starts. The match accepted is filled in with my name (because I accepted it under the account "YO YO")

And I just realized a bug in the system because it displays the wrong map name... Nice!

Lets fix this one ;)

Handshaking Part 2

Ok, after having everything sink down a bit, while setting up the whole view match page its time for the whole handshaking bit. As far as I can tell now is that there are 2 levels of handshaking. One which is a must have, and the second is the optional part. I'll try to explain myself why, how and what in the next few segments.

Match handshake
First of all we have the match handshake. This is the point where teams accept the match, choose which map to play and set a date for the match.

Team 1 (the Attacker) determines 3 times (max) and 3 maps (max) to choose from.
Team 2 has to accept one time and one map to play

or

Team 2 can decline the match (which also results into a forfeit, and team 1 thereby automatically wins the match).

The second level of handshaking is on player level, which happends when both teams accepted the match. In this case the players have to submit if they are able to attend to the match. Thus the whole lineup will be known as well.

The latter part is the part I am making optional (but still make it into play). There are couple of reasons behind this.

- the system is brand new, making the match system too complex in the beginning makes people not to use it
- the lineup is in someway already known since a team has players and these players are identified
- it results into additional checksums that have to take place, since new team members which signed up after the match has been accepted, they cannot join etc.

I might add, in the long run a player handshake is important. That is why I am making this part optional. But for the short term it isn't needed to get the match underway.

So with the view match page already there, this will be the next section I will be implementing in the next day. Since it should not be that difficult to make it work.

Match reconstruction

Today i started with the whole match reconstruction. At least, my initial assumption right now is that the whole setup I have done inside the matches itself is eventually going to by myself in the head.

Currently I am having different states for a match for team1 and team2. From a query perspective it works if its limited. However, since the states have alot of impact on what the outcome of a match is going to be it will eventually start into one complicated mess.

In the new setup I have split the match up into 2 different tables. First you have the match, and next you have the team status. This team status is defined by the following parameters:

- Match Id
- Team Id
- Team Side (attack / defend)
- Match Status (accepted/declined the match)
- Match Score Accepted (accepted / declined the scores)
- Match Rescheduled (accepted / declined rescheduling)

From a query point of view it makes it easier for fetching the information. Even while its just another table.

Currently I have fixed the inserts (I am still inserting the old columns inside the matches, however eventually they will be phased out). I only need to fix the view match page where I am gathering the information from the new matchteam table. But... that should not take that long I think.

What else I need to change:
- pending matches on the team control panel
- pending matches notifications on the toolbar (footer)
- function getPendingMatchesCaptain2 is obsolete now

Update: And by now this all got sorted out. So this should hopefully make further developments on the match status a little bit more easy to implement.

Match scores entering

Ok, this is an interesting process. Since it has been bugging me while i was writing down the code for viewing the matches. There is a point when the match completes. And when this happends the match results needs to be entered in right? Ok.. then comes the pop quiz question:

- Who enters the scores?
- How is this process done?
- is there any role from the admin point of view?

To get answers to these questions, I asked around about how other systems work with this process. And personally I think I understand now where to take this all... Let me write it all down in the next few segments while it is still fresh on my mind:

- The match scores get entered by either one of the 2 team captains
- A match score gets accepted withing 2 hours time
- if the other side does not agree with the scores, they file a complaint towards the admins (dispute).
- If they accept the match results they can simply say "accept"

So this whole process leads into a new section i need to add inside the whole match system. Next to accepting matches, I need to have a field called "accept results". And this needs to be saved for both team 1 and team 2.

If team 1 enters the scores the flag for accepted team 1 will automaticly be set to true.

If one of these 2 fields is set to true, and nothing has happened in the next 2 hours, the match will automaticly be flagged for completed. This also needs to be a seperate field

Next interesting point is "rescheduling a match". This can happen when something goes terribly wrong during the match or it just did not really work out for both teams (eg: too little players, no one showed up etc).

To make this workable there needs to be 2 additional fields for the match which is called rejected team1, and rejected team2.

To be honest, I am beginning to wonder if I shouldn't just seperate the whole match thing into 2 tables. One for the match, and one for the entered data (flags) by the teams. Since from a 'retrieval' point of view it gets pretty messy when they are spread over more then one field.

So more like:

Match, data

Match, Side, Team, Accepted, Reschedule, Score etc

Somewhere in that direction. I just need to think this one really through if I am gonna this or not. Since it requires some changes inside the entermatch/ view match scripts.

Ah well.. I need to edit them anyways.

View Match

Right, here goes the view match page. This one is pretty heavy when it comes to data retrieval, since there is so much info I can grab from a match alone.

My initial idea here is to copy most of that which cybergamer does. Which comes down to the line of "Who vs Who". The match details. The game which is played. The server info. etc.

Then there is the player line up. Now, here is the tricky part. The view page displays every single one. However... If there is going to be a handshake on player level, then this means that I need to find a way here that people are saying they are attending to the match.

The tricky part is that there needs to be some checksum if you are on the team, and if you haven't accepted / declined the match and so on. That is just a piece of logic that could be implemented into this page (since the logic / visual) is seperated from eachother.

Second, the same page could be used for accepting the dates/ maps for the team captains. Again, its defined by the logic, and then presented onto the page if this is the case.

I still need to find my ways on how to implement it. But in basic terms, it just comes down to flag it, say yes/no (or 1 and 0) and then show that part of the form if that would be the case.

Its a shameless plug really...

And we'r setup with most of the information we need...

MatchStatus

I'll need 2 fields for the MatchStatus. One for team 1, and the other for team 2.
I just realized this when I was making the list of pending matches.

Ok, I just realized the same thing with the match maps, and the dates. What if... Yeah big if. But what if the match is made outside the challenge us section, but manually inserted by the administration.

In that case both teams need to handshake along with the whole thing.
the same thing is with the tournament. since a tournament is most often defined by a set of rules of engagment (at least I can remember this from a BF1942/BF2 tourneys we did).

The ladder however (outside a tourney) is often being handled by the teams themselves (thus the whole challenge us has an impact). And in that case the team that submits the challenge will most obvious accept the maps they selected (hell.. why else select maps that you would suck with right?!)

Anyways, I just modified the script a bit so the dates / maps are now fixed. Also, I noticed earlier on that team2 was never filled. I made a type there. And another thing I need to fix over here is the dynamic Ajax system I inserted. It needs to update when I pressed save.

At least all the data is stored now. I am gonna work on a view page so I can get the handshake system into play.

Handshaking

Ok.. now for the tricky part numero uno... The handshaking between the teams. First of all i need to send an email to the team primary assets (eg, the important dudes of the other team).

This can be fetched using a single query and grab all the people that have the rank of doing matches and so on.

With that in mind, the same people will get access to the pending matches. Since they are able to confirm if they accept or decline... or simply do nothing with it (which also results into a decline in x hours).

The team control panel will be the place to be at for this. However, I like it to be modular so I'll add this into a seperate block code and place it into the team control panel. So just in case I need this list else where I can plug it in... Just like in the Matrix...

The handshake will be a new screen (duh!). Its like an 'edit' match. but more simplfied. It should show the details of the match like who challenges who, which map, game etc.

The user is able to select the map he wants to do, and select the date he wants to do it. When this is done, then the match is set to go. The next step would be the whole player pool... thats comes after the handshake. Since we need a lineup of players who are able to attend to this match.

All this has to take place in like 48 hours or so. Which reminds me... I need to have a date checksum. Since a match cannot take place in the past. And a match has to be scheduled in like +4 days (since there is 2 days between the handshake, then 2 days for the lineup).

ValidateForm

This should cover most of the validations I need for the match to get underway...
This is a part of Javascript... which all happends on the client side. Should work in IE, FireFox, Safari, Chrome and Opera

function ValidateForm()
{
var lvalid = true;
var sMsg = "";
if(dg('mname').value=='')
{
lvalid=false
sMsg += "The match needs to have a valid name \n";
}
if(dg('mgid').options[dg('mgid').selectedIndex].value==0)
{
lvalid=false
sMsg += "There is no game selected \n";
}
if (dg('map1')!=null)
{
// this is a bit of a tricky part since map1 is not always there!
m1 = dg('map1').options[dg('map1').selectedIndex].value
m2 = dg('map2').options[dg('map2').selectedIndex].value
m3 = dg('map3').options[dg('map3').selectedIndex].value
if(m1==0 && m2 == 0 && m3 == 0)
{
lvalid=false
sMsg = "You need to select at least one map"
}
}
t1 = dg("time").value
t2 = dg("time2").value
t3 = dg("time3").value
d1 = dg("date").value
d2 = dg("date2").value
d3 = dg("date3").value
lDate = false;
if(d1=="" && d2=="" && d3 =="")
{
lvalid = false
sMsg ="You need to enter alteast one Date/Time, otherwise we can't schedule this event"
lDate = true;
}

if(t1=="" && t2=="" && t3 =="" && !lDate)
{
lvalid = false
sMsg ="You need to enter alteast one Date/Time, otherwise we can't schedule this event"
}
if (!lvalid)
{
alert(sMsg);
}
return lvalid

}

Matches is almost there

Aside from a few tweaks i need to do, making a pending match is almost done. There are just a few concirns that I need to address here.

- what if there is no game selected. A game is mandatory.
- what if you have no date / time entered? This needs to be fetched by an error message before the form gets submitted
- there needs to be at least one map selected.
- server could be optional, but needs to be filled in eventually (since otherwise you would not have a place where the match takes place). It's just an informative piece nothing more.

I also started to add a new section on the team control panel, which is the pending matches. Eventually a match has 4 states. New, Pending, Accepted and Declined. There the last does not need to show up in this list.

Also, I need to add a date/time stamp in this section, otherwise it will show all the matches that taken place in the past. But thats a matter of adding a where clause. Nothing special.

The optional maps

For the creation of a match I need something as "optional maps". This means, that either you have one map set (generated by the tournament) or you have a set of maps created by the challenger.

This requires an additional handshake. Since not only are we handshaking the date/time for the match to take place. But also the confirmation on which map to play.

These optional maps needs to be stored into a similar system as the dates. So something like:

- Match
- Map
- Accepted

Should do the trick.

However this leads me with another question. What if we have 3 maps to choose from... do we select one or more maps? The system, as initially intended does allow it to have more then one map since we also have a section called rounds. And each round can have its own map.

But initially I'll go with the select one map approach, but have the system still remained opened up for multiple maps to be selected if it really needed be there. Its all about making things optional and revert changes if it really needed to be done.

I like to plan ahead more or less.

Houston, now I have a problem

k... here goes... This one caught my eye before. And I had this issue now. So I thought like, while I am on the subject noticing the problem. Lets just write it down and explain what happends.

The current way I am making these forms is that they have states. As in, what are we doing with this form? Are we adding a new record? Are we editing an existing record?

This state is inserted on the form itself. Meaning, there is a hidden field that contains an "action" which is Add or Edit. With edit there is not much of a problem there. However, with adding there is.

The thing that I want to do different here is to ADD the record first and Edit it later on. Normally this is not behavior on how websystems work. Because they just tell you "your thing has been created, or send" and then you need to click somewhere to edit it later on. This is probably done to prevent the issue I am addressing here right now.

But seriously, this is just another click... and we already click way too much. I like to prevent this from happening. Thus the system i initially went for is existing. However, now I have the problem that the same exact record gets inserted twice when hitting the F5 key after pressing Save...

For me, this makes sense why this is happening. Since the form states are being send as they were the previous time the Save button was clicked. So this means that the action I am sending back and forth is still the same ("ADD").

I can come up with multiple ways to solve this issue. Since its just a matter of checking "if the data is already there"... But this also means I need to do this on every inserts I have done so far. Which kinda stinks at this point since I have made alot already. But nevertheless, I just need to clean this little issue up somewhere tomorrow.

Adding servers

Ok, servers is now an option to add. Simply put a list of servers, and a nice edit page. Nothing special. I also opened up the system so that eventually teams themselves can add their own servers for skirmished (just in case). So far, it remains a part of the admin panel though...

Now I need to use this somewhere in the match section. Since it needs to allow it to add a server when the server is not there. Or we can use an existing one.

Often I like these kind of setup, since it gets frustrating at times when you want to get something done, and then all of a sudden you start to realize something is missing (in this case the server). So you end up adding a new item, go back at the page and then you realize you have to re-enter everything...

Yeah, thats web applications for you. So, we have a server add mode optional in the match section... Sounds logic eh ;)

Game Times

This is an interesting point that was brought up on which I havent thought of yet. While determining a match there is a negation point on which the teams decide to make the match happen. I will call this the handshake approach more or less.

At some point in time, the match is inserted and the first team gives a few times to play on. Then the second team needs to pick a time to play on.

When this happends the time match is set.

Basically it comes down that there are 3 till 5 different options of different playtimes as an optional gametime. Too many would probably lead to too much choice.

The way this could be implemented is as followed:

match date - default empty
option1 - filled
option2 - filled
option3 - filled

Once this is setup, the match goes in pending mode (since it still needs to be accepted by the other team).

Once the other team decides to take the match, and selects one of the options given to them the match date gets filled with that option which was selected.

From a database point of view it could be as dynamic as I want it to be (if i would do a seperate table insert). But it would also lead into having a total complex system just to insert a time. I am not sure though. I need to think about it.

The only advantadge point if I would go for the whole insert time in a seperate table is that I could have unlimited amount of times for one match (so I am not limiting myself with lets say, 3 or 5 options).

I am not sure about this though... since it can get really complex from an entry point of view (the way that the page needs to build up etc).

Or I could start adding the dynamic layer but have it fixed to start with. Since in this case I can start building it first. Have it with the date time inserts seperate. And later on decide if i'll make the times build up dynamic aswell. I think I will go with that approach.

Here's another interesting idea btw. I came accross this plugin: http://digitalbush.com/projects/masked-input-plugin/

It is a jquery plugin (which ofcourse needs the jquery libary). However, the cool thing with this plugin is that the definitions of it work pretty well. However, with checksums using additional javascripting you need to be extra carefull with it. Since input masking also changes the value of the input field. Yeah, I figured this one out the hard way a few months ago.

But anyways. This program is not gonna be that hard on javascripting validations (mostly serverside).

But anyways, jquery mask is implemented in this project now too... and it works like a charm. Now to add them dates.

For the whole DateTime veriant, i'll go with the following setup
- Match
- Date / Time
- Accepted

Thats it basically. Since the rest can be retrieved from the match itself.