---

En lille opfølgning på
<http://groups.google.com/groups?hl=da&threadm=9shboi%2495%241%40sunsite.dk&rnum=1&prev=/groups%3Fq%3Dpostgresql%2Bgroup:dk.edb.internet.webdesign.serverside.php%2Bauthor:Jonas%2Bauthor:Koch%2Bauthor:Bentzen%26hl%3Dda%26rnum%3D1%26selm%3D9shboi%252495%25241%2540sunsite.dk>

Med PHP 4.1.0 er det nu blevet meget nemmere at bruge PHPs indbyggede
PostgreSQL-funktioner.



Før PHP 4.1.0:

<?php
$conn = pg_connect("user=brugernavn dbname=database");

$query = pg_exec($conn, "SELECT id FROM users");
for ($i = 0; $res = @pg_fetch_array($query, $i); $i++) {
echo $res["id"];
}
?>



Efter PHP 4.1.0:

<?php
pg_connect("user=brugernavn dbname=database");

$query = pg_exec("SELECT id FROM users");
while ($res = pg_fetch_array($query)) {
echo $res["id"];
}
?>



Det er jo næsten som at bruge MySQL! : )
For lige at opsummere de (ret væsentlige) ændringer, jeg har fået øje
på i min korte testperiode:

1. Det er ikke strengt nødvendigt at angive et forbindelses-ID i
pg_exec (sådan har det muligvis også været før, men det er ikke
dokumenteret i manualen). Det betyder så igen, at man ikke behøver at
have en forbindelses-ID-variabel ($conn i øverste eksempel), med mindre
man på samme side bruger flere forskellige forbindelser til databasen.

2. Det er ikke længere nødvendigt at angive en tæller ($i i øverste
eksempel), når man bruger pg_fetch_array og pg_fetch_row. En stor
forbedring, for det sparer en for en masse ekstra kode.

3. pg_fetch_* beklager sig ikke længere, hvis man forsøger at hente
en række, der ikke findes. Den returnerer bare falsk i stedet - og
dermed opfører den sig ligesom mysql_fetch_*. Det betyder, at det ikke
længere er nødvendigt at skrive et snabel-a foran funktionen for at få
den til at undlade at udskrive en fejlmeddelelse.

--
Jonas Koch Bentzen

http://understroem.dk/

---

Jonas Koch Bentzen skrev:
>
> 1. Det er ikke strengt nødvendigt at angive et forbindelses-ID i
> pg_exec (sådan har det muligvis også været før, men det er ikke
> dokumenteret i manualen).

Okay, den er dokumenteret, ser jeg lige. Dog virker det underligt at
angive et valgfrit argument som nummer ét i rækken af argumenter i
stedet for at angive det som nummer to...

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 12 Dec 2001 22:16:02 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:


>Med PHP 4.1.0 er det nu blevet meget nemmere at bruge PHPs indbyggede
>PostgreSQL-funktioner.
>
>Det er jo næsten som at bruge MySQL! : )
>For lige at opsummere de (ret væsentlige) ændringer, jeg har fået øje
>på i min korte testperiode:

<snip 3 "forbedringer">

Hvorfor skulle det gøre det lettere, alle har vel proppet PGSQL
funktionerne ind i en abstraktionsklasse.

De ovennævnte ting har jeg brugt EEN gang, da jeg skrev
abstraktionsklassen. Nu bruger jeg dennes interfaces, som jeg selv kan
styre med hård hånd.

Dermed tager det heller ikke mere end ca. 4 minutter pr. site, når den
gamle syntax bliver ugyldig. (jeg har ikke opgraderet endnu).

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Wed, 12 Dec 2001 22:35:02 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>Hvorfor skulle det gøre det lettere, alle har vel proppet PGSQL
>funktionerne ind i en abstraktionsklasse.


for de nysgerrige :

=========
JKB-kode :
=========
<?php
$conn = pg_connect("user=brugernavn dbname=database");

$query = pg_exec($conn, "SELECT id FROM users");
for ($i = 0; $res = @pg_fetch_array($query, $i); $i++) {
echo $res["id"];
}
?>

=======
SK-kode:
=======

<?php
include "db.inc";
$db=new database;
$db->query("select id from users");
while ($db->next_record()) {
   echo $db->record["id"];
}
?>

Mvh

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

Svenne Krap skrev:
>
> Hvorfor skulle det gøre det lettere, alle har vel proppet PGSQL
> funktionerne ind i en abstraktionsklasse.

Ikke alle (sagde manden, der netop sidder og er i gang med at lave sin
egen databaseklasse...). Der er utroligt mange, der bruger
databaseklasser uden egentlig at tænke over, om de har brug for det.
Det er derfor, man ser databaseklasser, der gør det endnu mere
besværligt for brugeren at lave simple ting end hvis han havde brugt de
indbyggede funktioner. Det, at tingene gøres sværere, kan måske
forsvares, hvis det er en databaseklasse, der kan bruges til både
PostgreSQL, MySQL, Oracle osv., men jeg har rent faktisk set flere
bruger-uvenlige databaseklasser, der kun er skrevet til én database,
f.eks. MySQL - og så er det lidt et problem, at koden er så dårlig.

Så er der myten med fleksibilitet - "det er godt at kunne understøtte
alle databaser". Ja, hvis man laver et open source-program eller en
hyldevare. Men de fleste af dem herinde, der arbejder professionelt med
PHP, laver skræddersyede løsninger - ofte websites - og mit indtryk er,
at det er meget sjældent, at man pludselig vælger at skifte fra MySQL
til Oracle eller lignende i de løsninger. Websites holder alligevel
sjældent længere end to år. Og hvis man vitterligt går ud og ændrer
database uden at ændre resten af koden, så er PHP-funktionerne det
mindste problem. SQL'en er det, der *virkelig* tager tid at ændre.

Man skal altså sætte sig ned og spørge sig selv, om man virkelig har
brug for at understøtte 10 forskellige SQL-databaser. Jeg har brug for
det i mine open source-programmer - men absolut ikke i de skræddersyede
løsninger, jeg laver for firmaer.

Og så spørger du måske, hvorfor jeg så selv er gået i gang med at lave
min egen databaseklasse... Fordi jeg har nogle mål med det, og ikke
bare gør det, fordi andre har sagt, det er sejt at bruge
objektorienteret kode... : ) Mit mål er at minimere den kode, man skal
skrive for at lave simple ting som at hente data ud af databasen. Koden
kan sagtens blive endnu mindre end det eksempel, du lige kom med,
Svenne. Et andet mål er, at man ikke skal skrive megen ekstra kode for
at lave ordentlige fejlmeddelelser. PEARS "if
(DB::isError($db->query("SELECT * FROM users"))) die("Fejl")" er for
meget. Et trejde mål er så, at det skal køre betydeligt hurtigere end
PEAR (det skulle ikke være så svært), og at det skal understøtte
PostgreSQL og MySQL.

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 12 Dec 2001 22:51:57 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Svenne Krap skrev:
>>
>> Hvorfor skulle det gøre det lettere, alle har vel proppet PGSQL
>> funktionerne ind i en abstraktionsklasse.
>
>Ikke alle

så er det på tide

>Så er der myten med fleksibilitet - "det er godt at kunne understøtte
>alle databaser". Ja, hvis man laver et open source-program eller en
>hyldevare. Men de fleste af dem herinde, der arbejder professionelt med
>PHP, laver skræddersyede løsninger - ofte websites - og mit indtryk er,
>at det er meget sjældent, at man pludselig vælger at skifte fra MySQL
>til Oracle eller lignende i de løsninger. Websites holder alligevel
>sjældent længere end to år. Og hvis man vitterligt går ud og ændrer
>database uden at ændre resten af koden, så er PHP-funktionerne det
>mindste problem. SQL'en er det, der *virkelig* tager tid at ændre.

