---

Hej -

Det er ikke fordi jeg leder efter en til <subj.> (selvom det nu kunne være
rart :), jeg er derimod interesseret i at høre hvordan i andre løser alle de
trivielle opgaver der nu engang er ved sådan noget web-udvikling. Jeg tænker
på generering & validering af forms, bruger-validering mv. Desuden også hvad
i måtte bruge af database-klasser og hvordan alle disse ting kombineres uden
at bruge 7 forskellige frameworks.

Har i hver i sær jeres lille framework med alt hvad hjertet begærer, er der
nogen der reelt bruger PEAR - sådan lige ud over database-klassen, eller
koder i virkeligt alt bunden hver gang?

Er meget nysgerrig :)
På forhånd tak!

--
Mvh./Best Regards
Jonas Delfs, http://delfs.dk

---

"Jonas Delfs" <jonas@NOSPAM.delfs.dk> writes:

> Har i hver i sær jeres lille framework med alt hvad hjertet begærer, er der
> nogen der reelt bruger PEAR - sådan lige ud over database-klassen, eller
> koder i virkeligt alt bunden hver gang?

Jeg starter forfra hver gang jeg går i gang med et nyt hyggeprojekt.
Det er ikke optimalt, men jeg har endnu ikke lavet noget der var så
generelt og godt, at jeg følte jeg kunne genbruge det.

--
Med venlig hilsen
- Jacob Atzen

---

Jonas Delfs wrote:
>
> Har i hver i sær jeres lille framework med alt hvad hjertet begærer, er
> der nogen der reelt bruger PEAR - sådan lige ud over database-klassen,
> eller koder i virkeligt alt bunden hver gang?

Jeg plejer at kode det fra bunden hver gang (undtagen databaseklassen - dér
bruger jeg altid PEAR DB) - men dit indlæg har igen givet mig lyst til at
lave et fundament, jeg kan genbruge til forskellige projekter. Jeg har
været i gang med det før, men måtte henlægge projektet på grund af andre
projekter.

PEAR (udover DB) bruger jeg - men ikke til generelle ting. PEAR indeholder
lige nu ikke så meget, som jeg kan bruge til hvert eneste projekt - men der
er helt klart mange nyttige klasser, man kan bruge til mere specialiserede
formål.

--
Jonas Koch Bentzen

---

"Jonas Delfs" <jonas@NOSPAM.delfs.dk> wrote in message
news:asb6gd$c74$1@sunsite.dk...

> Det er ikke fordi jeg leder efter en til <subj.> (selvom det nu kunne være
> rart :), jeg er derimod interesseret i at høre hvordan i andre løser alle
de
> trivielle opgaver der nu engang er ved sådan noget web-udvikling. Jeg
tænker
> på generering & validering af forms, bruger-validering mv. Desuden også
hvad
> i måtte bruge af database-klasser og hvordan alle disse ting kombineres
uden
> at bruge 7 forskellige frameworks.

I arbejdsmæssig sammenhæng har jeg standardklasser til fejlhåndtering,
formgenering og validering, brugerstyring, templates, betaling, logging osv.
Som databaseabstraktionslag benyttes PEAR, selvom dataadgang i reglen er
indkapslet i andre klasser, i forbindelse med brugere og ellers.

/A

---

"Anders Johannsen" <anders@johannsen.com> wrote in
news:u4qG9.49619$HU.3494525@news010.worldonline.dk:

> I arbejdsm‘ssig sammenh‘ng har jeg standardklasser til fejlh†ndtering,
> formgenering og validering, brugerstyring, templates, betaling,
> logging osv. Som databaseabstraktionslag benyttes PEAR, selvom
> dataadgang i reglen er indkapslet i andre klasser, i forbindelse med
> brugere og ellers.

Nu blev jeg så osse lige nysgerrig...

Hvordan ser en klasse til formgenerering og templates ud? Jeg har selv
sådan nogle men har måttet sande at min måde at skrive PHP på nok ikke er
verdens mest effektive - der er alt for mange funktionskald blandet ind
(laaangsomt).

Min form-klasse er i bund og grund bare en ting hvor man kan sætte action-
url og tilføje ting (jeg har funktioner til at lave forskellige input-
felter). Metoden $form->create() gør det indlysende :)

