PHP·pub - Programming With Attitude - and beer

[Garanti]

Ok, fant et litt mer oversiktlig eksempel her(no offence ) Går det an å benytte seg av dette i forms da?

Eksempelvis

<input type="file" name="array[frukt][eple]"
<input type="file" name="array[frukt][pære]"
<input type="file" name="array[frukt][mango]"
<input type="file" name="array[grønnsak][palme]"
<input type="file" name="array[grønnsak][furu]"
<input type="file" name="array[grønnsak][osp]"

[Martin A.]

Bare å teste det.

 

Gjør input om til text, og fyll inn noe random crap i feltene, og kjør en print_r() på $_POST['array'];

[Garanti]

Jøss, jeg var ikke klar over hvilke underverker <pre>-tag'en kunne gjøre

[Peter]

Skal vi dra ned nivået på denne tråden også nå?

Kan ikke folk opprette tråder for hjelp slik det er meningen at de skal gjøre?

[Garanti]

Joda, skal gjøre det neste gang.

[Rabbid]

Hmm, tenker på å porte et av prosjektene mine fra PHP til Python, er det noen som har noen argumenter for å _ikke_ gjøre dette?

 

NB: Har ikke tenkt å bruke Django, skal bare porte den "direkte" med mod_python (Python Server Pages eller Publisher handler).

Spør her siden dere kanskje har noen fordeler for PHP ovenfor Python (?)

Endret 27. mars 2008 av Rabbid

[Ernie]

Mulig det er en brannfakkel det her, men jeg tror det er få argumenter mot å gjøre det. Jeg kan ikke komme på en eneste fordel med PHP utover at det er utbredt, men det er kanskje ikke et problem? Derimot så tror jeg Python har en fordel i forhold til PHP:

• Unicode/i18n. UTF8 komplett umulig å få ordentlig til i PHP uten mbstring, og selv da har man problemer. Mbstring er forøvrig noe ordentlig herk som godtar blant annet totalt ugyldige bytesekvenser. Python har såvidt jeg kan se innbygget støtte for unicode og i18n kan høyst sannsynligvis gjøres mye, mye bedre i Python enn PHP.
  
• Python har endel flere høynivå-datastrukturer.
  
• Python yter muligens bedre enn PHP (uten at jeg har noe mer håndfast enn litt rykter på nettet)
  
• PHP mangler namespaces (som riktignok kommer «snart» til PHP)
  

De som kan både Python og PHP kan garantert liste opp mer, men det er det jeg sånn kjapt kan liste opp uten særlig kjennskap til Python.

[loathsome]

Python har kulere navn

[Peter]

Hmm, tenker på å porte et av prosjektene mine fra PHP til Python, er det noen som har noen argumenter for å _ikke_ gjøre dette?

 

NB: Har ikke tenkt å bruke Django, skal bare porte den "direkte" med mod_python (Python Server Pages eller Publisher handler).

Spør her siden dere kanskje har noen fordeler for PHP ovenfor Python (?)

Jeg snur på flisa og spør hvorfor du vil bytte?

Dersom du har noen GRUNN til å bytte til Python, er det vel bare å sette igang, men dersom du bare har "lyst" så burde du vel vurdere verdien i det.

Er heller ingen ting som sier at du ikke kan få de to til å samarbeide så kan du gjøre en trinnvis portering.

[Rabbid]

Er heller ingen ting som sier at du ikke kan få de to til å samarbeide så kan du gjøre en trinnvis portering.

Den største grunnen er faktisk noe så overfladisk som at jeg syns Python-kode ser penere ut, liker kodestilen. Har ikke så mange store grunner utenom det, men skal ikke påstå at jeg ikke har blitt påvirket av Django-hype og lignende fenomener.

 

Men hvordan kan jeg få dem til å samarbeide? Ble litt nysgjerrig på hva du mener her

Endret 28. mars 2008 av Rabbid

[Garanti]

Noen som vet om en god side/artikkel for grunnleggende innføring i regulære uttrykk / preg_*?

[MC2]

Noen som vet om en god side/artikkel for grunnleggende innføring i regulære uttrykk / preg_*?

Har denne bookmarked: http://www.ilovejackdaniels.com/regular_ex...cheat_sheet.png

[endrebjo]

Jeg liker veldig godt http://www.regular-expressions.info/

[Peter]

Er heller ingen ting som sier at du ikke kan få de to til å samarbeide så kan du gjøre en trinnvis portering.

Den største grunnen er faktisk noe så overfladisk som at jeg syns Python-kode ser penere ut, liker kodestilen. Har ikke så mange store grunner utenom det, men skal ikke påstå at jeg ikke har blitt påvirket av Django-hype og lignende fenomener.

 

