PHP Require Database Histogram Tallying Tutorial
The “PHP Require Database” concept of yesterday, with PHP Require Database Application Tutorial, opens the way for more Google Chart “application” thoughts and ideas for value adding to the iOS mobile application “Make Your Own Charts”.
With that in mind we are adding a “less interactive” version of our Google Chart Histogram Chart that concentrates on what a “Tallyer” (ie. one who keeps tally) might do. We get the Histogram Chart interface web application to a point waiting for the one series of keyboard entries, perhaps entered by memorizing keys and pressing them without looking, concentrating on a vehicle type count perhaps. So the user finalizes their “tally capture” phase by clicking a Javascript prompt window’s OK button, resulting in a Histogram of findings.
To get this functionality to work we needed changes as per …
- php_database.php (not changed) … and then to interface to the “Make Your Own Charts” iOS iPad mobile application …
- histogram_chart.php (changed this way)
- pie_chart.php (changed this way)
- butsel.php (not changed)
- justmenuWebView.html (changed this way)
Previous relevant PHP Require Database Application Tutorial is shown below.
PHP Require Database Application Tutorial
This “PHP Require Database” concept of yesterday, with PHP Require Database Primer Tutorial, does have its uses, or “application”.
Before we reveal what today’s “application” is, you need to see where it sits in the “permanency stakes” …
- beats a local Javascript variable in a local Javascript function
- beats a global Javascript variable for the life of a client webpage
- beats HTTP Cookie client storage
- beats $_SESSION[] PHP interwebpage permanency
- beats $_GET[] and $_POST[] PHP interwebpage permanency
- beats HTML5 LocalStorage
- beats Indexeddb’s ObjectStore
- our “PHP Require Database” concept probably sits here … not as permanent feeling as …
- web server flat files
- web server databases
- remote server databases
… and we don’t see it as robust and flexible as those last few, really in this early stage having awkward delimitation rules, and in all practicality not really designed for lots of data in multiple database type fields.
With that “flagging” feeling talent, as intimated above, today we use that “PHP Require Database” talent to “flag” when we are using an iOS (via Xcode) UIWebView housed webpage, where a call to start the mobile app is used to flag this scenario, and register that event with our “PHP Require Database”. So, today, we use this “flagging” mechanism to “value add” to the menus of the “Make Your Own Chart” mobile application, today, as a start adding a “Pie Chart Fractions Game” to try to help teach fractions via that tried and trusted “pie cut up” approach.
There were small changes to, mainly PHP, required by yesterday’s “child” …
- php_database.php (changed this way) … and then to interface to the “Make Your Own Charts” iOS iPad mobile application …
- pie_chart.php (changed this way)
- butsel.php (changed this way)
- justmenuWebView.html (changed this way)
Previous relevant PHP Require Database Primer Tutorial is shown below.
PHP Require Database Primer Tutorial
Am wondering whether you were here when we introduced the concept of a PHP source file, on its own, acting like a web server residing database, by its mechanism of being able to update itself, yet, on an Apache/PHP/MySql web server arrangement, not easily be revealing that data to the general public, but to the user (equals computer/web browser type combination) it will allow access, as exemplified by the tutorials within the tutorial blog posting thread involving Signature Signature PHP Tutorial?
Well, today we extend that thought just a little bit, by trying to create a “child” PHP source file scenario, that is called from a supervisor via …
require('php_database.php');
… and then work off either …
- $_GET[] arguments and/or …
- $_POST[] arguments
… to store and recall “database” data stored within the bowels of the “child” PHP that has the capability of storing and updating this “database” data.
In the industry you tend to hear about “database drivers” or “database engine”. Well, today, we have those being just plain straight PHP code. This interests me, but then, you know, those butterflies in Brazil changing the weather look interesting too … we hope you share this Latin Thang Going On … huh?!
First thing with this project we researched was whether PHP’s require can take arguments. We came out thinking, not except in some really kludgy fashion … and we’re not into fashion … so if we were cornered … alley fashion … moi … no.
Before we go any further, you may have asked “why do this?”. It strikes us that is quite a legitimate question, to which we’d answer, that we like ideas that …
- have a supervisory/child relationship … and in so doing, for us …
- have us modularize PHP code in a way to make “the parts of the whole” logically smaller (and/or logically belonging in “compartments of code”) … “logically” being the operative word … “why do it?” would be our ask of “illogical” (or arbitrary) approaches here
So try today’s supervisor web application (you could call using_php_database.php) (and you could try setting your own database stored recall value via this (to new window)) supervising our “child” (called via PHP require) php_database.php for our “PHP Source Code Database” concept today.
As per usual, we give thanks to those geniuses on the WWW … today it’s … this useful link … so … thanks.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
