I am learning web development. And for that, I am trying to create a web-app to 1. The admin can upload classes per types with dates and time-slots, 2. users can book the classes (this is like the most-basic, or where I can go now).
My code creates a new entry in my MYSQL database. My idea is to add a new column with a quota, so when users book that class the code rests one slot from the quota.
But, what happens? That the admin of the site (this is actually like a booking engine for gym classes), they have to create a class every day per day.
So, I imagine that the best way to achieve this was to 1. the admin can select how many classes to create (for example, a loop that goes between two dates). 2. when the admin fills the form in PHP it creates a new job for CRON.
For instance, the admin decides to create a class selecting MONDAY and THURSDAY at 18.00. The CRON job will insert a new value into the SQL table every MONDAY and THURSDAY, so it will be available for the users to book.
But now, I don't have any idea of how to set this up. I am looking online but I can't find a good tutorial for me...
Thanks beforehands!
Related
I have a simple php user profile system that works like this: When user is registered he gets a specific url ?user. Therefore, other visitors can access his page.
What I want it to include chat application on users profile pages. But, every single user should have its own chat.
Which approach is the best, as I am a beginner in this? Should I put the messages from chat into the database or should I work with some log.txt files?
Any good tutorial for this would be helpful.
I found some tutorial for you: http://tutorialzine.com/2010/10/ajax-web-chat-php-mysql/
- looks like it could help you.
The only thing you need to adjust is to add room column in WEBCHAT_LINES table - that will be the unique name of the user, into which's chat room the chat line belongs. Then, when new chat line will be sent, you must save it to DB with apropriate room identificator. When you display the messages in chat, you must filter the results in each room to show only the lines for this particular room.
If you haven't use database before, there are plenty tutorials about mysql around the internet - it's not that difficult.
Good luck! And use Google when you'll have some doubts.
I'm trying to integrate a rating and like system as part of a package to send to the end user (with unknown progamming skill).
My problem is how to manage the users (registered or not) that have already done an action.At this moment I'm using PHP session to keep stored for a week the information, but this isn't a good solution.Is it a good solution creating 2 tables (one for rating and one for like) to store the information? If I use this solution what's the most useful and "correct" information to retrieve if the user is not registered? And is it user-friendly?I have thought to store: username and the ip
I would extend the members's table with at least two new columns, likes and rating or create a new table (as you said) including the memberID with a reference(and an index) to store and select the data. I believe it's the best way. Unfortunately, in this case non-members cannot press like or rate, but it is a good reason for one to register. –
I have written a really simply forum to integrate into a web app as I was struggling to find a lightweight and quick forum which allowed me to use my own authentication methods to decide who was or wasn't a valid users and which fitted into my application theme. Users are asking for the ability to subscribe to threads so they are notified of replies - what is the best way of doing this?
I could create a threads subscriptions table and enter a new row each time someone subscribes - this could involve lots of lookups for busy threads on every post and reply but would be pretty quick on new subscriptions with only one simple insert.
The other option I thought of was to have row per thread and to have a field where I can add (or read from) an array per thread which contains all the subscribed user id's. This strikes me as quicker for reading as there are less database calls (i.e. when a new reply has been made only one database call is needed to get all the user id's) but I think it might be slower for inserts when a new subscriber is added as I would have to find the row for the thread, get the existing array and then add the user id to the existing array.
A final option, very similar to the second one, would be to have a user subscription table where each row is a user id and then have an array of subscribed threads.
Which would be the best way? At the moment my only requirement is to email users on new posts and replies but in the future I may want to expand it to include the ability for users to list their subscribed threads etc like many mainstream forums do.
In my opinion, your two options are good, except for the array thing. You can simply go for a table which contains a unique id for a thread and if a user hit a subscribe button it can be added with his id and the thread id. You can call it, subscription table.
I think array might come handy if a user started subscribing much more threads. It depends on how big your forum is going to be.
I'm creating a mobile game on various mobile platforms and have decided to use PHP/MySQL as the back end and communicate with this via JSON. (The game will be text based).
I'm lacking on idea's on how to implement this, the sort of logic i'm after is as follows;
User will need to register an account
User will enter the game lobby looking for an open slot
If there is a suitable game ready and waiting (not full and waiting for new players) then join
If not create a new game and await players
I was thinking of having 20 players for each game and only allowing the game to start when there's 3 or more players waiting. When there's 3 or more players waiting there would be a count down of say 60 seconds until the game began.
Now i know some of this might need to be done on the client side. I'm struggling on where to start!! So any idea's, code samples or links to reading material that may help would be very much appreciated.
thanks!
Based on comments, I'm guessing you're looking for some ideas on database schema, like Brad Christie suggests. So I'm going to start with that.
First, you'll need a table for the players. I'm guessing you already have one of those, but you'll probably want to include a field for the game ID that they're in.
Next, you'll need a table for the games. This is where you store information on the game itself, including whether it's active. To get the player count, you simply query the list of players with that game's ID. You could also keep track of player count and update it whenever the player leaves or joins the game, depending on a few factors.
Now, the game lobby itself. The exact method here really depends on how you want it to function. You can either use AJAX to keep a list of currently active games up to date (and set up some sort of chat system to let players talk while waiting), or you can use the game lobby as routing page. If you go the latter route, then query the active games, automatically dump the player into one that meets your criteria, then send the user to the 'main game page'.
Hopefully this will give you a solid outline on how to start. I'm afraid I can't help you much more unless I know more about your requirements.
For register a user you simply need a form and save that form in your database. When the user logs in the you query the database matching the password and user name.
I was looking for input about integrating a feature that:
*When a new article is added, search for users having a watchlist taht match the article categorie.
*Send them an email with the new article.
I am kind of worried it will slow the application to browse the whole watchlist table everytime a new article popup.
What would be the best way to integrate that?
Is doing a cron job that check every hours new article and compare them to watchlists a good idea? One email per day?
Thanks!
If I were doing this, I would only worry if (numberOfwatchlists) * (newArticlesPerMinute) is a very large number.
As for not spaming emails, I think a once a day check would be good.