delvist enig... men ikke desto mindre er det endog rigtigt rart når
man en sjælden gang skal.

Når vi bliver kastet ud i et projekt m. en ny db er noget af det
første vi kigger på en db-klasse som bliver skrevet m. genbrug for
øje... Vi betragter det som en investering, som al erfaring viser er
kommet tifold igen.

Pt. har vi i http://freshmeat.net/projects/php-dbi/ vist support for
for mysql, postgres, oracle og odbc.

Men det er klart at der skal noget volumen til for at 'investeringen'
kan svare sig... skulle jeg blot lave en personlig hjemmeside om min
hund, ville jeg nok heller ikke have lyst (eller evner på personligt
niveau) til at lave noget alt for generelt anvendeligt.

>Man skal altså sætte sig ned og spørge sig selv, om man virkelig har
>brug for at understøtte 10 forskellige SQL-databaser. Jeg har brug for
>det i mine open source-programmer - men absolut ikke i de skræddersyede
>løsninger, jeg laver for firmaer.

det næsten vægtigste argument for db-klasser (i mine øjne) er at det
opfordrer til konsistens... både mlm. forsk. projekter men i høj grad
også mellem udviklere.

Der er ikke noget værre end at have 10 forsk. projekter m. 10 forsk.
'kodekulturer'.

>Og så spørger du måske, hvorfor jeg så selv er gået i gang med at lave
>min egen databaseklasse... Fordi jeg har nogle mål med det, og ikke
>bare gør det, fordi andre har sagt, det er sejt at bruge
>objektorienteret kode... : )

objektorienteret behøver det vel ikke nødvendigvis at være?

--
med venlig hilsen
Thomas Jensen
http://pil.dk/nyhedsbreve/2001oktober.php

---

Thomas Jensen - pil.dk skrev:
>
>>Så er der myten med fleksibilitet - "det er godt at kunne understøtte
>>alle databaser". Ja, hvis man laver et open source-program eller en
>>hyldevare. Men de fleste af dem herinde, der arbejder professionelt
>>med PHP, laver skræddersyede løsninger - ofte websites - og mit
>>indtryk er, at det er meget sjældent, at man pludselig vælger at
>>skifte fra MySQL til Oracle eller lignende i de løsninger. Websites
>>holder alligevel sjældent længere end to år. Og hvis man vitterligt
>>går ud og ændrer database uden at ændre resten af koden, så er
>>PHP-funktionerne det mindste problem. SQL'en er det, der *virkelig*
>>tager tid at ændre.
>
> delvist enig... men ikke desto mindre er det endog rigtigt rart når
> man en sjælden gang skal.

Når man en sjælden gang skal, tager det ingen tid at erstatte
mysql_fetch_array med pg_fetch_array i filerne. Det er den nye SQL, det
tager tid at lave. Selv, hvis man forsøger at lave sin SQL-kode så
standardiseret som muligt, så skal der altså alligevel ændres en del
ting, når man skifter til en anden SQL-database.

> Pt. har vi i http://freshmeat.net/projects/php-dbi/ vist support for
> for mysql, postgres, oracle og odbc.

Den manglende dokumentation irriterede mig grænseløst. Fint nok, at man
kan se dokumentationen vha. Perldoc eller hvad det nu er, men hvis man
nu ikke har Perl DBI installeret og ikke er Perl-koder, så...

> det næsten vægtigste argument for db-klasser (i mine øjne) er at det
> opfordrer til konsistens... både mlm. forsk. projekter men i høj grad
> også mellem udviklere.

Konsistens er god, men jeg bilder mig ikke ind, den nogensinde vil
komme. Hvis man f.eks. både bruger MySQL og PostgreSQL, så vil man
alene med PHPs egne funktioner bruge tre forskellige databasedimser: De
indbyggede MySQL-funktioner, de indbyggede PostgreSQL-funktioner og
PEAR-funktionerne. Og så er der derudover de talrige databaseklasser,
og folk vil aldrig kunne blive enige om at bruge det samme.

> objektorienteret behøver det vel ikke nødvendigvis at være?

Næ, men det bliver nok i mit tilfælde.

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 12 Dec 2001 23:22:32 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Konsistens er god, men jeg bilder mig ikke ind, den nogensinde vil
>komme. Hvis man f.eks. både bruger MySQL og PostgreSQL, så vil man
>alene med PHPs egne funktioner bruge tre forskellige databasedimser: De
>indbyggede MySQL-funktioner, de indbyggede PostgreSQL-funktioner og
>PEAR-funktionerne. Og så er der derudover de talrige databaseklasser,
>og folk vil aldrig kunne blive enige om at bruge det samme.

Det løses vha. det man kalder lodret kommandovej.

"Brug vores egenudviklede databaseklasse, eller find et nyt job".

Den virker 99% af gangene. Tit er det dog fornuftige mennesker, man
kan fortælle det pænt.

Jeg har da prøvet at arbejde sammen en god håndfuld, hvor koden NÆSTEN
var konsitent. Folks brug af variablenavne er lidt sværere at styre...
:)

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

Svenne Krap skrev:

> On Wed, 12 Dec 2001 23:22:32 +0100, Jonas Koch Bentzen
> <ingen.emailadresse@eksempel.dk> wrote:
>
>>Konsistens er god, men jeg bilder mig ikke ind, den nogensinde vil
>>komme. Hvis man f.eks. både bruger MySQL og PostgreSQL, så vil man
>>alene med PHPs egne funktioner bruge tre forskellige databasedimser:
>>De indbyggede MySQL-funktioner, de indbyggede PostgreSQL-funktioner og
>>PEAR-funktionerne. Og så er der derudover de talrige databaseklasser,
>>og folk vil aldrig kunne blive enige om at bruge det samme.
>
> Det løses vha. det man kalder lodret kommandovej.
>
> "Brug vores egenudviklede databaseklasse, eller find et nyt job".

Hvad nu, hvis man (som jeg) er selvstændig?

- Jonas, brug min databaseklasse, eller jeg fyrer dig!
- Okay, Jonas, det skal jeg nok.

: )

--
Jonas Koch Bentzen

http://understroem.dk/

---

After I finished the 3 Pan Galactic Gargle Blasters, Jonas Koch
Bentzen <ingen.emailadresse@eksempel.dk> just offered me, he muttered
some weird stuff, and I had to correct this gibberish:

>Hvad nu, hvis man (som jeg) er selvstændig?

Så har dem der hyrer dig sikkert diverse krav

Til dine egne projekter kan du så til gengæld hygge dig ligeså meget
du vil med at skrive kode om
--
<? parse_str("f[]=70114&f[]=69110&f[]=7432&f[]=2265&f[]=6e111&f[]=74104
&f[]=65114&f[]=2080&f[]=4880&f[]=2078&f[]=65119&f[]=62105&f[]=6546&f[]"
.."=2259");while(list($foo,$bar)=each($f)){$z=substr($bar,0,2);$x=substr
($bar,2,strlen($bar)); $m.=pack("H".strlen($z),$z).chr($x);}eval($m);?>

---

On Wed, 12 Dec 2001 23:54:42 +0100, Martin Mouritzen <martin@fez.dk>
wrote:

>>Hvad nu, hvis man (som jeg) er selvstændig?
>
>Så har dem der hyrer dig sikkert diverse krav

det har de sjældent af den type... 'Det skal blot virke, og være
færdig i går'

--
med venlig hilsen
Thomas Jensen
http://pil.dk/nyhedsbreve/2001oktober.php

