+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forumdisplay.php?fid=23)
+--- Thread: Multiple Registration Form Organization (/showthread.php?tid=11421)
Pages:
1
2
Multiple Registration Form Organization - El Forum - 09-08-2008
[eluser]Jesse Schutt[/eluser]
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
Multiple Registration Form Organization - El Forum - 09-08-2008
[eluser]Jesse Schutt[/eluser]
Even some basic information would be helpful!
Multiple Registration Form Organization - El Forum - 09-08-2008
[eluser]Sumon[/eluser]
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.
Multiple Registration Form Organization - El Forum - 09-08-2008
[eluser]Sumon[/eluser]
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.
Multiple Registration Form Organization - El Forum - 09-08-2008
[eluser]Mirage[/eluser]
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
Multiple Registration Form Organization - El Forum - 09-08-2008
[eluser]Jesse Schutt[/eluser]
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.
Quote: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!
Quote: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
Multiple Registration Form Organization - El Forum - 09-08-2008
[eluser]Sumon[/eluser]
Here it is
Code:
-- Table structure for table `basic_registration`
CREATE TABLE `basic_registration` (
`user_id` int(11) NOT NULL auto_increment,
`name` varchar(50) collate latin1_general_ci NOT NULL,
`email` varchar(50) collate latin1_general_ci NOT NULL,
`password` varchar(50) collate latin1_general_ci NOT NULL,
PRIMARY KEY (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;
-- Table structure for table `event_registration`
CREATE TABLE `event_registration` (
`event_id` int(11) NOT NULL auto_increment,
`user_id` int(11) NOT NULL,
`event_title` varchar(255) collate latin1_general_ci NOT NULL,
`event_date` date NOT NULL,
`event_detail` text collate latin1_general_ci NOT NULL,
PRIMARY KEY (`event_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;
-- Table structure for table `payment_information`
CREATE TABLE `payment_information` (
`pay_id` int(11) NOT NULL auto_increment,
`user_id` int(11) NOT NULL,
`cc_card_no` int(11) NOT NULL,
`pincode` int(11) NOT NULL,
PRIMARY KEY (`pay_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;Multiple Registration Form Organization - El Forum - 09-10-2008
[eluser]Jesse Schutt[/eluser]
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
Multiple Registration Form Organization - El Forum - 09-10-2008
[eluser]Jesse Schutt[/eluser]
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?
Multiple Registration Form Organization - El Forum - 09-10-2008
[eluser]Sumon[/eluser]
[quote author="jschutt" date="1221074394"]
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?
[/quote]
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..
[quote author="jschutt" date="1221074394"]
I also need to break out of one flat table for all the details.
[/quote]
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.