Template-klassen baserer sig på en HTML-template, hvor jeg har defineret
nogle huller (f.eks. [>INDHOLD<]), og så har den en metode til at tilføje
noget tekst til et givent hul ($template->add("INDHOLD", "blabla")).

Derudover har jeg klasser og funktioner til stort set alt andet osse...
HTML-tabeller er f.eks. osse en klasse hvor man kan tilføje rækker, sætte
bredder og styles mv. Faktisk står der _udelukkende_ PHP i min .php-filer,
og det er nok der jeg brænder nallerne mht. udførelsestid - al HTML bliver
genereret af kald til den ene eller anden funktion/metode.

Til gengæld kan jeg fuldstændig ændre udseendet af et site ved at rette
HTML-template og stylesheet...

Hyggehej
/Thomas

---

"Thomas Lindgaard" <thomas@it-snedkeren.BLACK_HOLE.dk> wrote in message
news:Xns92D813B971A28thomasitsnedkerendk@62.243.74.162...

> Hvordan ser en klasse til formgenerering og templates ud? Jeg har selv
> sådan nogle men har måttet sande at min måde at skrive PHP på nok ikke er
> verdens mest effektive - der er alt for mange funktionskald blandet ind
> (laaangsomt).

Baserer du det på praktiske erfaringer? Det er naturligvis indlysende, at
det udfra et rent ydelsesmæssigt synspunkt er langsommere at kalde en
funktion end at have koden stående direkte, men fordelene ved at kunne
strukturere koden opvejer ulemperne i en sådan grad, at jeg end ikke ville
overveje at optimere af denne vej.

> Min form-klasse er i bund og grund bare en ting hvor man kan sætte
action-
> url og tilføje ting (jeg har funktioner til at lave forskellige input-
> felter). Metoden $form->create() gør det indlysende :)

Den jeg bruger har et lignende princip, dog således at hvert enkelt
formelement har sin egen klasse. Her er et forsimplet eksempel