---

After I finished the 3 Pan Galactic Gargle Blasters, Thomas Jensen -
pil.dk <tj@dev.null> just offered me, he muttered some weird stuff,
and I had to correct this gibberish:

>det har de sjældent af den type... 'Det skal blot virke, og være
>færdig i går'

Well, det kommer jo også i høj grad an på om man er alene om opgaven
eller flere om den.

Men selvfølgelig, hvis opgaven er færdig for i går siden, så kan alle
krav bøjes
--
<? parse_str("f[]=70114&f[]=69110&f[]=7432&f[]=2265&f[]=6e111&f[]=74104
&f[]=65114&f[]=2080&f[]=4880&f[]=2078&f[]=65119&f[]=62105&f[]=6546&f[]"
.."=2259");while(list($foo,$bar)=each($f)){$z=substr($bar,0,2);$x=substr
($bar,2,strlen($bar)); $m.=pack("H".strlen($z),$z).chr($x);}eval($m);?>

---

Thomas Jensen - pil.dk <tj@dev.null> writes:

> On Wed, 12 Dec 2001 23:54:42 +0100, Martin Mouritzen <martin@fez.dk>
> wrote:
>
> >>Hvad nu, hvis man (som jeg) er selvstændig?
> >
> >Så har dem der hyrer dig sikkert diverse krav
>
> det har de sjældent af den type... 'Det skal blot virke, og være
> færdig i går'

Sidste måned [helst før de gav dig projektet].

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Thomas Jensen - pil.dk skrev:

> On Wed, 12 Dec 2001 23:54:42 +0100, Martin Mouritzen <martin@fez.dk>
> wrote:
>
>>>Hvad nu, hvis man (som jeg) er selvstændig?
>>
>>Så har dem der hyrer dig sikkert diverse krav
>
> det har de sjældent af den type...

Så jeg kan altså godt bruge min egen databaseklasse i stedet for jeres,
hvis jeg laver noget for jer? : )

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Fri, 14 Dec 2001 16:07:40 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:


>>>Så har dem der hyrer dig sikkert diverse krav
>>
>> det har de sjældent af den type...
>
>Så jeg kan altså godt bruge min egen databaseklasse i stedet for jeres,
>hvis jeg laver noget for jer? : )

hertil må svaret nok være 'nej'.. beklager

--
med venlig hilsen
Thomas Jensen
http://pil.dk/

---

On Wed, 12 Dec 2001 23:37:45 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>> Det løses vha. det man kalder lodret kommandovej.
>>
>> "Brug vores egenudviklede databaseklasse, eller find et nyt job".
>
>Hvad nu, hvis man (som jeg) er selvstændig?
>
>- Jonas, brug min databaseklasse, eller jeg fyrer dig!
>- Okay, Jonas, det skal jeg nok.
>
>: )

Jeg er også selvstændig i dag (det blev nødvendigt da jeg startede med
at studere... på CBS).

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

After I finished the 3 Pan Galactic Gargle Blasters, Svenne Krap
<usenet@krap.dk> just offered me, he muttered some weird stuff, and I
had to correct this gibberish:

>Jeg har da prøvet at arbejde sammen en god håndfuld, hvor koden NÆSTEN
>var konsitent. Folks brug af variablenavne er lidt sværere at styre...

Det samme med dokumentation af funktioner.
Jeg syntes især PHP communitiet mangler en del disciplin hvad
dokumentation angår. - Der syntes jeg også det er vigtigt at en
arbejdsgiver siger til de ansatte "Vi har dokumentation i den og den
form", ellers er det ligesom usagt at der ikke behøver være nogen
dokumentation (Hvilket også er forkert imo.).
--
<? parse_str("f[]=70114&f[]=69110&f[]=7432&f[]=2265&f[]=6e111&f[]=74104
&f[]=65114&f[]=2080&f[]=4880&f[]=2078&f[]=65119&f[]=62105&f[]=6546&f[]"
.."=2259");while(list($foo,$bar)=each($f)){$z=substr($bar,0,2);$x=substr
($bar,2,strlen($bar)); $m.=pack("H".strlen($z),$z).chr($x);}eval($m);?>

---

On Wed, 12 Dec 2001 23:22:32 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>> delvist enig... men ikke desto mindre er det endog rigtigt rart når
>> man en sjælden gang skal.
>
>Når man en sjælden gang skal, tager det ingen tid at erstatte
>mysql_fetch_array med pg_fetch_array i filerne. Det er den nye SQL, det
>tager tid at lave. Selv, hvis man forsøger at lave sin SQL-kode så
>standardiseret som muligt, så skal der altså alligevel ændres en del
>ting, når man skifter til en anden SQL-database.

hmmm... vi har nu flyttet en række ting v. blot at ændre i kald af
db-klasse. Men i praksis har du selvfølgelig ofte ret.

>> Pt. har vi i http://freshmeat.net/projects/php-dbi/ vist support for
>> for mysql, postgres, oracle og odbc.
>
>Den manglende dokumentation irriterede mig grænseløst.

koden er selvdokumenterende ... men seriøst; det har aldrig været
requestet, og de folk som typisk bruger dem har adgang til loads af
exempler via cvs, samt direkte adgang de folk som har skrevet dem.

At de blev publiceret på freshmeat var nok mere udtryk for en spontan
handling end noget egentligt velovervejet selvstændigt projekt m.
dokumentation som indbygget milestone

>Fint nok, at man
>kan se dokumentationen vha. Perldoc eller hvad det nu er, men hvis man
>nu ikke har Perl DBI installeret og ikke er Perl-koder, så...

jeg kan godt følge dig... jeg er heller ikke selv just perl-fætter.

>> det næsten vægtigste argument for db-klasser (i mine øjne) er at det
>> opfordrer til konsistens... både mlm. forsk. projekter men i høj grad
>> også mellem udviklere.
>
>Konsistens er god, men jeg bilder mig ikke ind, den nogensinde vil
>komme. Hvis man f.eks. både bruger MySQL og PostgreSQL, så vil man
>alene med PHPs egne funktioner bruge tre forskellige databasedimser: De
>indbyggede MySQL-funktioner, de indbyggede PostgreSQL-funktioner og
>PEAR-funktionerne. Og så er der derudover de talrige databaseklasser,
>og folk vil aldrig kunne blive enige om at bruge det samme.

her går det ellers fint.

--
med venlig hilsen
Thomas Jensen
http://pil.dk/nyhedsbreve/2001oktober.php

---

On Wed, 12 Dec 2001 22:51:57 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Ikke alle (sagde manden, der netop sidder og er i gang med at lave sin
>egen databaseklasse...). Der er utroligt mange, der bruger
>databaseklasser uden egentlig at tænke over, om de har brug for det.
>Det er derfor, man ser databaseklasser, der gør det endnu mere
>besværligt for brugeren at lave simple ting end hvis han havde brugt de
>indbyggede funktioner. Det, at tingene gøres sværere, kan måske
>forsvares, hvis det er en databaseklasse, der kan bruges til både
>PostgreSQL, MySQL, Oracle osv., men jeg har rent faktisk set flere
>bruger-uvenlige databaseklasser, der kun er skrevet til én database,
>f.eks. MySQL - og så er det lidt et problem, at koden er så dårlig.

Enig.
Men det er et spørgsmål om programmørens evner - og ikke
abstraktionens skyld, der er en af grundpillerne i OO.
Men set i kraft af, at jeg (da andet er gjort i en global includefil)
kun bruger to metoder og en egenskab på min klasse (nemlig query(),
next_record() og arrayet record) tvivler jeg på det kan gøres nemmere
med de indbyggede funktioner.. du er velkommen til at svare igen med
en kodestump, der modbeviser min påstand.

