isset() og E_ALL

Jah, du kan f.x. i starten af dit script

  if (!isset($a)) { $a=""; }

og så blot bruge $a efterfølgende - den vil nemlig være defineret. Der kan så
være situationer, hvor man ikke lige kan dette.

isset() checker om en variabel eksisterer. Normalt ved du vel om dine variable eksisterer eller ej - men der kan selvfølgelig være tvivl hvis input kommer fra URL.

Din if-sætning ser fin ud. Men hvad har alt dette med E_ALL at gøre?

nogle gange kan det bidrage til gennemskueligheden, at opdele if sætninger i flere, med
if (isset($a) && isset($b) && $a!=$b) {
} else if ......

men generelt sagt, véd du jo præcist hvornår $a osv er sat, med mindre disse kommer som parametre. Fx anvender jeg udelukkende isset når det er tale om fx $_GET variabler, som pr default er usikre. Fremfor i hver sætning at spørge "hvis sat", kan du jo også i toppen give værdien en default, fx null - dermed véd du den er sat og behøver ikke længere spørge på om variablen eksisterer

Ja, det havde jeg overvejet, men så får jeg en del nestede if's og jeg har været ude for situationen (som du påpejer) hvor det ikke var en løsning.

Men bruger jeg isset() korrekt i det 2. eksempel jeg kom med ?

I mit tilfælde kommer $a og $b dom OPST/GET og jeg er ikke sikker på at $c er sat.

sone: Hvis der ikke tjekkes med isset()/empty(), så brokker PHP sig under E_ALL.

Jeg mener stadig du skal bruge isset i toppen. Det er en rent teknisk ting, og
du bør ikke lade din programmeringslogik afhænge så meget af lige det. Kan du
ikke nøjes med at sætte en variabel til en tom streng, så skal du bare udvide lidt

if (isset($_GET['a']))
  { $a_angivet=true; $a=$_GET['a']; }
else
  { $a_angivet=false; $a=""; }

Så kan du med dine egne variabler se hvilket af de to tilfælde, der er indtruffet.
Her kan $a fx være angivet til at være tom.

Jeg ved ikke om din if-sætning er korrekt, googolplex, men den er simpelthen
for lang til at nogen, mig eller dig om nogle måneder, kan se hvad meningen egentlig er.

erik: Ja, den er alt for lang (!!), det var derfor jeg gerne vil have sat den lidt mere overskueligt op :)

Lad os da prøve. Hvorfor er $c ikke altid defineret, og hvad er det egentlig
der skal ske?

$a og $b kommer som POST/GET. Det er ikke sikkert at de begge er sat.

$c er en regel (regular expression) som muligvis er sat.

Hvorfor er $c ikke nødvendigvis sat? Hvad indeholder den, hvis den er sat,
og hvad bestemmer om og hvad den indeholder. Hvad er logikken i $a og $b?
Under hvilke betingelser skal if-sætningen "udløses"?

Jeg kan ikke læse mig til om du har lavet den rigtigt. Jeg kan ikke gøre
den "smart" uden at vide hvad du skal have beregnet.

Jeg kan godt bare skrive den om - men det er ikke meget fidus i.

$c = $this->mRules[$this->mFields[$counter]['password']['name']] - er muligvis sat via $this->AddRule() og vil så indeholde en regular expression.

$a = $this->mMethod[$this->mFields[$counter]['password']['name']] - indeholder navnet på et password field og vil være sat når formen submittes.

$b = $this->mMethod[$this->mFields[$counter]['confirmation']['name']] - indeholder et navnet på et bekræftigelses password (for at sikre de er ens). Den er muligvis sat, men kun hvis der benyttes to password-felter, hvilket sættes i $this->AddPassword();

Jeg har ikke så meget tid lige nu, men en måde ville måske være at definere et
'altid lovligt' regulæret udtryk, i det tilfælde der ikke er nogle regler. Du vil
fx altid få et 'ja' på

  ereg('.*','hvadsomhelst')

På den måde vil du altid kunne

  if (!ereg($c,$a)) {...}

Når du internt bestemmer om der skal være 1 eller 2 password felter, skal du
ikke lade formens felter afgøre om der er et eller 2. Det bør være

  if ($a!="") { fejl... }
  if (derskalvære2passwords && $a!=$b) { fejl...}
  if (!ereg($c,$a)) { fejl...}

hvor 'derskalvære2passwords' er en aflæsning af din opsætning.

Jeg havde faktisk overvejet den med det regulære udtryk, men var ikke helt sikker på, hvordan jeg defineret 'hvadsomhelst' :)

Skal der ikke være en delimiter som fx. '/.*/' eller er det kun i Javascript ? Er '^$' ikke også hvadsomhelst ?

Hvis du vil have point så læg et svar ;) Men ellers så takker jeg mange gange for hjælpen!!!

delimiters bruges i Perl-kompatible regexp. ereg() laver en POSIX-kompatibel regexp.

"^$" er en begyndelse og en slutning uden noget imellem. Så den matcher ikke på hvadsomhelst, men kun på en tom streng.

Ok, men hvorfor bruger man så delimeters i Javascript ? Jeg fik af vide, at javascript bruger POSIX-kompatibel regex ??

Aner det ikke.

Uden at være sikker mener jeg dog at Javascripts regex minder mere om Perlkompatible end om de POSIX. Jeg vil dog ikke hænges op på det, da jeg ikke har beskæftiget med med Javascript.

Æb bæv, jeg troede jeg kunne bruge det samme regex til både ereg (eller preg_match) og Javascript, men der er åbenbart forskel på dem alle 3 :(

Du kan sagtens holde dig indenfor samme valide reg-exps i alle 3. Nemmest med preg_-funktionerne.

erik: Det lyder rigtig dejligt, jeg vil nemlig helst bruge preg_match(), men det troede jeg ikke jeg kunne.

Hvordan griber jeg det bedst an, når jeg skal lave regex's der virker både serverside og clientside. Det problem er virkelig min store hovedpine ligenu !!

Findes der en bog eller lignende eller en tutorial ?

Jeg har endnu ikke skrevet (eller fundet) den ultimative bog eller tutorial
om regulære udtryk. Men spørg.

Ok, det vil jeg så gøre!

Tillader at give lars pointene, da jeg ved du ikke samler på dem :)