$def = array();
$def['username'] = new new Form_Text('Ønsket brugernavn', array('minlength'
=> 3, 'maxlength' => 30,'size' => 12));
$def['email'] = new Form_Text('Email adresse', array('match' =>
FORM_MATCH_EMAIL, 'matcherrormessage' => 'er ikke en gyldig
email-adresse'));
$def['birthday'] = new Form_Date('Fødselsdag', array('value' => FALSE,
'yearstart' => (int)date('Y')-100, 'yearend' => (int)date('Y')));
$def['submit'] = new Form_Submit('Påbegynd medlemskab');

$form = new Form_Generator('signup', $def);

if ($form->submitted && form->valid) {

} else {
print $form->getHTMLTable();
}

Ovenstående kode håndterer javascript-validering, serverside-validering,
udskrivning af form og udskrivning af fejlmeddelser.

/A

---

"Anders Johannsen" <anders@johannsen.com> wrote in
news:%4QG9.54748$HU.3654263@news010.worldonline.dk:

>> Hvordan ser en klasse til formgenerering og templates ud? Jeg har
>> selv sådan nogle men har måttet sande at min måde at skrive PHP på
>> nok ikke er verdens mest effektive - der er alt for mange
>> funktionskald blandet ind (laaangsomt).
>
> Baserer du det på praktiske erfaringer? Det er naturligvis indlysende,
> at det udfra et rent ydelsesmæssigt synspunkt er langsommere at kalde
> en funktion end at have koden stående direkte, men fordelene ved at
> kunne strukturere koden opvejer ulemperne i en sådan grad, at jeg end
> ikke ville overveje at optimere af denne vej.

Jeg har kodet et webinterface til et system, hvor alt bliver genereret af
funktioner og metodekald. Dette er der nu en anden der har overtaget, og
han har lavet lidt test. Han har omskrevet noget af det til en blanding
af HTML og PHP og skåret kraftigt ned på antallet af smarte funktioner,
og faktum er at en side nu bliver genereret på 20 msek imod 150 msek
tidligere...

.... om det så er min klyt-kode eller antallet af funktionskald ved jeg
ikke helt - men meget af tiden tror jeg skal hentes i mit template-
system, som bruger en del reg.exp., konkateneringer og str_replace.

> Den jeg bruger har et lignende princip, dog således at hvert enkelt
> formelement har sin egen klasse. Her er et forsimplet eksempel

<snip kode>

> Ovenstående kode håndterer javascript-validering,
> serverside-validering, udskrivning af form og udskrivning af
> fejlmeddelser.

Det ser <word type="bandeord" /> meget lækkert ud det dér kode :)

Er det noget med at kaldet til Form_Generator sætter $form->submitted =
true hvis $_POST indeholder submit-knappen og så validerer og sætter
$form->valid, eller også skriver formen ud som en pæn tabelformatteret
ting?

/Thomas

---

"Anders Johannsen" <anders@johannsen.com> skrev i en meddelelse
news:u4qG9.49619$HU.3494525@news010.worldonline.dk...

> I arbejdsmæssig sammenhæng har jeg standardklasser til fejlhåndtering,
> formgenering og validering, brugerstyring, templates, betaling, logging
osv.

Nu ved jeg ikke om "I arbejdsmæssig sammenhæng" forhindrer dette, men
specielt klasser til fejlhåndtering, brugerstyring og logging kunne jeg godt
tænke mig at se/høre nærmere om.
Hvis ikke det er noget som kan gøres tilgængeligt, vil jeg meget gerne at du
forklarer hvorledes de fungerer.

--
Mvh./Best Regards
Jonas Delfs, http://delfs.dk

---

Jonas Delfs wrote:
> Har i hver i sær jeres lille framework med alt hvad hjertet begærer, er
> der nogen der reelt bruger PEAR - sådan lige ud over database-klassen,
> eller koder i virkeligt alt bunden hver gang?

Jeg har lavet en form processor, som efterhånden har sparet mig en del tid
med netop trivielle opgaver. Udgangspunktet for udviklingen var, at jeg
ville definere min form én gang, hvorefter denne def. skulle danne
udgangspunkt for form generering, validering, opdatering af db, listning
etc. etc.

Indtil videre foregår det via multidim. arrays, men det var planen en dag at
lave det i xml. Jeg definerer tre arrays - en vedr. forbindelsen til db'en,
selve formen, samt formens felter

$dbDef = array("dbTable" => "adresser",
"dbPrimKeyName" => "adresseID");

$formDef = array("submitValue" => "Gem adresse!");

$fieldDef = array(array("name" => "name",
"label" => "Navn"),
array("name" => "postnr",
"label" => "Post nr."
"regexp" => "[[\d]{4}]),
"error" => "indtast postnr!!!")
array("name"=>"category",
"label" => "Kategorier",
"type" => "multiple",
"min"=>1,
"max"=>100,
"optTable" => "categories",
"optTableFields"=>array("categoryID","navn"),
"relTable" => "adresserTyperRel",
"relTableFields" =>array("adresseID","typeID")));

Ideén er så at information vedr. hvert felt skal bruges i alle faser.
Definition kan skæres meget ned ved at bruge default værdier - eks. er
typen ofte text og regexp ofte [[:alnum:]]{1,80} osv. Endvidere kan man
lave intelligente fejlmeddelser, som udfra min og max, samt type kan
sammensætte en læselig fejl meddelse.

Definition af 'category' er et eks. på hvorledes et felt er knyttet til en
tabel med nogle mulige værdier (optTable) samt en table med relationerne -
altså en mange-til-mange relation. Netop automatiseringen at denne del har
sparet rigtig mange timer. Når definition kendes, er det så blot at kalde
to linjer.

$myForm = new formProcessor($formDef,$fieldDef,$dbDef);
$myForm->procesForm();

--
mvh Jakob Kirkegaard
-> http://jakir.dk

---

"Jakob Kirkegaard" <jkir00@control.auc.dk> skrev i en meddelelse
news:askr7e$aut$1@sunsite.dk...

> Jeg har lavet en form processor, som efterhånden har sparet mig en del tid
> med netop trivielle opgaver. Udgangspunktet for udviklingen var, at jeg
> ville definere min form én gang, hvorefter denne def. skulle danne
> udgangspunkt for form generering, validering, opdatering af db, listning
> etc. etc.

Specielt de 2 sidstnævnte ting interesserer mig. Mon man kunne få lov at
se/høre nærmere?

> $dbDef = array("dbTable" => "adresser",
> "dbPrimKeyName" => "adresseID");

Du kan næppe lave en database-connection på baggrund af ovenstående - hvor
kommer resten fra?

> $formDef = array("submitValue" => "Gem adresse!");

Hvilken form giver det?

<snip kode>

> Definition af 'category' er et eks. på hvorledes et felt er knyttet til en
> tabel med nogle mulige værdier (optTable) samt en table med relationerne -
> altså en mange-til-mange relation. Netop automatiseringen at denne del har
> sparet rigtig mange timer.

Det finder jeg ret interessant. Jeg gad godt nok godt se kode?:)