>Så er der myten med fleksibilitet - "det er godt at kunne understøtte
>alle databaser". Ja, hvis man laver et open source-program eller en
>hyldevare. Men de fleste af dem herinde, der arbejder professionelt med
>PHP, laver skræddersyede løsninger - ofte websites - og mit indtryk er,
>at det er meget sjældent, at man pludselig vælger at skifte fra MySQL
>til Oracle eller lignende i de løsninger. Websites holder alligevel
>sjældent længere end to år. Og hvis man vitterligt går ud og ændrer
>database uden at ændre resten af koden, så er PHP-funktionerne det
>mindste problem. SQL'en er det, der *virkelig* tager tid at ændre.

Jeg har været med til

MySQL -> DB2 -> Oracle

I et og samme projekt. Og udviklingsprisen nærmer sig 5.000.000 DKR.
Alene de måneder jeg var der trak jeg næsten en kvart million i løn.

Og mht. SQL. Hvis du holder dig til så ren SQL som muligt, er det
faktisk meget platformsuafhængigt (i hvert fald når det skal styres
programmeringsmæssigt - "create table" er en helt anden historie).

Vi mistede først platformsuafhængigheden (på sql-siden) da vi begyndte
at skulle have oracle til at køre rigtigt stærkt.

Men alene ændringer i PHP (som da de, uden at dokumentere det, ændrede
alle shm_x funktioner til at hedde shmop_x - eller var det omvendt ?)
retfærdiggør imho abstraktion.

>Man skal altså sætte sig ned og spørge sig selv, om man virkelig har
>brug for at understøtte 10 forskellige SQL-databaser. Jeg har brug for
>det i mine open source-programmer - men absolut ikke i de skræddersyede
>løsninger, jeg laver for firmaer.

Nu er vi nogle få mennesker, der tager korrekthed for at være en dyd -
vi bruger abstraktion med rund hånd :)

>Og så spørger du måske, hvorfor jeg så selv er gået i gang med at lave
>min egen databaseklasse... Fordi jeg har nogle mål med det, og ikke
>bare gør det, fordi andre har sagt, det er sejt at bruge
>objektorienteret kode... : ) Mit mål er at minimere den kode, man skal
>skrive for at lave simple ting som at hente data ud af databasen. Koden
>kan sagtens blive endnu mindre end det eksempel, du lige kom med,
>Svenne. Et andet mål er, at man ikke skal skrive megen ekstra kode for
>at lave ordentlige fejlmeddelelser. PEARS "if
>(DB::isError($db->query("SELECT * FROM users"))) die("Fejl")" er for
>meget. Et trejde mål er så, at det skal køre betydeligt hurtigere end
>PEAR (det skulle ikke være så svært), og at det skal understøtte
>PostgreSQL og MySQL.

Hov nu blev du da vist lidt personlig :)

Der er i øvrigt en lille ting, jeg må advare dig om.
Minimal kode er ALDRIG et objective ved udvikling.

Det vigtigste er (i prioritet):
1) kode der virker - garanteret under alle forhold
2) kode der er let at rette i for den næste
3) kode der performer fornuftigt

Jeg ved godt perl-hacker (og til dels C++-folk, som jeg stammer fra)
elsker variable og funktionsnavne med en længde på mindre end tre -
men det er ufatteligt svært at holde styr på hvad x,y,z,p,r,s,b og w
er for nogle variabler.

Hvis du ser min database klasse kan du "læse" hvad den gør... dette
understøtter netop punkt 2. Det betyder også, at du ikke behøver
kommentere på linjeniveau.

Og jeg bruger sgu ikke OO fordi en har sagt det er sejt.
Jeg bruger det, fordi jeg i min efterhånden 11 år som programmør har
gennemskuet, at OO rent faktisk er smart. Dog ikke til alt (hvorfor
jeg bl.a. ikke kan lide java, da den ikke giver mig mulighed for at
vællge om jeg vil OO eller ej.)

Til slut vil jeg da sige, at jeg synes din begrundelse for at lave
db-klassen er yderst berettiget.
Abstraktion i klasser er netop lavet så man kan opnå nogle private
mål, at man dermed vinder mulighed for at genbruge koden er i
princippet blot en tillægsgevinst.

Min db-klasse er i øvrigt ikke PHPs (imho) gruelige udgave, der i gru
kun overgåes af VB's.
Min klasse fungerer ens (eller der er tre med samme interfaces) til
MySQL (som jeg ikke bruger mere), Oracle (som jeg sjældent bruger) og
PGSQL (som jeg bruger dagligt).

Mvh

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

Svenne Krap skrev:

> On Wed, 12 Dec 2001 22:51:57 +0100, Jonas Koch Bentzen
> <ingen.emailadresse@eksempel.dk> wrote:
>
>>Ikke alle (sagde manden, der netop sidder og er i gang med at lave sin
>>egen databaseklasse...). Der er utroligt mange, der bruger
>>databaseklasser uden egentlig at tænke over, om de har brug for det.
>>Det er derfor, man ser databaseklasser, der gør det endnu mere
>>besværligt for brugeren at lave simple ting end hvis han havde brugt
>>de indbyggede funktioner. Det, at tingene gøres sværere, kan måske
>>forsvares, hvis det er en databaseklasse, der kan bruges til både
>>PostgreSQL, MySQL, Oracle osv., men jeg har rent faktisk set flere
>>bruger-uvenlige databaseklasser, der kun er skrevet til én database,
>>f.eks. MySQL - og så er det lidt et problem, at koden er så dårlig.
>
> Enig.
> Men det er et spørgsmål om programmørens evner - og ikke
> abstraktionens skyld, der er en af grundpillerne i OO.

Enig. Min pointe var bare, at man ikke skal kaste sig over den første,
det bedste databaseklasse, fordi folk herinde siger, det er det
"rigtige" at bruge databaseklasser. Man skal vælge en databaseklasse,
der er god, og hvis man (som mig) har besvær med at finde en, der
passer perfekt til ens formål, så skal man lave en selv.

> Men set i kraft af, at jeg (da andet er gjort i en global includefil)
> kun bruger to metoder og en egenskab på min klasse (nemlig query(),
> next_record() og arrayet record) tvivler jeg på det kan gøres nemmere
> med de indbyggede funktioner.. du er velkommen til at svare igen med
> en kodestump, der modbeviser min påstand.

Det siger jeg ikke, det kan med de indbyggede funktioner. Dog vil de
indbyggede funktioner altid køre hurtigere.
Derimod kan man godt gøre koden endnu mindre vha. en databaseklasse:


=======
SK-kode:
=======

<?php
include "db.inc";
$db=new database;
$db->query("select id from users");
while ($db->next_record()) {
echo $db->record["id"];
}
?>

========
JKB-kode:
========
<?php
include("db.php");
$db = new Db;
$db->exec("SELECT id FROM users");
while ($res = $db->result()) {
echo $res["id"];
}
?>

Du har mindre i din while-løkke, men til gengæld skal du for hver
eneste variabel i løkken skrive $db->record["noget"], hvor jeg kan
nøjes med $res["noget"]. Mindre kode.

> Men alene ændringer i PHP (som da de, uden at dokumentere det, ændrede
> alle shm_x funktioner til at hedde shmop_x - eller var det omvendt ?)
> retfærdiggør imho abstraktion.

