[raido357]

Eespool olevad postitused on küll vanad aga miks mitte kasutada MySQL Improved varianti ja prepared statemente ?

[keevitaja]

kuidas need käivad

[keevitaja]

ja mis asjad täpselt need exceptionid on? manualis nagu natukene oli kirjas, kuid ei saa hästi pihta

[andrusny]

Veateated.

[keevitaja]

exceptionitest veel. keegi oskab seletada throw, catch jne... manualis erit nagu kirjas pole.

kas üldiselt oleks parem neid kasutada, selle lihtsa die() asemel?

[mikk36]

http://php.net/manual/en/language.exceptions.php
Example 1 näitab kenasti ära mõtte.

[keevitaja]

[mikk36]

Kui ühtegi exceptionit ei vista (viga), siis catch osa ei rakendu, kui visatakse exception, siis saad seda catch lõigu sees töödelda, antud juhul väljastatakse exceptioni sõnum (getMessage()).
Otsetõlkes on need kaks väljendit siis proovi ja püüa, kui ta ei suuda edukalt proovi lõiku teha, siis püütakse error kinni ja php scripti käivitumist ei peatata, saad kenasti kasutajale errori saata.

[inzinz]

Umm, hetkel tundub see asi siin jalgratta leiutamisena ja mugavuse aknast väljaviskamisena et mingit huvitavat asja proovida.
Mis on näiteks häda sellel, et panna verifytext tagastama true ja false ja seda hiljem kontrollida ?

function verifyText() {
return !empty($this->text);
}

function printText() {
if(!$this->VerifyText()) echo 'tekst puudub';
else echo $this->text;
}

Antud moodus on ju palju mugavam ja loogilisem kirjutada kui nii:
function verifyText() {
if empty($this->text) throw new Exception('tekst puudub');
}

function printText() {
try{
$this->VerifyText();
echo $this->text;
}catch{
echo 'tekst puudub';
}
}

Exceptionitega koodi on palju raskem lugeda ja hiljem hallata. Exceptionitel on oma aeg ja koht, aga mingi taoline lihtlabane kontroll ei ole nüüd küll selline koht... (näiteks redirecti tegemine redirectexception klassiga ja selle püüdmisega on täitsa ok kasutus, aga iga pisikest kontrolli niimoodi "paremaks" teha üritades on suht pointless...)

[keevitaja]

ma tegelt kirjutan siin ühe gd classi, kus siis tahan kontrollida, et $this->image mis on loodud imagecreatefrom abil on olemas!
kuna see peab 100% olema, siis die('pilt puudub!') oleks ok ja mingit muud keemiat vaja pole?

[inzinz]

No, minu meelest nii hardcore lähenemist ei ole ikka, et kuskil klassi sees teed die('käi kurele'); kui ühte pilti pole, kuna sellisel juhul sa pead seda klassi hakkama muuta kui tahad teist teksti kuvada jne. Ja kui tahad erinevat teksti kuvada eri kohtadest kasutades, siis on jälle jama majas.

Mõistlikum ja hiljem paremini kasutatav lahendus on see, et sa ise peale pildi laadimist ja enne klassi edasist kasutamist kontrollid läbi funktsiooni IsImageLoaded() {return !empty($this->image);} staatust vms. Niimoodi on põhiklass asjalik ja minimaalne, ja seda kasutav kood ise juba kontrollib ja majandab errorite või hoiatuste kuvamisega, või äärmisel juhul lihtsalt ignoreerib errorit ja proovib uuesti tegevust teha jne jne. Sa ei saa kõiki võimalikke erijuhte baasklassi toppida vaid ikkagi nende koht on seal koodis, mis seda baasklassi kasutab.
Kui on vajadus kasutajale html lehte ilusama error teatega näidata, siis klassi seest tulev die muudab selle võimatuks, aga kõrgemal koodis pildi laadimist kontrollides, on parem kontroll olukorra üle.

[raido357]

[keevitaja]

no ma kasutan sqlit nii:

[lehm2]

Aga milleks, leiutada ratast ?

[Celos]

[inzinz]

[keevitaja]

mul nüüd lsb (alates PHP 5.3) küsimus:

[keevitaja]

leidsin lahenduse! äkki kellelegi abiks:

[keevitaja]

SELECT:

[mark11]

[keevitaja]

krt, see tundub kuidagi liiga keeruline. siis võiks ise ju neid querysid kontrollida.

põmst ma tahaks ainult, et need queryd oleks prepared (eelvormindatud???). fetchida võiks ka muud muudi äkki?

[keevitaja]

klge olete te kindel selle mysqli prepared statementide headuses? ma siin üritasin nüüd asjast sotti saada ja jõudsin sellisele tulemusele:

[nene]

[keevitaja]

jumal tänatud. ma siin kartsin, et panin siin oma katsetamisega mööda täiega kuna väideti, et ma oma eelpool mainutud klassiga leiutan jalgratast...
see mysqli on pealegi veel bugine kah. näiteks long integeri peab sisestama stringina...

[iceincube]

Ma kasutaks ka muid asju.
Kuna kasutan ise Zend'i päris palju siis soovitan seda.


