Hi Nitin,
> its all about contest online where we maintain point
> of the all user and if user take partispate in the contest
> then he not again eligible for that time when new contest are
> not update.
So you have a site with a quiz and want to make sure a user doesn't do the
same quiz twice.
Fairly: this is impossible to avoid. You can only make things a bit more
difficult for someone who wants to participate more often.
Of course first thing is have all participants register their (valid) email
address, then you can at least limit access so that a person can only use a
specific email address only once to make a certain quiz (and then still they
will be able to participate several times, depending on how many email
addresses they have).
If you don't register email address there are alternatives, but...
- controlling access using IP address, the first alternative, is not very
useful. Dialup and ADSL users would only need to logout, wait, login, (get
another IP address) to have access again, and multiple users behind one
gateway would find access blocked if another user behind that gateway had
already participated in the quiz.
- controlling access using cookies might be done. After participating, you
store the number of the quiz the user just did in the cookie and on every
access to a quiz you check if the user already has the number of that quiz
stored in the cookie on his machine. But cookies on the users machine can be
deleted by the user (and they will, if there is prize money involved), or
they simply access again from another machine.
So best way is to ask users to register an email address, and send a
confirmation code there, to be used to get access. Then make a table
'accesses' with fields
ac_id, ac_email (or better: ac_us_id), ac_quiznumber, ac_accesstime and when
a user makes a quiz you store his email, the quiznumber just made and the
time of access there. Next time, you check if that email address already
registered for that quiz and if not, he/she will get access.
But as said, that does not protect you against people using dozens of email
addresses. And again: they will, especially if participation is for free and
there is price money involved...
> 2) Some are multiple choice; others may be plain answers. I
> need to be able to have contestants see their score as soon
> as they finish.
This is tricky. I used to work as a developer for Wageningen University in
the Netherlands and we spent quite some time thinking about online
examination. Fact is: in the end we decided there is no way to do this in a
watertight way without inviting all students to be seen when making the exam
online (just to prevent the students to ask the brightest one of them to
make the test for all of them, by physically logging in as other students,
or by just standing behind the other student and telling them the right
answer to type..., or by using SMS, or whatever)
Anyway, with multiple choice it is easy to check the answers and give the
score right away. But with plain text answers, especially when the answer is
a sentence and not a word, this becomes almost impossible, there will be
need for an intelligent full text parser.
And even with single word answers it can be tricky, your message is the
proof of this: even simple words as 'urgent' ('argent'), 'participate'
('partisipat'), 'up to date' ('update') can be misspelled and would
disqualify the answer even if basically the answer would have been correct.
> 3) Separate registration with full address (and an agreement
> to receive newsletters) and E-mail address is a must.
I would not participate. Or I would use a 'use once and forget' hotmail
address. Newsletters are too often confused with spam. Keep the users in a
table 'users' with primary key us_id (might have guessed that ac_us_id above
would refer to this).
> 4) Upload of mp3's for music identification quizzes
Only through the CMS I suppose, is not that difficult to realise. Having
users (participants) upload files is trickier and requires checking if the
uploaded file really is an mp3 and not a virus, trojan, whatever.
Again, use a database and store only the filename. But make sure to leave
the file in the filesystem, and not as a BLOB.
> 5) Possibility of setting up logins with files for every user
> so that points can be tallied up for monthly or yearly prize.
You don't need files for that, use the database. In the table I gave above
you could add a field ac_score and then finding scores of users in a
specific period of time becomes a piece of cake
("select *, sum(ac_score) as total from accesses where ac_us_id=foo and
(ac_accesstime > x) and (ac_accesstime < y)")
> 6) Exciting and dynamic interface - but fast loading.'
Use flash. But only for elements on the site and not for the whole layout as
Flash is indexed badly by search engines like Google, so a site in Flash
tends to make the site invisible. (Even pointing this out, there are
customers who insist in a 100% Flash site though as it looks so good
compared to a static page...)
> So not much needed then.
> Maybe just 1 or 2 lines of php.
:-))
Marc
Community email addresses:
Post message: [email protected]
Subscribe: [EMAIL PROTECTED]
Unsubscribe: [EMAIL PROTECTED]
List owner: [EMAIL PROTECTED]
Shortcut URL to this page:
http://groups.yahoo.com/group/php-list
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/php-list/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
