Hello All,

I have the need to build an event registration application and I wanted to ask some questions before I get too far into the process.

Currently I have one form built that integrates with PayPal, posts to a DB, emails the admin, and updates the DB upon IPN confirmation.

The plan is to expand this to be the event registration for up to 30 events for the same organization at different points throughout the year.  The information and payment that needs to be collected is somewhat uniform but there are some differences to each event.

I would also like to add a backend to this to manage the registrations with sorting, reports, manual addition of registrants.

Can someone give me some direction on the following questions?

1. How should I go about building this at the beginning to facilitate the addition of additional registration forms?

2. Advice on the DB table structure?  Should I put users in a table and connect them to different tables containing the event-specific information?

3. Where do go with the admin backend…

Thanks in advance!

Jesse

Even some basic information would be helpful!

You can create three different tables.

basic_registration: table which contain username(or email can treate as username) and password for further login.

payment_information: table contain payment related information like CC info or so. as though they are same for multiple events. an option to update user payment information when they are logged in.

event_registration: finally event related informations like event_date, place etc etc

from basic_registration user_id will be use in other tables. 1-1 relationship with payment_information and 1-many for event_registration.

Through backend you can easily sorting users, view reports, add registrants, edit registrants information or even block an unexpected user/registrant.

You can create three different tables.

basic_registration: table which contain username(or email can treate as username) and password for further login.

payment_information: table contain payment related information like CC info or so. as though they are same for multiple events. an option to update user payment information when they are logged in.

event_registration: finally event related informations like event_date, place etc etc

from basic_registration user_id will be use in other tables. 1-1 relationship with payment_information and 1-many for event_registration.

Through backend you can easily sorting users, view reports, add registrants, edit registrants information or even block an unexpected user/registrant.

—not sure how much helpful my reply is.

Without knowing the application potential scale in detail, I’d approach it this way:

Each registration form / form set runs against the same controller / registration method.

The view (form template) uses a hidden parameter[s] to describe a registration type / event type.

A single table stores all registrations.

One or two columns help identify the type of registration in the admin.

Common registration data such as name, email, etc gets it’s own column.

Arbitrary registration data is stored in json format or other serialized format in a single text column.

Alternatively - if arbitrary data needs to be [conveniently] searchable / sortable - create relational tables with the registration/event specific columns and link it back to registrations table by id.

Where to go with the admin backend?
A loaded question. I’ll just say that I develop all admin panels in ExtJs these days. Flexible, pluggable and consistent UI.

Cheers -
m

Thanks to both of you for your responses!

I really like seeing how others create their applications.  It is always enlightening to see how many different ways there are to accomplish the same thing.

Arbitrary registration data is stored in json format or other serialized format in a single text column.

This is a new concept for me.  My newb is showing!

Alternatively - if arbitrary data needs to be [conveniently] searchable / sortable - create relational tables with the registration/event specific columns and link it back to registrations table by id.

Though it is probably a pretty simple question, can you give me some specifics on how to connect these by id?  Is that just the auto_increment setting on a mysql field?

I really appreciate you taking the time to give me some direction!

Jesse

Here it is

Sumon,

Thanks for the ideas!  One of the things that I know I don’t want to be doing is storing any cc information.  PayPal is the method of choice right now for payment.  I know, I know, some aren’t happy with it, but it is what we are going to use for the time being.

I have a question about the overall application flow…  Well, let me tell you what the current flow is and see if it should be modified.

1. Form is built and upon validation, submitted
2. Details are posted into one flat table and emailed to admin
3. User is transferred to PayPal
4. Upon confirmation of IPN, record is updated in DB to “Paid”
5. User is redirected to a confirmation page on our site with payment details.

My biggest question is in step 2 and between steps 2 and 3.  Should I email the admin before the payment has been completed?  Or should I wait until the confirmation of payment is received and then email the admin?  I also need to break out of one flat table for all the details.

Thanks in advance!

Jesse

Mirage - Can you give me some more specifics on extJS?  I went over to their site and was quite impressed with what I saw.  Does it integrate easily with CI, or do you abandon CI for the admin panel?

jschutt - 10 September 2008 03:19 PM

1. Form is built and upon validation, submitted
2. Details are posted into one flat table and emailed to admin
3. User is transferred to PayPal
4. Upon confirmation of IPN, record is updated in DB to “Paid”
5. User is redirected to a confirmation page on our site with payment details.

My biggest question is in step 2 and between steps 2 and 3.  Should I email the admin before the payment has been completed?  Or should I wait until the confirmation of payment is received and then email the admin?

Jesse,
From my point of view, “Yes” you should not email admin before payment is done. Because many visitor’s add product into their basket for nothing. So admin must not happy to receive email for these.
One additional option “Visitor Tracking” what you can add. i.e how much visitors visit your site. Which product visited most etc etc..

jschutt - 10 September 2008 03:19 PM

I also need to break out of one flat table for all the details.

May be this idea is useful. Event table only contain event_id, user_id, date_of_registration, payment_cleared(Yes/No),  etc etc
and event_detail table contain all informations regarding an event like event_id, guest_info, contact_email or something like it according to your requirement.

Sumon,

Thanks for the ideas!  I will look at breaking out into several tables.

Just to clarify, this isn’t for a cart or storefront.  It is a registration application for events.  I’m not sure if that was clear before.

You suggested that I use fields like user_id and event_id.  How do I go about generating those values?  I know how to use the auto_increment on the primary key, but is that what you would suggest?

Jesse

ha ha ha. Your read my post instantly. that’s why you get shopping cart. Within few minutes i have changed it to event. please have a look now.
http://ellislab.com/forums/viewreply/457732/

jschutt - 10 September 2008 10:30 PM

You suggested that I use fields like user_id and event_id.  How do I go about generating those values?  I know how to use the auto_increment on the primary key, but is that what you would suggest?

Exactly. user_id from registration table and event_id from event. both are auto increment and primary key.