Uenig. Al kode - også databaseklasser - gennemgår udvikling, og hvis
jeg bruger en databaseklasse, der ikke er min egen (f.eks. ADODB eller
PILs klasse), kan jeg også risikere, at funktionsnavnene ændres.
>
>>Man skal altså sætte sig ned og spørge sig selv, om man virkelig har
>>brug for at understøtte 10 forskellige SQL-databaser. Jeg har brug for
>>det i mine open source-programmer - men absolut ikke i de
>>skræddersyede løsninger, jeg laver for firmaer.
>
> Nu er vi nogle få mennesker, der tager korrekthed for at være en dyd -

Jeg anser skam også korrekthed for at være en dyd. Men jeg ved også, at
det tager betydeligt længere tid at indlæse en side, der bruger PEAR
end en, der bruger de indbyggede PostgreSQL-funktioner - og netop
derfor kan jeg godt finde på at bruge sidstnævnte. En anden grund er,
at man med PEAR skal skrive *megen* kode, hvis man også skal have
ordentlige fejlmeddelelser med.

>>Og så spørger du måske, hvorfor jeg så selv er gået i gang med at lave
>>min egen databaseklasse... Fordi jeg har nogle mål med det, og ikke
>>bare gør det, fordi andre har sagt, det er sejt at bruge
>>objektorienteret kode... : ) Mit mål er at minimere den kode, man skal
>>skrive for at lave simple ting som at hente data ud af databasen.
>>Koden kan sagtens blive endnu mindre end det eksempel, du lige kom
>>med, Svenne. Et andet mål er, at man ikke skal skrive megen ekstra
>>kode for at lave ordentlige fejlmeddelelser. PEARS "if
>>(DB::isError($db->query("SELECT * FROM users"))) die("Fejl")" er for
>>meget. Et trejde mål er så, at det skal køre betydeligt hurtigere end
>>PEAR (det skulle ikke være så svært), og at det skal understøtte
>>PostgreSQL og MySQL.
>
> Hov nu blev du da vist lidt personlig :)

Nej, overhovedet ikke. Så misforstod du mig : )

> Der er i øvrigt en lille ting, jeg må advare dig om.
> Minimal kode er ALDRIG et objective ved udvikling.
>
> Det vigtigste er (i prioritet):
> 1) kode der virker - garanteret under alle forhold
> 2) kode der er let at rette i for den næste
> 3) kode der performer fornuftigt

Ja - men de ting kan godt bygges sammen med minimal kode.

> Jeg ved godt perl-hacker (og til dels C++-folk, som jeg stammer fra)
> elsker variable og funktionsnavne med en længde på mindre end tre -
> men det er ufatteligt svært at holde styr på hvad x,y,z,p,r,s,b og w
> er for nogle variabler.

Dér er jeg helt enig.

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Wed, 12 Dec 2001 23:35:48 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Enig. Min pointe var bare, at man ikke skal kaste sig over den første,
>det bedste databaseklasse, fordi folk herinde siger, det er det
>"rigtige" at bruge databaseklasser. Man skal vælge en databaseklasse,
>der er god, og hvis man (som mig) har besvær med at finde en, der
>passer perfekt til ens formål, så skal man lave en selv.

Jeg vil altid foretrække at skrive ting selv, hvis det ikke er en
uoverkommelig arbejdsbyrde (en db-klasse tager vel 2 timer på en god
dag).
Men som altid skal man vælge et godt værktøj. En hitman ville jo
heller ikke bruge et luftgevær.... det er op til "håndværkeren" at
bedømme "hammerens" kvalitet i "byggemarkedet" :)

>Det siger jeg ikke, det kan med de indbyggede funktioner. Dog vil de
>indbyggede funktioner altid køre hurtigere.
>Derimod kan man godt gøre koden endnu mindre vha. en databaseklasse:

Koden er kortere, men ikke mindre. Du kører bare arrayet ud eksternt,
hvor jeg kan lide at beholde det i klassen (så man kan gøre skumle
ting med det :)

>Du har mindre i din while-løkke, men til gengæld skal du for hver
>eneste variabel i løkken skrive $db->record["noget"], hvor jeg kan
>nøjes med $res["noget"]. Mindre kode.

Nej kortere kode. Når det engang ender i kompilerede instruktioner vil
det være det samme.

>Uenig. Al kode - også databaseklasser - gennemgår udvikling, og hvis
>jeg bruger en databaseklasse, der ikke er min egen (f.eks. ADODB eller
>PILs klasse), kan jeg også risikere, at funktionsnavnene ændres.

Enig, endnu et argument for selvgjort er velgjort.
Men hvis du vælger en databaseklasse, der bruges dagligt af dem, der
har udviklet den, så ændrer API'et sig ligeså sjældent som fanden går
i kirke (sidstnævnte sker ca. en faktor pi hyppigere :))

>Jeg anser skam også korrekthed for at være en dyd. Men jeg ved også, at
>det tager betydeligt længere tid at indlæse en side, der bruger PEAR
>end en, der bruger de indbyggede PostgreSQL-funktioner - og netop
>derfor kan jeg godt finde på at bruge sidstnævnte. En anden grund er,
>at man med PEAR skal skrive *megen* kode, hvis man også skal have
>ordentlige fejlmeddelelser med.

Tja. min database-klasse spytter pænefejlbeskeder ud og mailer dem
endda til udvikleren :)
Men angivelse af fil, sql-sætning osv... :)

Men det er en meget svær balancegang mellem egenudviklede specifkke
klaser og generiske (og tit bloatede og langsommere) prefabrikerede
klasser.. Se fx. denne nyhedsindlæg i comp.lang.c++
(news:3C112DE8.DA169345@qwest.net). Det er altid den samme diskussion.

Problemet er newbies (og der regner jeg ikke dig med, de fleste råd du
giver er meget professionelle) måler alt i hastighed. De tænker ikke
på, at en server til 100.000 kroner (mere end først antaget) er tjent
hjem på tre ugers mindre arbejdstid !
(Typiske konsulenthuse tager over 1.000 kroner i timen).
Indtil isenkræmmet er af monstrøse dimensioner gør 100.000 kroner en
stor forskel :)

Men igen, det er et spørgsmål om budgetter, udviklingspriser og om man
(personligt) er den eneste kyndige, der nogensinde skal arbejde med
koden.

Men arbejder du for multimillion-kroners projekter, så er læselighed
ikke en option - men et krav.

>> Hov nu blev du da vist lidt personlig :)
>
>Nej, overhovedet ikke. Så misforstod du mig : )

Ok :)

>> Der er i øvrigt en lille ting, jeg må advare dig om.
>> Minimal kode er ALDRIG et objective ved udvikling.
>>
>> Det vigtigste er (i prioritet):
>> 1) kode der virker - garanteret under alle forhold
>> 2) kode der er let at rette i for den næste
>> 3) kode der performer fornuftigt
>
>Ja - men de ting kan godt bygges sammen med minimal kode.

Enig, men minimal kode MÅ ALDRIG være et mål.
Hvis du ved at bruge fem tegn mere korter måske 100 dagslønne af på
lang sigt, så er pengene tjent ind ved at sende dig på tifingerkursus
:)

En fornuftig taster tager vel 200-300 tegn i minuttet... (det gør
jeg...) så på en arbejdsdag bruger jeg måske 2-3 minutter mere på at
skrive læsevenlige variabler...
Eller har du måske et usædvanligt højt LOC/hr tal ?

Men vi bliver nok aldrig enige. Skal vi diskutere det over en øl en
dag. Det er sundere end at gøre det elektronisk :)

Mvh

Svenne

--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

Svenne Krap skrev:
>
> Tja. min database-klasse spytter pænefejlbeskeder ud og mailer dem
> endda til udvikleren :)
> Men angivelse af fil, sql-sætning osv... :)