Samuti kavas doctrine'i proovida.

[keevitaja]

no zend framework lihtsalt andmebaasiga suhtlemiseks vist oleks liiast... kui sa nüüd seda mõtlesid

[iceincube]

eks ta mõnes mõttes õige ole..
Ma toon sulle näite, kui tahad proovida...

[keevitaja]

ma kunagi midagi postitasin kah siia, aga hetkel olen kirjutanud selle klassi andmebaasiga suhtlemiseks:

[morgoth]

IMO DB klassil võiks ka mingi error handling olla. Hea kuskile logisse salvestada, kui midagi nihu läheb, või transaktsioonile rollbacki teha.

Zend_Db_Table abil annab suht hästi table data gateway patterni kasutada: Extendid oma klassi sellest ning pärast on väga mugav andmeid muuta/lisada:

[keevitaja]

mul endal selline süsteem tehtud. aga alates PHP 5.3 late static bindinguga... kus siis esimine klass sisaldab funktsioone, ja teine siis extendib teda kus ma kirjeldan ära siis tabeli nime ja vajadusel siis custom funktsioonid. saab samuti teha näiteks:

$page = Pages::find_by_id(4);
$page->name = 'uus nimi';
$page->save();

uus kanne oleks siis
$page = new Pages;
$page->save();

[keevitaja]

kas keegi viitsiks mulle seletada, mis point on abstract classidel. ma siin vaatasin manuali, kuid ei saa pihta, miks neid vaja on...

[Ho Ho]

Kui üldised OO põhimõtted selged ei tohiks aru saamine väga keerukas olla, kui ei ole selged siis pole vist eriti mõtet isegi üritada selgitada.


Sisuliselt abstraktne klass on selline klass, mida otseselt kusagil ei kasutata, see on ette nähtud ainult extendimiseks teiste klasside poolt. A'la midagi sellises stiilis (pseudokood c++ baasil):

[Fukiku]

[keevitaja]

ka php-s on olemas interfaced...

[telefoon]

Abstract class'i kasutamiseks peab tegema sellele alamklassi. Üks alamklass aga ei saa extendida mitut ülemklassi.
Interface'ga on aga nii, et üks klass võib implementeerida mitmeid interface'e. Selles mõttes on interface palju dünaamilisem.

[blinx]

Ei ole tõesti kiiruse vahet abstraktklasside meetoditel ja tavalistel.

[Ho Ho]

[keevitaja]

kas oleks võimalik saada klassi nimi ilma namespaceta kätte?

[keevitaja]

[Fukiku]

[keevitaja]

põmst kogu see jutt. ehk siis mingeid erroried see klass ju vajadusel kuvab. kas oleks pigem passlikum need errorid kuhugi muutujasse panna? mida tähendab transaktsioonile rollback...

[raido357]

[Le Inc]

Küsimus. Kas objekti meetoditest saab kuidagi "väljundit" kätte ilma return'ita. Ehk on meetod (funktisioon) mis teeb midagi tarka, kuid vahel võib ka viga tulla mis try ja catch kinni püütakse. Kui ma "echo" kirjutan siis see pritsitakse html, AGA tahaks kuskile muutujasse susata ja koodis "õiges kohas" uuesti välja lasta. Ainuke hetkel töötav variant on return susata ja sealt a la echo $klass->TereTore(); (// samal ajal käivitatakse funktsioon) kätte saada.

Kas saaks kuidagi teistmoodi ka?

[jnt]

& märk pane funktsiooni/meetodi argumendi ette. Siis muutes seda sees pool funktsiooni/meetodit muutub ka väljas pool see sama muutuja sisu. Lisaks olemas $_GLOBALS ja lihtsalt muutujate globaalseks tegemine.

[Le Inc]

[jnt]

Le Inc, muidugi saad klassis olevaid property'eid funktsiooni sees kasutada. Vaata ainult, et siis korraliku koodi mõistes klassis nood property'd ära ka defineerid.

Errorite jaoks võiks üldse üks staatiline error klass olla või veel enam, tee enda error handler ja siis lihtsalt trigger'dad erroreid ja su enda klass püüab nad kinni ja teeb, mida vaja.

[Le Inc]

Põmst trein üht klassi mis SOAP kaudu majandaks mobiil-id. Hetkel on plaanis piirduda ainult autentimisega, signeerimine jääb kunagi tulevikku, kui mul endal tekib selle järgi otsene vajadus.

Veakoodid mis tekivad SOAP päringust kutsuvad php Fatal Error'i välja (milleks!?). Ilma try ja catch jääks kood kinni. Hetkel olen veamajanduse array ära lahendanud (catch püüab SoapFault veastringi kinni), kus vastavale veakoodile on masiivis ka "tõlge".

Vististi on SK ka sarnasest koodist huvitatud (nende näide on PEAR põhine). Võimalik kui koodi valmis saan panen siisa üles, saate suuremad OOP kunnid üle kaeda (see mul esimene OOP moodi progemine). hetkel väga ei julge avalikult turule minna.

[Erti-Chris]