PHP·pub - Programming With Attitude - and beer

[rødøye]

Zend Framework er eit rammeverk til PHP -- altså en utvidelse av PHP-språket, som forøvrig utvikles av Zend for tiden. Du har sikkert hørt om django, ruby on rails (RoR) og lignende, som er rammeverk til henholdsvis python og ruby. Dette er andre rammeverk -- skrevet i andre språk, og med sine egne tilnærminger på verdens problemer.

 

 

Oppdatert: fikset BBkode

Endret 2. juli 2007 av rødøye

[Gjest Slettet+142]

Google?

http://framework.zend.com/

8987680[/snapback]

Og du tror jeg ikke har besøkt den siden?

 

rødøye:

Så etter hva jeg har skjønt, er det en kompilasjon av mange nye funksjoner som kan være veldig nyttige?

[rødøye]

Nei, her er det funksjoner som er skrevet i ens ærend å utvide og forenkle moderspråket. Altså en samling nye, utvidende funksjoner/metoder.

[Gjest Slettet+142]

Hmm. ok.

Mye å sette seg inn i ser det ut som

[jorgis]

Hvordan er Zend Framework sammenlignet med CodeIgniter?

[Peter]

Hvordan er Zend Framework sammenlignet med CodeIgniter?

8989862[/snapback]

Ikke prøvd noen av delene før nå, men har akkurat begynt å teste litt med ZF, og så langt så virker det enkelt og greit.

[Gjest Slettet-df17e]

Zend Framework har vel et mye større bibliotek med funksjoner enn hva Code Igniter har. Personlig har jeg blitt veldig glad i CI. Har riktignok ikke testet ZF, men CakePHP var for min del alt for stort. CI er lite og veldig fleksiblet. Noe jeg liker!

 

Sikkert noen her med litt mer erfaringer fra begge rammeverkene som kan komme med et litt fyldigere svar

[Gjest Slettet+142]

Har sett mye på de forskjellige bibliotekene Zend tilbyr som jeg kanskje trenger, og det ser litt skremmende ut.

Men samtidig ser det veldig nyttig ut

 

Får ta en bedre titt på det når jeg kommer hjem(reiser imorgen) ifra hytten.

- Prøve ut litt

 

Men mitt very first look er iallefall skremmende.

 

 

Jeg fikk faktisk ikke til å sende mail med Zend_Mail til @hotmail.com-adresse, mens i samme skriptet kom mailen fram til den andre adressen jeg spesifiserte i To-headeren

 

;Mariyo

Endret 5. juli 2007 av Slettet+142

[jorgis]

mariyo: Hotmail har ganske dårlige spamfiltre, som meget mulig kan ha strippet ut din mail, til og med uten å gi brukeren beskjed.

[Gjest Slettet+142]

Skal den ikke da havne i Spam-mappen da?

 

Har erfart meg Hotmail's veldige spamfiltre før. - De er absolutt ikke av den webmaster-vennlige sorten

Endret 5. juli 2007 av Slettet+142

[KiKKA]

Sitter her og koder på et nokså omfattende prosjekt, og lurer på om jeg skal legge inn språk-valg på siden. Funderer litt på hvordan det er vanlig og gjøre dette.

 

Hvordan ville dere gjort det?

 

 

Jeg tenker da på alt fra menyer til nyheter til faq etc.

 

Er det noe lurt å lagre det i database, for så å kjøre en forespørsel for hver minste ting (hver menyknapp ect.)?

 

EDIT. kanskje ikke passende for pub-en?

Endret 12. juli 2007 av KiKKA

[Peter]

gettext

Zend_translate

eller arrays som lastes inn dynamisk (f.eks. filnavn som matcher språk)

[jorgis]

I Vikingboard bruker vi objekter som holder språkstrenger, delt opp etter hvilke seksjoner som bruker strengen (for å unngå å måtte laste masse unødvendige variabler), fordelt i forskjellige filer etter språk (se her for kilde). Språkfilene inkluderes automatisk i kernel.php, og kan deretter hentes enten ved å skape objektet;

$lang = new lang_profile();
echo $lang->profile_invalid_userid;

 

eller i template-motoren;

$screen->set_lang('lang_profile');

// i template:
{if $invalid_userid}<h1>{$lang->profile_invalid_userid}</h1>{endif}

 

Jeg har sett nøye på gettext, men har funnet ut at ulempene (vanskelig distribusjon, trøbbel med locales) er tyngre enn fordelene i hvert fall i øyeblikket. Håper at gettext en dag skal bli inkludert som default i PHP, slik at det er mulig å gjøre seg avhengig av det, selv i applikasjoner som skal distribueres over vidt forskjellige plattformer og oppsett.