Men hvordan kan jeg få dem til å samarbeide? Ble litt nysgjerrig på hva du mener her

Personlig ville jeg valgt ruby/rails dersom jeg skulle begynt på noe nytt, men jeg har ikke planer om å skrive om gammel kodebase. Når jeg sier samarbeide mener jeg bare at nye ting kan skrives i django, mens du kan la det gamle som ikke skal endres være i PHP.

[Rabbid]

Når jeg sier samarbeide mener jeg bare at nye ting kan skrives i django, mens du kan la det gamle som ikke skal endres være i PHP.

Ja, men hvordan får jeg PHP og Python til å jobbe sammen? De kan vel ikke dele funksjoner/variabler, så da er det like godt å bare skrive om hele greia?

[dabear]

Når jeg sier samarbeide mener jeg bare at nye ting kan skrives i django, mens du kan la det gamle som ikke skal endres være i PHP.

Ja, men hvordan får jeg PHP og Python til å jobbe sammen? De kan vel ikke dele funksjoner/variabler, så da er det like godt å bare skrive om hele greia?

Svaret jeg ville gitt her, måtte bli noe sånt som å reimplementere sesjonshåndteringa i php til å bruke en database, og så i python hente ut og endre data fra den samme databasen. Eventuelt kode sesjoner med json_encode/decode, legge til fil og så hente å bearbeide dette fra python igjen.

[PHPdude]

Noen som vet om en god side/artikkel for grunnleggende innføring i regulære uttrykk / preg_*?

 

Kanskje ikke den beste for skjønne det aller mest grunnleggende, men fra de nest laveste trinnene til de nest høyste trinnene passer de bra.

Det heter ikke Perl-Compatible Regular Expression (PCRE) for ingenting.

 

http://perldoc.perl.org/index-tutorials.html

http://perldoc.perl.org/perlrequick.html

http://perldoc.perl.org/perlretut.html

[Ernie]

Jeg må si jeg er mektig imponert over hvor dårlig UTF8 (alt annet enn ISO-8859-1 & co også forsåvidt) funker i PHP. Som forventet fungerer såklart ikke str-funksjonene i det heltatt til noe annet enn 8bits tegnsett, men det bør jo ikke komme som noe stort sjokk. Det som er verre er at mbstring, som skal gi støtte til andre tegnsett, ikke akkurat imponerer. Hvis man ser bort fra den store manglen på funksjoner (hvor er f.eks *sort, *trim, strcasecmp, str_ireplace, ucfirst, ucwords, wordwrap ++?) har man noe så alvorlig som at de få som finnes ikke oppfører seg likt som str-funksjonene. F.eks: Sender man en offset som er større enn lengden på strengen til mb_substr får du en tom streng tilbake. Gjør du det med substr får du false. Det er udokumenterte forskjeller og er grenseløst irriterende når mbstring overload-er str-funksjonene. Riktignok er slike forskjeller stort sett ubetydelig. Verre er det dog at f.eks 2. parameter i strrchr og mb_strrchr tolkes forskjellig. Er det en int vil strrchr gjøre det om til et tegn, men det skjer jo ikke hvis man bruker mb_strrchr. Hva fanden skal man med overloading hvis ting ikke oppfører seg likt? Greit nok, det er jo mildt sagt klønete oppførsel i utgangspunktet, men når ting overload-er så forventer jeg at ting oppfører seg likt. Den gang ei

 

Nei, det skal bli deilig å kunne slenge alt eldre enn PHP6 rett i søpla, men det tar vel typisk nok litt tid. Dvs. det kommer til å ta litt tid, og vi får vel typisk nok ikke unicode_semantics=on pr. default (kan riktignok settes pr. req.) siden det vil ødelegge for behandling av binærdata, og det er hvis det i det heltatt kommer til å fungere. Skulle det siste ikke stemmer kan det jo ta litt tid før vi får PHP6 i det heltatt, siden jeg aldri i verden kommer til å tro at webhostene frivillig ødlegge for app. som behandler binærdata. Innen det skjer forblir i18n et vanvittig mareritt å gjennomføre i PHP. Bare tenk på sortering f.eks. v og w skulle inntil 2005 sorteres likt på svensk, y skal plasseres mellom i og j på litausk (og mellom i og y igjen finner man į ), ch teller som et tegn og skal mellom c og d på spansk osv. Har man UTF8-versjonen av «locale» for språket installert kan man jo såklart ha litt flaks og få noe fungerende ut av det, men ellers er det ganske «doomed». Enda verre blir det jo når man skal bruke UTF16 eller andre multibyte tegnsett. Bare det faktum at PHP ikke engang klarer å kjøre script lagret som UTF16 sier jo egentlig sitt (igjen, ikke noe sjokkerende siden PHP bare støtter ASCII-tegnsett).

 

