0

I am trying to create a calendar that allows me to add notes and allow people to view it and comment on the event for each day. I understand how to make the calendar out of php (i have already created it) but how do i get it so that i can add events to the calendar and also integrate a commenting system? I may use something like disqus for the commenting but the more code i write, the better.

So anyways. How do i incorporate a way that would allow me to add events to a calendar and allow people to comment on it (my users)? Can someone guide me through this problem? ideas/snippets/examples can help... I know this possible (i see it all the time, for example Schoolloop, except they don't have a commenting system on their own)

Thank you.

In the mean time, i will be searching for/creating an answer.

4
Contributors
7
Replies
44
Views
4 Years
Discussion Span
Last Post by <M/>
1

Sounds like you need a couple of tables to store that information, and some management to put the events and comments in. The question is broad because it really depends on how the calendar was written. For everyday shown, the calendar needs to query for events, and if there are any, also get the comments. Difficult to get more specific without seeing code.

Votes + Comments
Thanks
0

oh okay, that makes sense. I am going to need to MySQL if that is the case.
I will make some attempts in tweaking up the code. Unfortunately i can't show you my php code for the calendar at the moment, when I come back from the gym, i will post it so you can review it.

Thank you for being the first to help.

This is sent from my phone.

1

The task you describe can be relatively simple to quite complex. It all depends on how you want your data stored (or shared e.g. - do you need this to update a Google Calendar via XML or iCal file?).

The data should be totally independent to the view. Don't make the mistake of coupling data format or structure to a particular view, e.g. Agenda, By Day, By Week, By Month etc.

The main culprit IMO for added complexity is the 'repeatable event', where an event is repeated every week, every other week, every 3 days, every Friday and Sunday etc, between specified dates or ad infinitum. If you just have one-off events, then this will make things considerably easier as your discussions can just be linked to the event_id.

Disqus is a brilliant add-on, but you could equally roll your own simple system - and this may be prefereable if you need to display your coding ability or if you want to develop your skills.

I would strongly suggest utilising OOP (classes and methods) for this as a procedural approach would, to my mind, lead to a considerable amount of code duplication.

Your DB tables could be (just off the top of my head):

  • Events [FK to Event_Types]
  • Users [FK to User_Types]
  • Comments [FKs to Events, Users]
  • Event_Types
  • User_Types

//EDIT

DOH!
Jusr re-read the OP, you're just doing a blog-type post? So just a message that everybody can comment upon? Ignore most of what I said, it doesn't have to be this complicated.

  • Events
  • Comments [FK to Events]
  • Users [if you want to limit who can comment]

Edited by diafol

0

Wow... okay, thanks for pointing all that out diafol. Well, basically to make things sound easier for me, I am going to make a blog but displayed in a calendar format. Sounds easy so far, until I start building it...

Thanks you two

2

Sorry <M/>, I got the wrong end of the stick. Creating a blog app, is very straightforward. The DB schema should be simple, as you've already created. The matter for you is the commenting system I think.

AFAIK, your DB table would be something like this:

  • comment_id [PK]
  • blogpost_id [FK to blog post]
  • user_id [FK to user_id if used]
  • email [for users not logged in or not registered]
  • displayname [for users not logged in or not registered]
  • comment_dt [either datetime or timestamp]
  • body [text]
  • status [tinyint, e.g. 0 = awaiting moderation, 1 = accepted, -1 = declined]

You don't need to include an order for the comments as they can be ordered by datetime/timestamp.
The user_id can be used for registered users, if you need that sort of thing, e.g. trusted users with automatic accepted posts
Else the email is useful so that you can capture a gravatar if one exists asnd if you want to replicate a disqus avatar look.

ANyway, something to think about.

Votes + Comments
okay i will look into it
1

yes even i agree with diafol.

As for status,i think so you can divide it into two table,store status_id(FK to status table) as you suggested and status table must look like this.As it must be obvious for from database to know the status.:-

status

status_id int not null
status_name varchar 20 not null

So basically there should be 5 tables(marked Bold for primary key and italics for FK):-

Blogpost[blogpost_id,blogpost_name]
Events[event_id,blogpost_id ,event_date,event_added_by,last_modified_on]
Comments [comment_id ,event_id(FK to Events),user_id,comment_date,comment,status_id]
Users [user_id,displayname ,email_id]
Status[status_id,status_name]

0

oh okay, i will do my best in expirementing with those ideas :)

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.