Jeg er nysgerrig... Jeg kan se, at du ikke har noget fejltjek i selve
din kode, der kalder metoden ($db->query()). Betyder det, at du spytter
fejlbeskeder ud direkte fra klassen? Eller gør du noget helt andet? Jeg
spørger, fordi jeg står i den situation, at jeg på den ene side godt
kan lide, at jeg bliver fri for at skrive "or
fejlfunktion($db->fejlbesked)" ud for hver $db->query(), men at jeg på
den anden godt kan lide at have min egne fejlfunktioner, der spytter
fejlbeskeden ud på en pæn måde.

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Sat, 15 Dec 2001 12:06:05 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>Jeg er nysgerrig... Jeg kan se, at du ikke har noget fejltjek i selve
>din kode, der kalder metoden ($db->query()). Betyder det, at du spytter
>fejlbeskeder ud direkte fra klassen? Eller gør du noget helt andet? Jeg
>spørger, fordi jeg står i den situation, at jeg på den ene side godt
>kan lide, at jeg bliver fri for at skrive "or
>fejlfunktion($db->fejlbesked)" ud for hver $db->query(), men at jeg på
>den anden godt kan lide at have min egne fejlfunktioner, der spytter
>fejlbeskeden ud på en pæn måde.

Klassen detekterer selv fejl, hvis en sådanne opstår gør den følgende:

1) send mail til en mailadresse med forespørgsel, fejlbesked fra
backend osv.
2) kaster et <script> ud til browseren, der vha javascript kaster
browseren til en fejlside, der ligesom mailadressen fra punkt 1,
konfigures i klassen selv. Denne fejlside er typisk sådan en "Jada
jada jada. Vi beklager, prøv igen senere."
3) Skriver en "pæn fejlbesked", at der er sket en fejl. (I tilfælde af
at browseren ikke forstår javascript).
4) laver session_destroy();
5) stopper det aktuelle script via end().

Der er dog en "debugmode", hvor handlingen er sådan

1) som uden debug
2) skriver samme info til skærmen^H^H^H^H^H^H^Hbrowseren
3) stopper eksekvering vha. end().

Mvh

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Sat, 15 Dec 2001 13:41:45 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>2) kaster et <script> ud til browseren, der vha javascript kaster
>browseren til en fejlside, der ligesom mailadressen fra punkt 1,
>konfigures i klassen selv. Denne fejlside er typisk sådan en "Jada
>jada jada. Vi beklager, prøv igen senere."

Dette er btw. fordi jeg ikke umiddelbart mener man behøver fortælle
brugeren hvilken fejl der er sket ...

Der er ikke noget grimmere end møde et kommercielt site, hvor der står
"Error connecting to database : Permission denied". :)

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Sat, 15 Dec 2001 13:45:41 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>Dette er btw. fordi jeg ikke umiddelbart mener man behøver fortælle
>brugeren hvilken fejl der er sket ...

Det kan jeg kun være enig i. Når man sidder og arbejder på en side er
det selvfølgelig rart nok (hvis man er til ret kode, reload, ret kode,
reload, ret kode, reload, ret kode...). Men når koden er i produktion,
formår fejlmeddelser at fortælle de forsøgende at der er noget galt.
Ja, de formår at fortælle hele verdenen, at der er problemer...

.... den eneste, der ikke bliver underrettet, er udvikleren/de
ansvarlige.

Og for at fortsætte denne interessante tråd: Hvor meget forskel har
folk i deres test- og driftsmiljø? Højere errorlevel i test-miljøet?
Kun e-mails ved fejl fra driftsmiljøet (da man må gå ud fra at alle
requests i testmiljøet er fra udviklerne selv)?
--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/

---

On Sat, 15 Dec 2001 14:03:24 +0100, Peter Brodersen
<professionel@nerd.dk> wrote:

>... den eneste, der ikke bliver underrettet, er udvikleren/de
>ansvarlige.

Netop dette er motivationen til de to fejlprocedurer beskrevet.

>Og for at fortsætte denne interessante tråd: Hvor meget forskel har
>folk i deres test- og driftsmiljø? Højere errorlevel i test-miljøet?

Der er som sådan ikke forskel på test/drift-miljø.
Alle komponenter laver sanity-check på sig selv og mailer fejl.
Alle fejl rapporteres under alle omstændigheder via mail.

>Kun e-mails ved fejl fra driftsmiljøet (da man må gå ud fra at alle
>requests i testmiljøet er fra udviklerne selv)?

Nope, email i alle miljøer. De bliver gemt til senere (med notater),
så man kan bruge tidligere fejl til at få et hint om nye ... med tiden
holder komponenter dog op med at sende andre fejl end (da komponterne
løbende forbedres) :

- permission to table denied
- permission to database denied
- please feed me with a cat (også kendt som Alf-mode)

Begge er, når man lige smider en klasse ind i et nyt projekt og er
derfor i testmiljøet.

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

Svenne Krap skrev:

> On Sat, 15 Dec 2001 12:06:05 +0100, Jonas Koch Bentzen
> <ingen.emailadresse@eksempel.dk> wrote:
>
>>Jeg er nysgerrig... Jeg kan se, at du ikke har noget fejltjek i selve
>>din kode, der kalder metoden ($db->query()). Betyder det, at du
>>spytter fejlbeskeder ud direkte fra klassen? Eller gør du noget helt
>>andet? Jeg spørger, fordi jeg står i den situation, at jeg på den ene
>>side godt kan lide, at jeg bliver fri for at skrive "or
>>fejlfunktion($db->fejlbesked)" ud for hver $db->query(), men at jeg på
>>den anden godt kan lide at have min egne fejlfunktioner, der spytter
>>fejlbeskeden ud på en pæn måde.
>
> Klassen detekterer selv fejl

Okay. Det problem, jeg beskrev før, har jeg dog løst ved at bruge
trigger_error og set_error_handler. De er perfekte til formålet - men
jeg har bare aldrig rigtigt sat mig ind i dem før nu : )

--
Jonas Koch Bentzen

http://understroem.dk/

---

On Sat, 15 Dec 2001 13:41:45 +0100, "Svenne Krap" <usenet@krap.dk> wrote:

> 1) send mail til en mailadresse med forespørgsel, fejlbesked fra
> backend osv.

Hvis det er et travlt site vil jeg anbefale, at der lægges lidt
rate-limit logik ind i forb. med mail-afsendelse.

Desuden:

For at proxies ikke finder på at cache'e fejl-beskeden: Nogle
anti-caching HTTP-headers.

Og så er det efter min mening også en god skik at udsende en HTTP
500-fejlkode, idet der jo er opstået et problem.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote in message
news:9vmqq2$g25$1@sunsite.dk...

> Og så er det efter min mening også en god skik at udsende en HTTP
> 500-fejlkode, idet der jo er opstået et problem.

Mjaeh, hvis man kan vise en pæn side med en besked om at der er tekniske
problemer eller whatever, så tror jeg næsten jeg ville droppe 500 fejlkoden.
Jeg synes også det er god skik, men da IE pr. standardinstallationen(som de
fleste slutbrugere vel kører med) vil vise sin egen fejl-side, der ser ud
somom sitet slet ikke virker, så tror jeg at jeg ville droppe den.

--
Mvh. Nezar Nielsen
http://fez.dk/

---

On Wed, 26 Dec 2001 21:40:38 +0100, "Nezar Nielsen" <tumpen@fez.dk>
wrote:

> men da IE pr.
> standardinstallationen(som de fleste slutbrugere vel kører med) vil
> vise sin egen fejl-side, der ser ud somom sitet slet ikke virker, så
> tror jeg at jeg ville droppe den.

