problemmer med MySQLi class; intet respons ved SELECT

Hmm...
Jeg har altså opgivet at forstå din kode; jeg har sågar downloadet dit objekt for at finde hoved og hale i det du har skrevet og jeg mener du blander alt for mange ting sammen.

For det første:
echo '<pre>';throw new Exception ('No user set ('.$user.')');echo '</pre>';

En total misforståelse af hvad exceptions skal bruges til.
Exceptions er supersmarte hvis man bruger dem rigtigt; det nytter ikke noget at bruge dem. I ovenstående tilfælde vil du aldrig få echo '</pre>'; med ud da der efter din exception er blevet kastet og ikke fanget vil en Fatal error opstå.

For det andet:
Dit mysqli objekt er ikke længere et abstraktionslag, når du det er afhængigt af andre objekter på den måde som du laver dem her.
Det ville være mere relevant at servere dine queryes som en del af et objekt istedet for at generere et for hver gang du sender en query.

For det tredie:
Dit objekt er også afhængig af funktioner fra et andet script (curPageURL()). Dit abstraktionslag kan nu ikke længere genbruges.

For det fjerde:
Du lader ikke til at du har forstået idéen med at benytte public, private og protected, men jeg kan tage fejl? Dine erklæringer af klassens metoder giver ihvertfald ikke meget mening for mig.

Det ville hjælpe ekstremt meget hvis man fik at vide hvad formålet reelt set er med dit objekt? Om det overhovedet skal være et abtraktionslag eller om det blot er en del af noget større?

Tak for respons.
1.
Ja er også først lige begyndt, at forstå brugen af. throw new Exception, så det var faktisk begyndt at gå op for mig.

2.
Hmm, det lyder som om du siger noget klogt, vil du være venlig at uddybe det lidt.

3.
curPageURL() er en af de standart funktioner der bliver indlæst, så det gør ikke så meget. Men ja jeg burde nok sætte den ind i min class (MySQLc). Det vil også gøre klassen funktionsdygtig i forbindelse med AJAX.

4.
hmm nej det har jeg sikket ikke. Men hvis jeg skal quizze.
Public: en variabel i en class der er tilgængelig uden for, og inde fra en class. fx $class->publicvar, og $this->publicvar

Private: en variabel i en class der kun er tilgængelig inde fra en class, fx $this->privatevar.

Protected:
Ja så langt er jeg ikke kommet, men jeg ved at den er vigtig.

x.
jeg kender endnu ikke helt  betydnigen af abtraktionslag, men ideen var at class'erne tilsammen kunne udgøre en alternativ brug af mysqli.
http://pastebin.com/m2e89f1fb syntes jeg nu beskriver det meget godt. Havde jeg ikke min class skulle jeg fx konvertere fra ISO... til UTF-8 og omvendt i dette eksempel. Desuden kan jeg også have en fejl-log, hvilket for mig er ekstrem brugbart.
Desuden er classen også et modul af et MVC system jeg forsøger at lave.

Men det bliver nok ikke særligt let for dig at give god respons af noget som ikke er færdigt. Men jeg har da tænkt mig at bede om FeedBack når jeg er færdig. Så ville der også være eksempler der viser brugen af det.

PS: jeg fandt fejlen jeg manglede bare en
$this->store_result();

Men lig et svar så kan vi dele point, jeg kan tænke mig til du har brugt lang tid på det.

2.
Du har ikke konsistens i behandlingen af dine forespørgsler når du deler dine objekter ud som du har gjort.
Dit c_query objekt indeholder funktionaliteter som lige så godt kunne være i dit hovedobjekt. Men det vender jeg lige tilbage til.

3.
Ikke alene vil den gøre din AJAX mere selvstændig (hvis du har behov for at sætte det i sådan et perspektiv), det vil også lette portering og med kompabilitet. Forestil dig et et objekt du bruger til MySQL kommunikation som kan arbejde selvstændigt - du vil hurtigt kunne opdatere dine eksisterende applikationer og ved at bruge et selvstændigt objekt i stedet for de to du har nu, kan du hurtigt lave to objekter, som fungerer fuldstændig ens - den ene er bare til mysql, den anden måske til postgresql - mun funktionaliteterne er de samme.

4.
Private kan kun tilgås af sig selv.
Det vil sige $this->method();

Protected kan tilgås af sig selv OG nedarvede objekter.
F.eks. $this->method(); eller parent::method();

Public er tilgængeligt i alle scopes.
Selv det instancierede. $obj->method(); $this->method(); parent::method(); obj::method();

x.
Et abstraktionslag giver dig mulighed for at have simple behandlingslag som er nemme at vedligeholde.
et eksempel:
<?php
    $db = new cMysql();
    $sql = "SELECT * FROM table";
    $db->query($sql);
    $resultat = $db->result2array();
?>

Nu er $resultat et array med et multidimensionelt array med mine resultater.

Forestil dig så at din nye løsning skal over på en postgresql løsning; Hvordan vil du løse det uden at have to objekter du skal tilpasse?
Her er min udgave:

<?php
    $db = new cPostgresql();
    $sql = "SELECT * FROM table";
    $db->query($sql);
    $resultat = $db->result2array();
?>

og $resultat indeholder det samme som før.

På den måde har du opnået et fleksibelt abstraktionslag.

I et MVC miljø vil du kunne opnå noget som er endnu smartere, men ideen vil du forstå.

Du kan se mit abstraktionslag her:
http://pastebin.com/m13723a2e

Du skal også pille din log funktion, din encoding funktioner ud af dine objekter for at få noget brugbart i et MVC miljø.
Hele idéen med MVC var at adskille de enkelte elementer og så bruge dem fornuftigt sammen.

Behold selv dine point. Det var ganske interessant at se hvad du havde fået lavet.

Husk på; min måde at gøre tingene på er ikke nødvendigvis den korrekte måde - det er en holdning og stil jeg har.

Mange tak for dit svar/kommentar, det gav et godt indblik i hvor dan OOP kan benyttes.
Faktisk har jeg set dit abstraktionslag før, og det var også en del af min inspiration. Men den gør kun brug af query delen af MySQLi classen, hvilket i mine øjne kun er et hjørne af MySQLi. prepare delen er langt mere interessant syntes jeg.

Ideen med at have 2 class'er var at jeg kunne have flere query/prepare per MySQL forbindelse. Jeg har så prøvet at gå på kompromi ved at sætte variablerne i MySQLc til public.
Det gør selvfølgelig at c_query ikke er selvstændig, men sådan er det syntes jeg.

Men endnu en gang mange tak for din respons.

PS: jeg har kun programmeret PHP i et halvt år, så …