Endret 12. juli 2007 av jorgis

[KiKKA]

Har sett litt på VB-løsningen nå. Ser faktisk ut som en god løsning, og noe som kan fungere for meg.

 

Er enig i at gettext ser noe tungvint ut. Tror heller jeg baserer meg på en løsning lik VB.

[Gjest Slettet+142]

Er det en funksjon som gjør det mulig å avslutte skriptet i en fil?

 

fil1.php

PHP

<?php

require_once 'klasse.php';

require_once 'klasse.php';

 

$tekst = new klasse();

echo $tekst;

?>

 

klasse.php

PHP

<?php

if(defined('CLASS_KLASSE')){

// forhindre at skriptet i resten av akkurat denne filen(klasse.php) blir kjørt

}

define('CLASS_KLASSE', true);

 

require_once 'klasse2.php';

class klasse{

// weeee

function __construct(){

 return 'Hello World!';

}

}

?>

 

klasse2.php inneholder da bare en annen klasse som er nødvendig for klassen klasse...

 

Eller noe sånt? Idé noen?

Endret 13. juli 2007 av Slettet+142

[mamaar]

Slik som die()?

Endret 13. juli 2007 av mamaar

[Gjest Slettet+142]

Avslutter ikke die() skriptet som inkluderer klassen også da?

Det jeg vil er at det "ytterste" skriptet som inkluderer klassen skal kunne fortsette å gå, også etter at skriptet i den ene filen er stoppet

[dabear]

PHP

<?php

class ExitScriptException extends Exception{}

 

try

{

    require_once 'foobaz.php';

    

   //dersom  $someConditionIsMet er sann vil exception kastes og ingen

   // kode her vil kjøres. er  $someConditionIsMet ikke sann,

   // vil du kunne kjøre mer kode her

}

catch (ExitScriptException $e)

{

    //kjøres dersom exception er kasta, dvs $someConditionIsMet er sann

    echo $e->getMessage();//outputs "evt spesifisere feilmelding her"

}

 

/* script vil uansett fortsette her, om $someConditionIsMet er sann eller ikke*/

 

 

?>

 

foobaz.php:

PHP

<?php

/* masse kode her*/

 

if($someConditionIsMet)

{

throw new ExitScriptException('evt spesifisere feilmelding her');

}

 

/*

Script vil fortsette som normalt kun viss !$someConditionIsMet

 

*/

 

 

?>

Exceptions

Endret 14. juli 2007 av dabear

[Peter]

Startet som en liten utveksling av tanker i denne

tråden, men for å ikke ødelegge tråden der helt, så tar jeg med ting inn her istedenfor.

 

Vel, over 80% av webhoster kjører fremdeles PHP4, så jeg stiller meg veldig skeptisk til å bytte ut ext/mysql med ext/PDO eller enda et rammeverk å holde styr på i tillegg til mitt eget. Greit nok å gjøre slikt når en drifter egen server, eller spesifikt har valgt å kjøre programvaren på en PHP5-server, men når applikasjonen skal kunne distribueres mellom et utall forskjellige plattformer og oppsett blir det ikke fullt så enkelt å ta i bruk det nyeste nye. Selv SimpleXML er for nytt til at jeg tør å gjøre meg avhengig av det...

9068877[/snapback]

 

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

 

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5. '

Ved å lage programvare som kjører på en versjon som snart ikke støttes mer, gir du webhotellene valget å ikke oppdatere, noe som egentlig er uhørt. Wbhotell som etter tre år fortsatt kjører php4 alene er ikke verdt å satse på, og det burde snart forbrukerene få beskjed om også.

 

Ja, jeg forstår at du vil nå ut til størt mulig kundemasse, men på en annen side så risikerer du ende opp med samme problem som micrsoft og bakoverkompatibilitet.

Nei, jeg tror det beste er å holde programvaren på en plattform som er støttet en god stund fremover. Men det er også viktig å styre litt klar av cutting-edge, ettersom en del webhoteller er treige med å oppdatere(duuh), og php ofte introduserer en del bugs i nye funksjoner.

 

Hvilken versjon av php er den "laveste" du har valgt å støtte, og hvorfor?

[Ernie]

5.1. Det er nok host-er der ut til at de som virkelig vil kjøre scriptet faktisk får gjort det. Til småscript holder jeg meg riktignok til 4.3 siden jeg fort alikevel ikke har bruk for noe mer eller klarer å lage tilsvarende funksjonalitet i PHP4 (f.eks file_put_contents).