--
Mvh./Best Regards
Jonas Delfs, http://delfs.dk

---

Jonas Delfs wrote:
> "Jakob Kirkegaard" <jkir00@control.auc.dk> skrev i en meddelelse
> news:askr7e$aut$1@sunsite.dk...
>
>> Jeg har lavet en form processor, som efterhånden har sparet mig en del
>> tid med netop trivielle opgaver. Udgangspunktet for udviklingen var, at
>> jeg ville definere min form én gang, hvorefter denne def. skulle danne
>> udgangspunkt for form generering, validering, opdatering af db, listning
>> etc. etc.
>
> Specielt de 2 sidstnævnte ting interesserer mig. Mon man kunne få lov at
> se/høre nærmere?

Koden er blevet skrevet sideløbende med andre projekter, hvorfor udviklingen
ikke har været særlig struktureret, samtidig med at der mangler meget
dokumentation. Den kan dog ses på

http://jakir.dk/formProcessor.phps

Omkring opdatering af db, så er klassen i øjeblikket mysql specifik, men det
var planen benytte et mere generelt interface en dag. Mht. listningen, så
er dette ikke implementeret endnu - ihvertfald ikke på en smart måde ;)

>> $dbDef = array("dbTable" => "adresser",
>> "dbPrimKeyName" => "adresseID");
>
> Du kan næppe lave en database-connection på baggrund af ovenstående - hvor
> kommer resten fra?

Nej, naturligvis ikke. Dette er blot definition af måden hvorpå forbindelse
skal foregå - altså til hvilken tabel etc. Mere generelt kunne man
forestille sig, at der også kun defineres tekst filer eller email adr., som
modtagere af form indholdet.

>> Definition af 'category' er et eks. på hvorledes et felt er knyttet til
>> en tabel med nogle mulige værdier (optTable) samt en table med
>> relationerne - altså en mange-til-mange relation. Netop automatiseringen
>> at denne del har sparet rigtig mange timer.
>
> Det finder jeg ret interessant. Jeg gad godt nok godt se kode?:)

Hvis du ellers kan finde rundt i koden, så drejer det sig om, at
funktionerne getPresetValues (der henter de værdier som skal vises på formen
som udgangspkt.) samt getOptValues (dvs. de mulige værdier der kan vælges i
eks. et select multiple felt.)

--
mvh Jakob Kirkegaard
-> http://jakir.dk

---

On Sat, 30 Nov 2002 21:19:23 +0100, "Jonas Delfs"
<jonas@NOSPAM.delfs.dk> wrote:

>Har i hver i sær jeres lille framework med alt hvad hjertet begærer, er der
>nogen der reelt bruger PEAR - sådan lige ud over database-klassen, eller
>koder i virkeligt alt bunden hver gang?

I PEAR er der en HTML_OOH_Form-klasse.
Den er en videreudvikling af PHPLibs OOHForms (Object Oriented HTML
Forms) som giver mulighed for både serverside og clientside validering
via f.eks regular expressions eller callback-funktioner.

Man kan f.eks også beskrive sin form via XML.

Der findes en Quick Guide til HTML_OOH_Form på
http://www.ulf-wendel.de/schulung/ooh/ - den er dog på tysk.

Jeg brugte (og bruger) PHPLibs OOHForms som jeg er ret glad for.
Jeg udvidede den til at klare datoer og jeg skrev også en udvidelse så
den selv kunne hente/vise/gemme data fra en database. Det hele foregår
ved at rette i lidt kode så det hele tilpasses den givne sides layout,
og selve formularen og dens binding til databasen foregår ved at smide
nogle data i en array.

