[UPHPU] PHP Store

[C. Ed Felt]

Webot Graphics wrote:

> I have a project that someone wants me to do. I am wondering if it 
> can/should be done in php (not knowing php at all i am unsure, but 
> willing to learn because php sounds cool).
>
> The concept (because of contracts I had to change the type of store 
> that is being used) -
> Like a drive-through mini mart (like 7-11), where can drive up to get 
> there order. Now because of the quantity of selection (over 500 
> products) this won't be able to be done with a regular McDonald's 
> menu. The customer, because of this, and a techy feeling, wants to use 
> kiosks, in the drive through (more like a Sonic drive through), and 
> also inside the store. He also wants people to be able to place their 
> orders online, so it will be ready for them.
>
> The execution -
> I figure that we are going to need a client-side website, a client- 
> side kiosk website (unless they can be the same, i just think that the 
> buttons on the kiosk are going to have to be bigger), and a store- 
> side website that pulls up the orders. Now because this is a drive- 
> through the orders have to be sent to the store-side server fairly 
> quickly.
>
> The question -
> Should this be attempted completely in php or a combination of php 
> (the front end) and a computer language like cocoa (the store end)?
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
>
Webot Graphics:

This sounds like a great idea. This is a great project for PHP. Choosing 
a framework might make it much easier to manage later (Qcodo or Zend for 
instance), though I am a "from scratch" guy myself. It's also important 
to separate the GUI (look and feel) from the logic (PHP code). Any good 
framework should do this well. Prepare all the interfaces in HTML first 
to make sure you prototype it to your client's liking, then deal with 
the logic stuff. But the real issue here is your database. For speed, 
ease of use and supportability I would go with MySQL (which is most 
commonly used with PHP). There may even be some pre-made, PHP, open 
source packages you can just tweak for your needs (try sourceforge.net). 
As long all interfaces (store admin front, store fulfillment front, in 
store kiosk and web front) use the same database you should be able to 
do everything in real time. You will want to make sure you have 
redundancy back ups etc. as well. It's also important to define what 
permissions different web front ends have on the database. For instance, 
you would want to have a db user for the store kiosk web site with 
permissions only to create orders, but no permissions to admin settings. 
The usual bottle neck, if you are dealing with lots of transactions, is 
the database.

In short, (I know, I wasn't short), just stick to PHP, it will make your 
life easier. Building the admin and order processing sections of your 
site in PHP is safe as long as you secure the database access properly 
and separate the sites.

Just my $0.02.

-Ed Felt