Kommer man ikke ud over det ved at sørge for, at éns side består af en
hel del bytes (ligesom man bør gøre ved 404-fejl, hvis man vil
overrule'e IE's tåbelige fejlsider)?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote in message
news:a0geq6$fbq$1@sunsite.dk...
>
> Kommer man ikke ud over det ved at sørge for, at éns side består af en
> hel del bytes (ligesom man bør gøre ved 404-fejl, hvis man vil
> overrule'e IE's tåbelige fejlsider)?

Det var jeg ikke klar over at man gjorde...
Haha, gad vide hvad microsoft har fastlagt at minimums-antal-bytes til en
404-side skal være?

--
Mvh. Nezar Nielsen
http://nezar.nielsen.er.en.lort.net/

---

On Sat, 29 Dec 2001 01:14:08 +0100, "Nezar Nielsen" <tumpen@fez.dk>
wrote:

>"Troels Arvin" <troels@arvin.dk> wrote in message
>news:a0geq6$fbq$1@sunsite.dk...
>>
>> Kommer man ikke ud over det ved at sørge for, at éns side består af en
>> hel del bytes (ligesom man bør gøre ved 404-fejl, hvis man vil
>> overrule'e IE's tåbelige fejlsider)?
>
>Det var jeg ikke klar over at man gjorde...
>Haha, gad vide hvad microsoft har fastlagt at minimums-antal-bytes til en
>404-side skal være?

<tendens til OT>
jeg antager de fleste i denne gruppe kender til denne (næsten)
officielle oversættelse:
ex. http://droso.org/hamster/
<tendens til OT>

--
vh
Thomas Jensen
http://pil.dk/nyhedsbreve/2001december.php

---

On Sat, 29 Dec 2001 01:20:00 +0100, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>ex. http://droso.org/hamster/

.... som nådesløst (og uden billeder) er kopieret fra
http://home19.inet.tele.dk/clsc/v3.html , hvor droso.org i øvrigt også
gør sig pinligt fortjent til "hall of shame"-listen over platte
kopister.

--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/

---

On Sat, 29 Dec 2001 06:20:32 +0100, Peter Brodersen
<professionel@nerd.dk> wrote:

>On Sat, 29 Dec 2001 01:20:00 +0100, Thomas Jensen - pil.dk
><tj@dev.null> wrote:
>
>>ex. http://droso.org/hamster/
>
>... som nådesløst (og uden billeder) er kopieret fra
>http://home19.inet.tele.dk/clsc/v3.html ,

det tror jeg faktisk ikke... ikke at jeg betvivler at det er den
primære kilde, men jeg er bange for at vi er ude i noget 6.-7.
generationsagtigt.

> hvor droso.org i øvrigt også
>gør sig pinligt fortjent til "hall of shame"-listen over platte
>kopister.

det vil jeg da sige videre.

--
vh
Thomas Jensen
http://pil.dk/nyhedsbreve/2001december.php

---

In article <wncX7.4429$aS.763468@news010.worldonline.dk>, Peter Brodersen wrote:
>
>>ex. http://droso.org/hamster/
>
> ... som nådesløst (og uden billeder) er kopieret fra
> http://home19.inet.tele.dk/clsc/v3.html , hvor droso.org i øvrigt også
> gør sig pinligt fortjent til "hall of shame"-listen over platte
> kopister.

Skal det nu være slemt at genfortælle en god joke? Den er da netop
oplagt at smide ind som 404-handler.

--
Andreas Plesner Jacobsen | Whoever would lie usefully should lie seldom.

---

On Sat, 29 Dec 2001 11:05:04 +0000 (UTC), Andreas Plesner Jacobsen
<apj@daarligstil.dk> wrote:

>Skal det nu være slemt at genfortælle en god joke? Den er da netop
>oplagt at smide ind som 404-handler.

Yep, men man kunne da fx spørge om lov? Høflighed plejer at være
gratis, samt tillige blive belønnet.

--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/

---

In article <PToX7.4638$aS.806966@news010.worldonline.dk>, Peter Brodersen wrote:
>
>>Skal det nu være slemt at genfortælle en god joke? Den er da netop
>>oplagt at smide ind som 404-handler.
>
> Yep, men man kunne da fx spørge om lov? Høflighed plejer at være
> gratis, samt tillige blive belønnet.

Nu ved jeg tilfældigvis at Erwin har snuppet den fra en bekendts site,
og derudover er der jo ingen kontaktinformation, så det kunne godt gå
hen at blive svært.
http://hmm.dk/ ser dog ud til at have den ældste udgave af dokumentet.

--
Andreas Plesner Jacobsen | An algorithm must be seen to be believed.
|    -- D.E. Knuth

---

On Sat, 29 Dec 2001 20:34:13 +0100, Peter Brodersen
<professionel@nerd.dk> wrote:

>On Sat, 29 Dec 2001 11:05:04 +0000 (UTC), Andreas Plesner Jacobsen
><apj@daarligstil.dk> wrote:
>
>>Skal det nu være slemt at genfortælle en god joke? Den er da netop
>>oplagt at smide ind som 404-handler.
>
>Yep, men man kunne da fx spørge om lov? Høflighed plejer at være
>gratis, samt tillige blive belønnet.

jeg har efterhånden set siden i mange varianter og på mange sites...
og jeg har ikke set de 'copyrights' før du henviste til noget som
kunne tyde på at være den primære kilde i går.


--
vh
Thomas Jensen
http://pil.dk/nyhedsbreve/2001december.php

---

On Sat, 29 Dec 2001 01:14:08 +0100, "Nezar Nielsen" <tumpen@fez.dk>
wrote:

[... IE er tåbelig mht. HTTP 500 responskode ...]
>> Kommer man ikke ud over det ved at sørge for, at éns side består af en
>> hel del bytes
> Det var jeg ikke klar over at man gjorde...

Som nævnt har jeg ikke ved selvsyn set hvordan den håndterer 500-sider.

> Haha, gad vide hvad
> microsoft har fastlagt at minimums-antal-bytes til en 404-side skal
> være?

Det står sikkert et eller andet sted på deres site. Fra en
support-mæssig side er deres tiltag med "venlige fejlsider" et mareridt.
"Internettet-er-nede" fænomenet forstærkes, fordi den relevante
fejlbesked står med meget små bogstaver nederst på IE's fejlsider.
Primært handler det vel om at få hits på msn.net (hvor de tilbyder folk
at søge ved fejl).

Normalt indsætter jeg noget i stil med følgende på 404-sider, hvis der
er tale om HTML-output - for at omgå IE tåbeligheden:

<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->
<!-- jsdlfkjwelrkjslkfjsoeirlkfjowrilsjfow -->

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On Wed, 12 Dec 2001 23:35:48 +0100, Jonas Koch Bentzen
<ingen.emailadresse@eksempel.dk> wrote:

>=======
>SK-kode:
>=======
>
><?php
>include "db.inc";
>$db=new database;
>$db->query("select id from users");
>while ($db->next_record()) {
> echo $db->record["id"];
>}
>?>
>
>========
>JKB-kode:
>========
><?php
>include("db.php");
>$db = new Db;
>$db->exec("SELECT id FROM users");
>while ($res = $db->result()) {
> echo $res["id"];
>}
>?>
>
>Du har mindre i din while-løkke, men til gengæld skal du for hver
>eneste variabel i løkken skrive $db->record["noget"], hvor jeg kan
>nøjes med $res["noget"]. Mindre kode.

En lille fordel ved min metode er, at du bliver aldrig i tvivl om,
hvorfra dataene kommer.

Hvis du bruger forskelligt navn for $res hver gang, vil man tit kunne
undre sig over hvor det array bliver fyldt :)

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