Det er ikke perfekt og det er muligvis også besværligt at komme i gang
med, men jeg er glad for det og med lidt klippe-klistre så har man
lynhurtigt lavet en formular som viser en given tabels indhold med
mulighed for redigering.

Men siden PEAR nu har en databaseklasse og omtalte HTML_OOH_Forms så
mangler der jo bare at en eller anden sætter sig og skriver noget kode
som binder dem sammen

--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
http://www.gartneriet.dk
- First name: Mads
- The name you typed contains a word or phrase that Hotmail does not allow.

---

"Mads Lie Jensen" <mads@gartneriet.dk> skrev i en meddelelse
news:onruuuod1s7amgsasppqpfar08mivco2bo@4ax.com...
> On Sat, 30 Nov 2002 21:19:23 +0100, "Jonas Delfs"
> <jonas@NOSPAM.delfs.dk> wrote:
>
> >Har i hver i sær jeres lille framework med alt hvad hjertet begærer, er
der
> >nogen der reelt bruger PEAR - sådan lige ud over database-klassen, eller
> >koder i virkeligt alt bunden hver gang?
>
> I PEAR er der en HTML_OOH_Form-klasse.
> Den er en videreudvikling af PHPLibs OOHForms (Object Oriented HTML
> Forms) som giver mulighed for både serverside og clientside validering
> via f.eks regular expressions eller callback-funktioner.

Kender godt OOHForms såvel som HTML_OOH_Form og HTML_Quickform mv.

> Jeg brugte (og bruger) PHPLibs OOHForms som jeg er ret glad for.
> Jeg udvidede den til at klare datoer og jeg skrev også en udvidelse så
> den selv kunne hente/vise/gemme data fra en database. Det hele foregår
> ved at rette i lidt kode så det hele tilpasses den givne sides layout,
> og selve formularen og dens binding til databasen foregår ved at smide
> nogle data i en array.

Jeg mener at huske at OOHForms er ret så "tung"?

> Det er ikke perfekt og det er muligvis også besværligt at komme i gang
> med, men jeg er glad for det og med lidt klippe-klistre så har man
> lynhurtigt lavet en formular som viser en given tabels indhold med
> mulighed for redigering.

Nu kan jeg jo ikke præcist vide hvad du mener med "klippe-klistre", men det
jeg søger er netop noget så fleksibelt at der (i princippet) ikke må være
begrænsninger i det daglige brug - altså at man skal til at editere i
klassen. Ved ikke om det var det du mente.

Egentlig er det også mere sådan et "genbrugeligt fundament" generelt, og
ikke så meget en form-klasse jeg søger. (selvom det altid er spændende med
interessante påfund/nye idéer til forenkling)

--
Mvh./Best Regards
Jonas Delfs, http://delfs.dk

---

On Thu, 5 Dec 2002 19:27:18 +0100, "Jonas Delfs" <jonas@NOSPAM.delfs.dk>
wrote:

>Jeg mener at huske at OOHForms er ret så "tung"?

Tja.. det er nok ikke i den helt lette ende - men jeg syntes ikke det er
specielt tungt.
Det jeg bruger det til er mest et administrationsinterface, dvs. det er
relativt 'lidt' det bliver brugt. Det skal kun i sving når jeg skal
smide noget i databasen eller lign.


>> Det er ikke perfekt og det er muligvis også besværligt at komme i gang
>> med, men jeg er glad for det og med lidt klippe-klistre så har man
>> lynhurtigt lavet en formular som viser en given tabels indhold med
>> mulighed for redigering.
>
>Nu kan jeg jo ikke præcist vide hvad du mener med "klippe-klistre", men det
>jeg søger er netop noget så fleksibelt at der (i princippet) ikke må være
>begrænsninger i det daglige brug - altså at man skal til at editere i
>klassen. Ved ikke om det var det du mente.

Der skal ikke rettes i nogle klasser. Med klippe-klistre mente jeg at
man finder et script frem hvor man har defineret en form, klipper den
definition ud og lige retter navne, feltlængder osv. til. I stedet for
at skulle skrive hele formular-definitionen igen.


--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
http://www.gartneriet.dk
- First name: Mads
- The name you typed contains a word or phrase that Hotmail does not allow.