Red.: Jo, også sier jo manualen at hvis 2. parameter i strrchr består av flere tegn brukes bare det første. Hva skjer i mb_strrchr? Jo, hele strengen brukes.

Endret 3. april 2008 av Ernie

[Ernie]

Noen som veit om mbstring implementerer «full case mapping» eller «simple case mapping» av unicode? Jeg tror det skal være «simple case» (ut fra kildekoden ser det slik ut iallfall), men for de tegnene jeg testet det på (for å finne ut hva realiteten er) skjer det absolutt ingenting. Da tenkte jeg at jeg måtte teste ut om den faktisk endrer case på litt «sære» tegn (f.eks Dž som skal bli til DŽ og dž), og det skjer da heller ikke. Dokumentasjonen tilsier at mbstring driter i locale-settings, og da skulle det faktisk skje endring ved bruk av mb_convert_case og mb_strtoupper/mb_strtolower, men det gjør det altså ikke. Noen tanker?

 

 

<?php
echo '<pre>';
echo "Upper case: \xC7\x84\n";
echo "Title case: \xC7\x85\n";
echo "Lower case: \xC7\x86\n";
$str = "\xC7\x85";
//$str = "\xE1\xBE\x88";
$up = mb_convert_case($str, MB_CASE_UPPER, 'utf-8');
$down = mb_convert_case($str, MB_CASE_LOWER, 'utf-8');
echo "Org.:\n";
var_dump($str);
var_dump(ord($str{0}).'|'.ord($str{1}));//.'|'.ord($str{2}));
echo "Upper case:\n";
var_dump($up);
var_dump(ord($up{0}).'|'.ord($up{1}));//.'|'.ord($up{2}));
echo "Lower case:\n";
var_dump($down);
var_dump(ord($down{0}).'|'.ord($down{1}));//.'|'.ord($down{2}));
echo '</pre>';
?>

 

Hos meg returnerer det

 

Upper case: DŽ

Title case: Dž

Lower case: dž

Org.:

string(2) "Dž"

string(7) "199|133"

Upper case:

string(2) "Dž"

string(7) "199|133"

Lower case:

string(2) "Dž"

string(7) "199|133"

 

hvilket er feil.

 

Det jeg forventer er

 

Upper case: DŽ

Title case: Dž

Lower case: dž

Org.:

string(2) "Dž"

string(7) "199|133"

Upper case:

string(2) "DŽ"

string(7) "199|132"

Lower case:

string(2) "dž"

string(7) "199|134"

 

Red.: Å så flott. «Title case» blir ikke gjort om til «lower case» og «upper case» stikk i strid med unicode-standarden (Dvs. iallfall ikke for det tegnet.)

Endret 5. april 2008 av Ernie

[ostov]

Heisann! Har nettop begynt med php. Har gjort litt programmering for lenge siden. Har ikke planer om å bli verdens beste, men utrolig greit å kunne litt php. Anyway, kjører wamp sånn at jeg kan få testet det hele, men det ser ikke til å fungere som jeg ønsker. Dette er scripts fra en tutorial

 

Som dere sikkert skjønner så er dette et ganske simpelt script, men problemet er at jeg i en periode fikk godkjent passordet uansett hva det var. Nå får jeg plutselig ikke passordet til å funke, selv om jeg bruker riktig passord. Kan det ha noe med wamp å gjøre eller er det bare meg som har drukket for mye øl?

 

 

ifself.html

<html> 
<head> 
<title>If Statements</title> 
</head> 

<body> 

<h2>Acme Logon Page</h2>

<form method="post" action="http://localhost/scripts/ifelse.php">

<h2>Enter password</h2>

password: <input type="password" name="password"><p>

<input type="submit" value="Submit">

</form> 

</body> 
</html>

 

 

scripts/ifelse.php"

 

<?php

$GoodPasswod = 'acme';

if ($password == $GoodPassword){   
print "<b>Acme Password verified!</b>\n";   
}  
else {	   
print "<b>Acme Password incorrect.</b>\n";   
}

?>

 

 

Jeg har hatt samme problem med et script hvor jeg skal skrive navnet mitt inn så på neste side skal det stå Hi "yourname", men det kommer bare opp Hi. Veldig upersonlig synes jeg da