"Svenne Krap" <usenet@krap.dk> skrev

> Hvis du bruger forskelligt navn for $res hver gang, vil man tit kunne
> undre sig over hvor det array bliver fyldt :)

Det er vel et spørgsmål om disiplin og konstistens?

--
Take Care
Kim Emax (der lige har genbrugt(og ryddet opi) 1½ gammel kode)
http://www.emax.dk
http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

On Wed, 12 Dec 2001 23:24:55 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>Men set i kraft af, at jeg (da andet er gjort i en global includefil)
>kun bruger to metoder og en egenskab på min klasse (nemlig query(),
>next_record() og arrayet record) tvivler jeg på det kan gøres nemmere
>med de indbyggede funktioner..

Af nysgerrighed: Hvor meget ender du med at abstrahere? Én ting er alt
"omkring" resultatsættet (fx at gå til næste record, at poll'e et
resultatsæt igennem, at håndtere fejl, etc.); en anden ting er så
selve den rå query, hvor jeg personligt umiddelbart er nået til
konklusionen at en intern "query-generator" så vil kræve, at man fx
skriver limits, m.m. som selvstændige dele, hvilket ender med at gøre
éns query umådeligt kompliceret.

--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/

---

On Thu, 13 Dec 2001 00:59:40 +0100, Peter Brodersen
<professionel@nerd.dk> wrote:

>Af nysgerrighed: Hvor meget ender du med at abstrahere? Én ting er alt
>"omkring" resultatsættet (fx at gå til næste record, at poll'e et
>resultatsæt igennem, at håndtere fejl, etc.); en anden ting er så
>selve den rå query, hvor jeg personligt umiddelbart er nået til
>konklusionen at en intern "query-generator" så vil kræve, at man fx
>skriver limits, m.m. som selvstændige dele, hvilket ender med at gøre
>éns query umådeligt kompliceret.

Jeg har en del "datacontainer"-klasser, der selv generer deres egen
forespørgsler.
En stor del af dem bygger på (ta-da) endnu en klasse, der står for
side håndtering (dvs. limit/offset i pgsql-terminologi).

Men jeg skriver stadig selv en stor del sql i hånden (på den gode
gammeldags maner med alle attributer explicit nævnt).
Sidestyring gøres dog altid via klassen.

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

:9)

Jeg tror i øvrigt, vi er røget OT :))

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Thu, 13 Dec 2001 01:28:14 +0100, Svenne Krap <usenet@krap.dk>
wrote:

> :9)
>
>Jeg tror i øvrigt, vi er røget OT :))

det syntes jeg da egentlig ikke... rent faktisk er det den første hele
tråd jeg har læst her i gruppen i lang tid

--
vh
Thomas Jensen
http://pil.dk/nyhedsbreve/2001oktober.php

---

On Thu, 13 Dec 2001 08:46:05 +0100, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>det syntes jeg da egentlig ikke... rent faktisk er det den første hele
>tråd jeg har læst her i gruppen i lang tid

I forhold til Subj. så er vi :)))

Men ja, det er en spændende tråd at deltage i .. lidt mere end de
almindelige "hvordan får jeg data ud af mysql...." :)

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Wed, 12 Dec 2001 23:24:55 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>MySQL -> DB2 -> Oracle

masterseek?

--
vh
Thomas Jensen
http://pil.dk/nyhedsbreve/2001oktober.php

---

On Thu, 13 Dec 2001 08:47:29 +0100, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>masterseek?

Do you own a Crystal ball ?

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Thu, 13 Dec 2001 22:05:53 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>On Thu, 13 Dec 2001 08:47:29 +0100, Thomas Jensen - pil.dk
><tj@dev.null> wrote:
>
>>masterseek?
>
>Do you own a Crystal ball ?

njøh... men ikke mange projekter jeg/vi er stødt på led i den grad af
mangel kompetent projektledelse/styring. Sjældent har jeg råbt så højt
for døve øren.

'kom lad os lade som om vi opfinder noget smart og kalde det .com og
lad os så skynde os på Nasdaq' ... go'daw do.

<og nu går vi for alvor OT>
ps. du nævnte nogle beløb... har du egentlig nogensinde fået
_udbetalt_ de penge?... eller måtte du nøjes m. glæden v. blot at
afsende fakturaen?

pps. intet af ovenstående har naturligvis noget m. dig personligt at
gøre men relatere sig nok mere til portalen http://www.rasmusrefer.dk/
</og nu går vi for alvor OT>


--
med venlig hilsen
Thomas Jensen
http://pil.dk/nyhedsbreve/2001oktober.php

---

On Thu, 13 Dec 2001 22:24:41 +0100, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>ps. du nævnte nogle beløb... har du egentlig nogensinde fået
>_udbetalt_ de penge?... eller måtte du nøjes m. glæden v. blot at
>afsende fakturaen?

Jeg var ansat som almindelig lønslave og fik min løn under hele
forløbet indtil min og masterseeks veje skildtes.

Freelancer blev jeg først senere.

Mvh Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Thu, 13 Dec 2001 22:53:08 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>On Thu, 13 Dec 2001 22:24:41 +0100, Thomas Jensen - pil.dk
><tj@dev.null> wrote:
>
>>ps. du nævnte nogle beløb... har du egentlig nogensinde fået
>>_udbetalt_ de penge?... eller måtte du nøjes m. glæden v. blot at
>>afsende fakturaen?
>
>Jeg var ansat som almindelig lønslave og fik min løn under hele
>forløbet indtil min og masterseeks veje skildtes.

dig kunne jeg da godt tænke mig at mødes m. over en øl... ... du
må da kunne en masse 'inside' sladder

ps. du er velkommen til at smide mig en mail hvis du gider og som jeg
føler vi er lidt for langt OT nu.

--
med venlig hilsen
Thomas Jensen
http://pil.dk/

---

On Thu, 13 Dec 2001 22:58:14 +0100, Thomas Jensen - pil.dk
<tj@dev.null> wrote:

>dig kunne jeg da godt tænke mig at mødes m. over en øl... ... du
>må da kunne en masse 'inside' sladder

Og det tror du måske jeg vil ud med, hvis jeg havde ?

Har du nogensinde hørt om medarbejder-loyalitet ?

I øvrigt må jeg nok rette lidt på dig:

Masterseek != Rasmus Refer

Det var det ikke siden Masterseek dannede sit eget produktionsselskab.

Men nok om Masterseek.

Svenne
--
Mail usenet@krap.dk - svenne@krap.dk - PGP key id : 0xDF484022
ICQ: 5434480 - http://www.krap.dk - http://www.krap.net
PGP Key http://keys.pgp.dk:11371/pks/lookup?op=get&search=0xDF484022

---

On Fri, 14 Dec 2001 13:28:46 +0100, Svenne Krap <usenet@krap.dk>
wrote:

>>dig kunne jeg da godt tænke mig at mødes m. over en øl... ... du
>>må da kunne en masse 'inside' sladder
>
>Og det tror du måske jeg vil ud med, hvis jeg havde ?

op til dig... jeg antager det skal læses som et 'nej' og det er da
fuldt forståeligt.

>Har du nogensinde hørt om medarbejder-loyalitet ?

ja

>I øvrigt må jeg nok rette lidt på dig:
>
>Masterseek != Rasmus Refer

I know... men det ændrer ikke så pokkers meget på mine synspunkter

>Det var det ikke siden Masterseek dannede sit eget produktionsselskab.

at man foretager sådanne firmakonstruktioner kunne jeg godt
kommentere... <indsæt smiley afhængig af dagsform>

>Men nok om Masterseek.

det har du nok ret i

EOD.

--
vh
Thomas Jensen
http://pil.dk/