From DarkGuardian at uni.de Wed May 7 23:29:33 2003 From: DarkGuardian at uni.de (Frank Marmann) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage Message-ID: <000501c314d7$5ee6e420$244e58d9@dg> Huhu Liste! Ich Arbeite seit längerer Zeit mit IntegratedTemplate. Ich möchte nun aber die Templates aus mehreren Dateien zusammen bauen. Also z.B. aus head.tpl.html und body.tpl.html und footer.tpl.html. Mit IT lässt sich dieses Problem ja scheinbar nicht Lösen. Nun möchte ich wissen ob dies vieleicht mit ITX möglich ist. Die Documentation ist ja zur Zeit nicht verfügbar. Vieleicht hat jemand, wenn mein Problem denn mit ITX Lösbar ist, eine alte oder andere Documentation? Ciao, Frank -- darkguardian@uni.de From ths at 4bconsult.de Wed May 7 23:42:21 2003 From: ths at 4bconsult.de (Thomas Schulz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <000501c314d7$5ee6e420$244e58d9@dg> References: <000501c314d7$5ee6e420$244e58d9@dg> Message-ID: <3EB96FAD.6030209@4bconsult.de> Frank Marmann wrote: > Ich Arbeite seit längerer Zeit mit IntegratedTemplate. Ich möchte nun > aber die Templates aus mehreren Dateien zusammen bauen. Also z.B. aus > head.tpl.html und body.tpl.html und footer.tpl.html. > Nun möchte ich wissen ob dies vieleicht mit ITX möglich ist. http://pear.php.net/manual/en/package.html.html-template-sigma.intro-syntax.p hp HTML_Template_Sigma ist API-compatibel zu IT(X?). ThS. -- Dipl. Ing. Thomas Schulz 4bconsult - Beratung für die Baubranche Engeldamm 22 b - 10179 Berlin büro 030 - 27 59 16 67 fax 030 - 27 59 16 68 http://4bconsult.de From phpml at raschesweb.de Thu May 8 02:01:46 2003 From: phpml at raschesweb.de (Frank Rasche) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <000501c314d7$5ee6e420$244e58d9@dg> References: <000501c314d7$5ee6e420$244e58d9@dg> Message-ID: <132740351.20030508010146@raschesweb.de> Hallo Frank, Frank Marmann schrieb am Mittwoch, 7. Mai 2003 um 22:29: > Ich Arbeite seit längerer Zeit mit IntegratedTemplate. Ich möchte nun > aber die Templates aus mehreren Dateien zusammen bauen. Also z.B. aus > head.tpl.html und body.tpl.html und footer.tpl.html. Mit IT lässt sich > dieses Problem ja scheinbar nicht Lösen. Mal davon abgesehen, dass sich HTMLTemplate_Sigma nicht schlecht anhört (habs noch nicht ausprobiert), warum sollten Templates aus mehreren Dateien nicht funktionieren? $tpl = new HTML_Template_IT("./templates"); $tpl->loadTemplatefile("header.tpl.htm", true, true); ... parsen ... $tpl->show(); $tpl->loadTemplatefile("body.tpl.htm", true, true); ... parsen ... $tpl->show(); $tpl->loadTemplatefile("footer.tpl.htm", true, true); ... parsen ... $tpl->show(); usw. funktioniert bei mir einwandfrei. Lass dir die Templates doch mal einzeln ausgeben und schau, ob da nicht irgendwo ein Wurm drin ist. HTH Frank -- Website : http://www.raschesweb.de e-mail : info@raschesweb.de GPG public-key: http://www.raschesweb.de/rasche.asc =================================================== ;-) From j.behrens at imckg.de Thu May 8 14:10:05 2003 From: j.behrens at imckg.de (John Behrens) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <132740351.20030508010146@raschesweb.de> References: <000501c314d7$5ee6e420$244e58d9@dg> <132740351.20030508010146@raschesweb.de> Message-ID: <3EBA3B0D.1050302@imckg.de> ich glaub er meint mehr sowas wie beispiel.tpl TITEL {bau ein metadaten.tpl} .... {BAU ein menüleiste.tpl} ... oder? ich mein da s geht mit ITX aber sicher bin ich mir auchnicht ist IT[x] eigentlich noch aktuell momentan sind mehrere template klassen da oder? ist dieses sigma teil besser als it[x] oder das gleiche iin grün? Frank Rasche wrote: >Hallo Frank, > >Frank Marmann schrieb am Mittwoch, 7. Mai 2003 um 22:29: > > > >>Ich Arbeite seit längerer Zeit mit IntegratedTemplate. Ich möchte nun >>aber die Templates aus mehreren Dateien zusammen bauen. Also z.B. aus >>head.tpl.html und body.tpl.html und footer.tpl.html. Mit IT lässt sich >>dieses Problem ja scheinbar nicht Lösen. >> >> > >Mal davon abgesehen, dass sich HTMLTemplate_Sigma nicht schlecht anhört >(habs noch nicht ausprobiert), warum sollten Templates aus mehreren >Dateien nicht funktionieren? > >$tpl = new HTML_Template_IT("./templates"); >$tpl->loadTemplatefile("header.tpl.htm", true, true); >... parsen ... >$tpl->show(); > >$tpl->loadTemplatefile("body.tpl.htm", true, true); >... parsen ... >$tpl->show(); > >$tpl->loadTemplatefile("footer.tpl.htm", true, true); >... parsen ... >$tpl->show(); > >usw. funktioniert bei mir einwandfrei. >Lass dir die Templates doch mal einzeln ausgeben und schau, ob da >nicht irgendwo ein Wurm drin ist. > >HTH Frank > > > -- INTER CONTENT KG Webproducer Harburger Schloßstraße 28 Channel 4 21079 Hamburg j.behrens@imckg.de T 040-767960-4728 ICQ #42974405 From wolff at 21st.de Thu May 8 14:22:48 2003 From: wolff at 21st.de (Markus Wolff) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <3EBA3B0D.1050302@imckg.de> References: <132740351.20030508010146@raschesweb.de> <3EBA3B0D.1050302@imckg.de> Message-ID: <20030508131813.3E2A.WOLFF@21st.de> Am Thu, 08 May 2003 13:10:05 +0200 schrieb John Behrens : > ist IT[x] eigentlich noch aktuell momentan sind mehrere template klassen > da oder? > ist dieses sigma teil besser als it[x] oder das gleiche iin grün? IT[X] ist ebenso aktuell wie Sigma - die unterschiedlichen Klassen sind aus einem Streit zwischen den jeweiligen Maintainern hervorgegangen, die sich nicht darauf einigen konnten, einige Features in IT[X] einzubauen, weil dies die Rückwärtskompatibilität zu bestehenden Anwendungen zerholzt hätte. Als Konsequenz entstand mit Sigma ein konkurrierendes Paket, das zwar das gleiche API abbildet, sich aber in Details im Verhalten von IT[X] unterscheidet. Augenscheinlichster Unterschied ist ein neues Feature, mit dem einmal geparste Templatestrukturen gecached werden, was speziell bei komplexen Templates mit vielen ineinander verschachtelten Blöcken die Ausführgeschwindigkeit drastisch erhöht. CU Markus -- *21st Media* | Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff | Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1 From phpml at raschesweb.de Thu May 8 14:41:17 2003 From: phpml at raschesweb.de (Frank Rasche) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <3EBA3B0D.1050302@imckg.de> References: <000501c314d7$5ee6e420$244e58d9@dg> <132740351.20030508010146@raschesweb.de> <3EBA3B0D.1050302@imckg.de> Message-ID: <1846131820.20030508134117@raschesweb.de> Hallo John, John Behrens schrieb am Donnerstag, 8. Mai 2003 um 13:10: > ich glaub er meint mehr sowas wie > beispiel.tpl > > TITEL > {bau ein metadaten.tpl} > > .... > {BAU ein menüleiste.tpl} > ... > oder? Weiss nicht ob er das meint ;-) > ich mein da s geht mit ITX Ok, ITX::addBlockfile() wäre das wohl. Ich habe das allerdings auch schon mit IT selber gemacht, indem ich via $content = IT::get() einen Block von bspw. metadaten.tpl parse und in die Variable $content übergebe. Anschliessend dann im beispiel.tpl den entsprechenden Block mit $content ersetze. zugegeben etwas umständlicher, allerdings hatte ich damals keine Zeit (und Lust) die fehlende Dokumentation von ITX mir aus dem Source zu holen. ;-) > ist IT[x] eigentlich noch aktuell momentan sind mehrere template klassen > da oder? Schaun mer mal: http://pear.php.net/package-info.php?pacid=108 1.1 stable 2003-03-12 HTML_Template_IT-1.1.tgz schaut recht aktuell aus. > ist dieses sigma teil besser als it[x] oder das gleiche iin grün? http://pear.php.net/package-info.php?pacid=189 "HTML_Template_Sigma implements Integrated Templates API designed by Ulf Wendel" Die API ist kompatibel zu IT, aber wohl auch weiterentwickelt. Die Beschreibung liest sich, als wolle man Smarty nacheifern. (Compiled templates,einfache Funktionen im Template, etc) Bin aber wie gesagt noch nicht zum Testen gekommen. Erfahrungsberichte sind daher willkommen. ;-) Gruss Frank From wolff at 21st.de Thu May 8 14:53:42 2003 From: wolff at 21st.de (Markus Wolff) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <1846131820.20030508134117@raschesweb.de> References: <3EBA3B0D.1050302@imckg.de> <1846131820.20030508134117@raschesweb.de> Message-ID: <20030508134749.3E36.WOLFF@21st.de> Am Thu, 8 May 2003 13:41:17 +0200 schrieb Frank Rasche : > Die API ist kompatibel zu IT, aber wohl auch weiterentwickelt. Die > Beschreibung liest sich, als wolle man Smarty nacheifern. (Compiled > templates,einfache Funktionen im Template, etc) > Bin aber wie gesagt noch nicht zum Testen gekommen. > Erfahrungsberichte sind daher willkommen. ;-) Ja nee, mit Smarty nacheifern ist da nicht viel. AFAIK wandelt Smarty die Templates wirklich in PHP-Code um, während Sigma nur die Struktur des Templates (welche Blöcke/Platzhalter gibt´s und wie sind die Blöcke geschachtelt) serialisiert und diese serialisierte Information in einer Datei zwischenspeichert, um beim nächsten Templateaufruf diese sehr rechenzeitintensive Strukturermittlung nicht wiederholen zu müssen. Merkbare Performancesprünge gibt´s damit aber nur bei sehr komplexen Templates. Ausserdem erlaubt Smarty richtige Kontrollstrukturen in Templates, was mit Sigma und IT[X] ebenfalls nicht geht (zum Glück!!!). Die Funktionen im Template gab´s AFAIR übrigens auch schon bei IT[X], allerdings gab´s hier in der Vergangenheit glaube ich Bugs... Viele Grüße, Markus -- *21st Media* | Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff | Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1 From phpml at raschesweb.de Thu May 8 15:24:19 2003 From: phpml at raschesweb.de (Frank Rasche) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <20030508134749.3E36.WOLFF@21st.de> References: <3EBA3B0D.1050302@imckg.de> <1846131820.20030508134117@raschesweb.de> <20030508134749.3E36.WOLFF@21st.de> Message-ID: <1229118907.20030508142419@raschesweb.de> Hallo Markus, Markus Wolff schrieb am Donnerstag, 8. Mai 2003 um 13:53: > Am Thu, 8 May 2003 13:41:17 +0200 schrieb Frank Rasche : >> Die API ist kompatibel zu IT, aber wohl auch weiterentwickelt. Die >> Beschreibung liest sich, als wolle man Smarty nacheifern. (Compiled >> templates,einfache Funktionen im Template, etc) > Ja nee, mit Smarty nacheifern ist da nicht viel. AFAIK wandelt Smarty > die Templates wirklich in PHP-Code um, während Sigma nur die Struktur > des Templates (welche Blöcke/Platzhalter gibt´s und wie sind die > Blöcke geschachtelt) serialisiert und diese serialisierte Information > in einer Datei zwischenspeichert, um beim nächsten Templateaufruf > diese sehr rechenzeitintensive Strukturermittlung nicht wiederholen zu > müssen. Merkbare Performancesprünge gibt´s damit aber nur bei sehr > komplexen Templates. ok, danke für die Info, habe bisher nur die Beschreibung zu Sigma gelesen und daher wohl die falschen Schlüssen gezogen. Mal schauen wie es sich entwickelt. Grössere Performanceeinbussen habe ich bei IT[x] bislang nicht gehabt, allerdings, soo komplex sind meine Templates auch nicht. (oder die Server sind schnell genug ;-)) Gruss Frank From ths at 4bconsult.de Thu May 8 17:12:59 2003 From: ths at 4bconsult.de (Thomas Schulz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <20030508131813.3E2A.WOLFF@21st.de> References: <132740351.20030508010146@raschesweb.de> <3EBA3B0D.1050302@imckg.de> <20030508131813.3E2A.WOLFF@21st.de> Message-ID: <3EBA65EB.5030707@4bconsult.de> Markus Wolff wrote: > IT[X] ist ebenso aktuell wie Sigma - die unterschiedlichen Klassen > sind aus einem Streit zwischen den jeweiligen Maintainern hervorgegangen, > die sich nicht darauf einigen konnten, einige Features in IT[X] > einzubauen, weil dies die Rückwärtskompatibilität zu bestehenden > Anwendungen zerholzt hätte. Also: es war eher so das: a) man sich erst nicht darauf einigen konnte, einige offene Bugs in IT[X] zu fixen, weil dies in Ausnahmefällen die Rückwärtskompatibilität zu bestehenden Anwendungen gefährdet hätte. b) der IT[X] Maintainer neue Features abgelehnt hat. Zu deutsch: die Jungs waren sich einfach nicht grün ;-) > Als Konsequenz entstand mit Sigma ein konkurrierendes Paket, das zwar > das gleiche API abbildet, sich aber in Details im Verhalten von IT[X] > unterscheidet. Augenscheinlichster Unterschied ist ein neues Feature, > mit dem einmal geparste Templatestrukturen gecached werden, was > speziell bei komplexen Templates mit vielen ineinander verschachtelten > Blöcken die Ausführgeschwindigkeit drastisch erhöht. Weitere Unterschiede sind, dass Sigma ausführlich dokumentiert ist, PEAR's Error Handling unterstützt, Unit Tests dazugehören und es einen Maintainer hat, der sich aktiv um das Paket kümmern kann. ThS. [Persönlich ist mir IT[X] viel zu umständlich, daher: Smarty ;-)] -- Dipl. Ing. Thomas Schulz 4bconsult - Beratung für die Baubranche Engeldamm 22 b - 10179 Berlin büro 030 - 27 59 16 67 fax 030 - 27 59 16 68 http://4bconsult.de From ths at 4bconsult.de Thu May 8 17:17:39 2003 From: ths at 4bconsult.de (Thomas Schulz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <20030508134749.3E36.WOLFF@21st.de> References: <3EBA3B0D.1050302@imckg.de> <1846131820.20030508134117@raschesweb.de> <20030508134749.3E36.WOLFF@21st.de> Message-ID: <3EBA6703.1070804@4bconsult.de> Markus Wolff wrote: > Ausserdem erlaubt Smarty richtige Kontrollstrukturen in Templates, was > mit Sigma und IT[X] ebenfalls nicht geht (zum Glück!!!). Warum "zum Glück" ? -- http://4bconsult.de From ths at 4bconsult.de Thu May 8 21:07:01 2003 From: ths at 4bconsult.de (Thomas Schulz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <005901c12e7c$8a49cf80$77708550@lithium3> References: <3EBA3B0D.1050302@imckg.de> <1846131820.20030508134117@raschesweb.de> <20030508134749.3E36.WOLFF@21st.de> <3EBA6703.1070804@4bconsult.de> <005901c12e7c$8a49cf80$77708550@lithium3> Message-ID: <3EBA9CC5.1030001@4bconsult.de> Andre Gemünd wrote: > Damit hast Du vermutlich den Startschuss für eine weitere Runde der größten > PHP-Template-Debatte gegeben. Oh nein, das war der Kerl mit dem "Zum Glück" ;-) [SCNR] > Es geht um folgendes, eine Template-Engine wurde zu dem Zweck entwickelt den > eigentlichen Inhalt ( Texte, Bilder, HTML etc. ), von der sog. Business > Logic ( PHP, Datenbank, Bedingungen etc. ) zu _trennen_. Smarty trennt Business-Logik/Daten von Ausgabe-Logik/Layout. > Mehr oder minder komplexe Kontrollstrukturen innerhalb der Templates > widersprechen diesem Zweck, eben weil ja die eigentliche Programmierung > nichts in den Templates verloren hat. Ansichtssache. Ich finde das Reduzieren von Templates auf das pure Ersetzen von Platzhaltern erhöht nur den Gesamtaufwand der Entwicklung. Auch IT[X] hat doch Kontrollstrukturen: {form_address_error} Das gleiche in Smarty: {if $form.address.error} {$form.address.error} {/if} Für Loops kann man ähnliches bringen. > Smarty geht ja sogar so weit, das es > eine komplette Mikro-Sprache innerhalb der Templates erlaubt (inklusive > while's, for's, if's, arrays etc), Es gibt {if} und {foreach/section} und die passenden {else}'n. Dass man im Template auf Arrays zugreifen kann, vereinfacht die Programmierung, was man schön am obigen Beispiel sehen kann: {form_address_error} ist ein extra gebauter Platzhalter, {$form.address.error} der Zugriff über ein Array mit allen Formulardaten. Die beiden Beispiele kommen übrigens aus HTML_QuickForm, das ab Version 3 Renderer für Template-Engines unterstützt. Derzeit IT[X]/Sigma und Smarty. Wen es interessiert, der schaue sich die beiden Renderer ITStatic und ArraySmarty (Smarty im CVS) samt den Beispielen it-static und smarty-static an. Der ITStatic-Renderer ist bei nahezu identischem Template weitaus komplexer... > aber genau zu diesem Zweck ist ja PHP > entstanden. Die Frage ist ob wir eine weitere Sprache brauchen, die dann > doch wieder in PHP geparsed wird, welches letztendlich nochmal geparsed > wird.... Schlimmer, sie wird sogar mit PHP zu PHP-Code compiliert... ;-) Aber im Ernst: PHP ist als Template-Engine entstanden, und hat sich zu einer vollwertigen Programmiersprache entwickelt. > der Ansatz von patTemplate (xslt-ähnliche tags, etc) Sowohl patTemplate als auch XSLT bieten Kontrollstrukturen, um die Ausgabe-Logik zu steuern. ThS. -- Dipl. Ing. Thomas Schulz 4bconsult - Beratung für die Baubranche Engeldamm 22 b - 10179 Berlin büro 030 - 27 59 16 67 fax 030 - 27 59 16 68 http://4bconsult.de From andre.gemuend at t-online.de Fri May 9 18:06:21 2003 From: andre.gemuend at t-online.de (=?iso-8859-1?Q?Andre_Gem=FCnd?=) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage References: <3EBA3B0D.1050302@imckg.de> <1846131820.20030508134117@raschesweb.de> <20030508134749.3E36.WOLFF@21st.de> <3EBA6703.1070804@4bconsult.de> <005901c12e7c$8a49cf80$77708550@lithium3> <3EBA9CC5.1030001@4bconsult.de> Message-ID: <005601c3163c$8d3cb280$93e652d9@lithium3> >Ansichtssache. Ich finde das Reduzieren von Templates auf das pure >Ersetzen von Platzhaltern erhöht nur den Gesamtaufwand der Entwicklung. Genau das meinte ich, Ansichtssache! :-) Kontrollstrukturen sind nun einmal Programmierung, und die hat wenn man _wirklich_ trennen will, nichts im Template verloren. In meinen Templates sind lediglich die Blöcke gekennzeichnet, sonst pures HTML. Jede Iteration etc. läuft in den Scripts, nur so ist für mich eine sinnvolle Trennung zu erreichen. Wenn ich eine Bedingung ändern will, dann möchte ich dafür nicht das Template UND das Script ändern, sondern lediglich das Script, das Template bleibt unberührt, weil ich ja nichts am Aussehen, sondern etwas an der Logik ändern möchte. Du hingegen müsstest wahrscheinlich Template UND Script ändern. Zum angeblich erhöhten Gesamtaufwand ist zu sagen, das sich jeder der Deine Templates editieren will, erstmal mit der Smarty-Syntax vertraut machen muss, was für mich entscheidend den Aufwand erhöht. >Aber im Ernst: PHP ist als Template-Engine entstanden, und hat sich zu >einer vollwertigen Programmiersprache entwickelt. Aber wenn wir so weitermachen, entwickeln wir dann bald innerhalb von Smarty eine weitere Sprache? Schönes Wochenende, André From wolff at 21st.de Fri May 9 18:50:19 2003 From: wolff at 21st.de (Markus Wolff) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <005601c3163c$8d3cb280$93e652d9@lithium3> References: <3EBA3B0D.1050302@imckg.de> <1846131820.20030508134117@raschesweb.de> <20030508134749.3E36.WOLFF@21st.de> <3EBA6703.1070804@4bconsult.de> <005901c12e7c$8a49cf80$77708550@lithium3> <3EBA9CC5.1030001@4bconsult.de> <005601c3163c$8d3cb280$93e652d9@lithium3> Message-ID: <3EBBCE3B.2030609@21st.de> Andre Gemünd wrote: >>Ansichtssache. Ich finde das Reduzieren von Templates auf das pure >>Ersetzen von Platzhaltern erhöht nur den Gesamtaufwand der Entwicklung. > > Genau das meinte ich, Ansichtssache! :-) > Kontrollstrukturen sind nun einmal Programmierung, und die hat wenn man > _wirklich_ trennen will, nichts im Template verloren. In meinen Templates > sind lediglich die Blöcke gekennzeichnet, sonst pures HTML. Jede Iteration > etc. läuft in den Scripts, nur so ist für mich eine sinnvolle Trennung zu > erreichen. Ich bin zwar grundsätzlich ein Fan dieser Argumentationsweise, allerdings sind meine Gründe, weiterhin auf totale Trennung zu setzen, in der Realität viel pragmatischer: - Ich bekomme die Layouts von einem Grafiker geliefert, der mit Programmierung nix am Hut hat. Ich gebe ihm eine Liste, welcher Platzhalter was bedeutet und wie die sich wiederholenden Blöcke heissen müssen und fertig ist die Laube - Wenn ein neuer Entwickler mit in´s Team kommt, brauche ich max. 5 Minuten, um ihm die Funktionsweise von IT[X] zu erklären. Simplicity saves time. Time is money. Viele Grüße, Markus From ths at 4bconsult.de Fri May 9 21:59:36 2003 From: ths at 4bconsult.de (Thomas Schulz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] ITX Frage In-Reply-To: <005601c3163c$8d3cb280$93e652d9@lithium3> References: <3EBA3B0D.1050302@imckg.de> <1846131820.20030508134117@raschesweb.de> <20030508134749.3E36.WOLFF@21st.de> <3EBA6703.1070804@4bconsult.de> <005901c12e7c$8a49cf80$77708550@lithium3> <3EBA9CC5.1030001@4bconsult.de> <005601c3163c$8d3cb280$93e652d9@lithium3> Message-ID: <3EBBFA98.6020003@4bconsult.de> Andre Gemünd wrote: > Kontrollstrukturen sind nun einmal Programmierung, und die hat wenn man > _wirklich_ trennen will, nichts im Template verloren. Du trennst in Programmierer und Designer. Ich trenne in Businesslogik/Daten und Ausgabelogik/Layout. Und habe Designer, die bei {if} und {foreach} nicht gleich überfordert zusammenbrechen.. ;-) > In meinen Templates sind lediglich die Blöcke gekennzeichnet, sonst pures > HTML. IT[X] Blöcke sind nichts anderes, als jedesmal individuell vorbereitete Kontrollstrukturen für die Ausgabe. Um das zu folgendem IT[X] Template: ------------------------------------------------------------------------ <- wir sind wieder OnTopic!!! ;-)
{first_name} {last_name}
------------------------------------------------------------------------ äquivalente Smarty-Template zu rendern, reicht in der Businesslogik folgender Code: ------------------------------------------------------------------------ $data = array ( 0 => array('first' => "Mein", 'last'=> "Name"), ... ); $tpl->assign("data", $data); $tpl->display("table.tpl"); ------------------------------------------------------------------------ wobei das Template nur unwesentlich komplexer wird: ------------------------------------------------------------------------ {include file=table_header.tpl} {foreach item=name from=$data} {/foreach}
{$name.first} {$name.last}
------------------------------------------------------------------------ > Jede Iteration etc. läuft in den Scripts, nur so ist für mich eine > sinnvolle Trennung zu erreichen. Bei IT[X] mußt du dich um die Iteration im Template (Block markieren der iteriert werden soll) und im Script kümmern. Das ist zum Teil redundant und erfordert deshalb im Script etwas mehr Code: function toggle($item1, $item2) { static $i = 1; return $i++ % 2? $item1: $item2; } $tpl->setCallbackFunction('bgcolor', 'toggle'); foreach ($data as $name) { $tpl->setVariable(array( 'first_name' => $name[0], 'last_name' => $name[1] )); $tpl->parse('table_row'); } [Beispiel von: http://kuerzer.de/sigma.intro-syntax] > Wenn ich eine Bedingung ändern will, dann möchte ich dafür nicht das > Template UND das Script ändern, sondern lediglich das Script, das Template > bleibt unberührt, weil ich ja nichts am Aussehen, sondern etwas an der Logik > ändern möchte. Eine Bedingung in der Businesslogik änderst du im Script, eine Bedingung fürs Layout (wenn es sinnvoll ist) im Template. Smarty --------script---------------------------- $tpl->assign("errmsg", $error); --------template-------------------------- {if $errmsg} FEHLER:{$errmsg} {/if} IT[X] --------script---------------------------- if(!empty($error)) { $tpl->setVariable("errmsg", $error); $tpl->parse('error_block'); } --------template-------------------------- FEHLER:{errmsg} > Zum angeblich erhöhten Gesamtaufwand ist zu sagen, das sich jeder der Deine > Templates editieren will, erstmal mit der Smarty-Syntax vertraut machen > muss, was für mich entscheidend den Aufwand erhöht. Hält man die Templates frei von Businesslogik, die dort ja nicht hingehört, und beschränkt sich auf einen Funktionsumfang, der dem von IT[X] entspricht, ist der Aufwand für das Erlernens der notwendigen Smarty-Syntax nur unwesentlich höher. Ich würde sagen: 15 statt 5 Minuten bei einem Designer, der schon IT[X]-verblendet ist... ;-) Die holt man aber locker wieder rein, weil man sich das ganze manuelle iterieren und parsen der Blöcke spart und der Code zudem übersichtlicher wird (bitte korrigieren falls ich Blödsinn erzähle). > Aber wenn wir so weitermachen, entwickeln wir dann bald innerhalb von Smarty > eine weitere Sprache? Brauchst Du nicht, gibts schon: http://smarty.php.net/manual/de/language.function.php.php ThS. -- Dipl. Ing. Thomas Schulz 4bconsult - Beratung für die Baubranche Engeldamm 22 b - 10179 Berlin büro 030 - 27 59 16 67 fax 030 - 27 59 16 68 http://4bconsult.de From ralf at in-greece.de Tue May 20 11:51:28 2003 From: ralf at in-greece.de (Ralf Eggert) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? Message-ID: Hallo Liste, nachdem einige meiner Projekte eine Ueberarbeitung benoetigen, moechte ich mich nun einmal in PEAR einarbeiten. Ziel ist es, mir aus den vorhandenen Klassen ein Framework zusammen stellen, auf dessen Basis ich dann fortan meine eigenen Projekte aufbauen moechte. Als erstes suche ich nun die geeigneten Klassen fuer die Basisfunktionalitaet. Welche Klassen koennt ihr fuer folgende Aufgaben empfehlen? Im Vordergrund steht die einfache Wartbarkeit und die Performance. 1. Datenbank - DB oder MDB? Wo liegen die jeweiligen Vor- und Nachteile? - Hat jemand schon DB_DataObject oder DB_QueryTool verwendet? Wenn ja, ist der Einsatz empfehlenswert? 2. Templates - Gibt es brauchbare Alternativen zu HTML_Template_IT? - Wuerdet Ihr eher eine Template Klasse verwenden, die nicht zu PEAR gehoert? 3. Formularverarbeitung - Lohnt der Einsatz von HTML_QuickForm? - Habe bereits mehrmals von HTML_OOH_Form gelesen, finde das Package aber im Package Browser auf der PEAR Website nicht. 4. Caching - Fuer das Cachen ist mir wichtig, dass ich nicht nur den gesamten Output einer Seite, sondern auch einzelne Seitenfragmente (Seitenkopf, Spalte links, Spalte rechts, etc.) unabhaengig voneinander cachen moechte. Zudem moechte ich die Moeglichkeit haben, nach dem Lesen der Cache Dateien noch Veraenderungen vornehmen zu koennen (z.B. fuer Anzeige des eingeloggten Users etc.) - Kommen wir zur entscheidenen Frage: Cache oder Cache_Lite? Natuerlich werde ich die verschiedenen Packages durchtesten bzw. habe auch schon einige in der Mangel. Ich wuerde mich jedoch, trotz der Vielzahl meiner Fragen, ueber ein paar Tipps und Hinweise von Leuten freuen, die schon mehr praktische Erfahrungen mit der einen oder anderen Klasse gesammelt haben. Ich bedanke mich schon einmal fuer eure Kommentare und Tipps. Gruss, Ralf From tobias at schlitt.info Tue May 20 12:10:30 2003 From: tobias at schlitt.info (Tobias Schlitt) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? In-Reply-To: References: Message-ID: <28302.193.150.166.44.1053421830.squirrel@webmail.php-appli cations.de> > Hallo Liste, Hallo Ralf! > nachdem einige meiner Projekte eine Ueberarbeitung benoetigen, moechte > ich mich nun einmal in PEAR einarbeiten. Ziel ist es, mir aus den > vorhandenen Klassen ein Framework zusammen stellen, auf dessen Basis > ich dann fortan meine eigenen Projekte aufbauen moechte. Als erstes > suche ich nun die geeigneten Klassen fuer die Basisfunktionalitaet. Für ein Applicationframework würde ich Horde nehmen: www.horde.org. PEAR soll schließlich kein Farmework sondern eine Klassensammlung sein. > Welche Klassen koennt ihr fuer folgende Aufgaben empfehlen? Im > Vordergrund steht die einfache Wartbarkeit und die Performance. > 1. Datenbank > - DB oder MDB? Wo liegen die jeweiligen Vor- und Nachteile? > - Hat jemand schon DB_DataObject oder DB_QueryTool verwendet? Wenn ja, > ist der Einsatz empfehlenswert? DB oder MDB ist eigentlich latte. IMHO für den Individual-Software-Gebrauch oversized. Wenn Du nur intern entwicklest, solltest Du aus Performance-Gründen auf eine Abstraction verzichten. > 2. Templates > - Gibt es brauchbare Alternativen zu HTML_Template_IT? > - Wuerdet Ihr eher eine Template Klasse verwenden, die nicht zu PEAR > gehoert? IT ist IMHO ausreichend für die meisten Zwecke. Performanter (allerdings wohl auch komplizierter) dürfte Flexy sein. Findest Du auch in PEAR: http://pear.php.net/package-info.php?pacid=111 Ich würde Grundsätzlich Klassen aus PEAR empfehlen. Besonders in Sachen QA wird da im Moment einiges getan und die Qualität der Pakete wird in nächster Zeit weiter zunehmen. > 3. Formularverarbeitung > - Lohnt der Einsatz von HTML_QuickForm? Das kommt IMHO darauf an, wieviel Du mit Forms machst! Für 2-3 einfache Formulare lohnt sich das nicht. Die kannst Du auch im Template basteln. Bei "echten" Anwendungen würde ich sowas jedoch vorziehen. > - Habe bereits mehrmals von HTML_OOH_Form gelesen, finde das Package > aber im Package Browser auf der PEAR Website nicht. Habe bisher nur Quickform benutzt. OO-Form sollte dann dieses hier sein: http://pear.php.net/package-info.php?pacid=157. > 4. Caching > - Fuer das Cachen ist mir wichtig, dass ich nicht nur den gesamten > Output einer Seite, sondern auch einzelne Seitenfragmente (Seitenkopf, > Spalte links, Spalte rechts, etc.) unabhaengig voneinander cachen > moechte. Zudem moechte ich die Moeglichkeit haben, nach dem Lesen der > Cache Dateien noch Veraenderungen vornehmen zu koennen (z.B. fuer > Anzeige des eingeloggten Users etc.) Darin liegt nicht der Sinn eines Caching. Wenn Du erst Daten cachet und dann was darin veränderst (evtl. per Regex) verlierst Du wahrscheinlich mehr Zeit als Du beim caching gewonnen hast. Wenn Du für Header und Footer extra Templates benutzt, sollte aber das Caching hier auch kein Problem sein. > - Kommen wir zur entscheidenen Frage: Cache oder Cache_Lite? Egal! ;) > Natuerlich werde ich die verschiedenen Packages durchtesten bzw. habe > auch schon einige in der Mangel. Ich wuerde mich jedoch, trotz der > Vielzahl meiner Fragen, ueber ein paar Tipps und Hinweise von Leuten > freuen, die schon mehr praktische Erfahrungen mit der einen oder > anderen Klasse gesammelt haben. Hoffe ich konnte helfen! Ein guter Anlaufpunkt ist auch immer pear-dev@lists.php.net. Ausserdem freuen wir uns immer über fähige Entwickler! ;) > Ich bedanke mich schon einmal fuer eure Kommentare und Tipps. Kein Problem! Grüße! Toby -- From pschuster at n-o-g.de Tue May 20 12:15:52 2003 From: pschuster at n-o-g.de (Patrick Schuster) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? In-Reply-To: Message-ID: <004101c31eb0$6be54210$635bfea9@oemcomputer> Hallo Ralf, > [mailto:pear-admin@phpcenter.de] On Behalf Of Ralf Eggert > Subject: [pear] Welche Klassen verwenden? > Welche Klassen koennt ihr fuer folgende Aufgaben empfehlen? > Im Vordergrund steht die einfache Wartbarkeit und die Performance. > > 1. Datenbank > > - DB oder MDB? Wo liegen die jeweiligen Vor- und Nachteile? Hmm, dazu kann ich nicht allzuviel sagen. MDB ist der Merge von DB und Metabase und hat wahrscheinlich noch viel mehr Features als DB, die aber ich zumindest nicht brauche, deswegen benutze ich ausschliesslich DB und bin wunderbar zufrieden damit. Aber ein Wechsel der DB Abstraktion sollte nicht allzu schwierig sein, wenn es Dein Projekt verlangt. > - Hat jemand schon DB_DataObject oder DB_QueryTool verwendet? Wenn ja, > ist der Einsatz empfehlenswert? Hurra. Ich hab beide getestet und bin seitdem bei DB_DataObjects hängen geblieben und hoch zufrieden damit. Verwende ich praktisch in jedem Projekt. Zudem ist die Wartung der Applikation viel leichter geworden, der Code ist irgendwie besser zu lesen und nicht so fehleranfällig. Kann ich nur empfehlen. > 2. Templates > > - Gibt es brauchbare Alternativen zu HTML_Template_IT? Tja, SMARTY natürlich. Oje, jetzt geht wahrscheinlich der Glaubenskrieg wieder los :-) Nein im Ernst, ich benutze Smarty da es die populärste und am besten dokumentierte Engine ist, mit Mailingliste sogar. Bin bis jetzt noch nicht in die Verlegenheit gekommen, dass mit Smarty irgendetwas nicht zu lösen gewesen wäre. Und es macht einfach Spass :-) > - Wuerdet Ihr eher eine Template Klasse verwenden, die nicht zu PEAR > gehoert? Ja :-) Habe mir natürlich die PEAR T-Klassen auch angesehen, aber letztendlich doch zu Smarty gewechselt. Ich schätze das schadet nicht wirklich. Und wenn man eine Engine mal halbwegs beherscht, sollte es auch nicht schwierig sein, mal ein Projekt mit einer PEAR T-Engine durchzuführen. > 3. Formularverarbeitung > > - Lohnt der Einsatz von HTML_QuickForm? Bestimmt, hab ich aber aufgegeben, weil die Kooperation mit Smarty nicht so spannend ist. Benutze jetzt "HTML Forms" (http://www.phpclasses.org/browse.html/package/1.html), weil das ohnehin eines der (meiner Meinung nach) besten Formhandling-Klassen ist und diese zudem Smarty-Plugins beinhaltet und mit Smarty eben dadurch perfekt zusammen arbeitet. > - Habe bereits mehrmals von HTML_OOH_Form gelesen, finde das Package > aber im Package Browser auf der PEAR Website nicht. http://cvs.php.net/cvs.php/pear/HTML_OOH_Form?login=2 > 4. Caching Hab ich noch nie benutzt (*schäm*). Einen schönen Tag noch Tschüss Patrick -- Patrick Schuster | Tel.: ++49-89-93 027 08 net-o-graphic @ Internet Solutions | Fax.: ++49-89-93 93 81 59 = p.rogramming d.esign c.onsulting = | Mobil: ++49-174-86 73 202 Echinger Str. 14a | pschuster@net-o-graphic.com 80805 München | http://www.net-o-graphic.com From smith at backendmedia.com Tue May 20 12:46:08 2003 From: smith at backendmedia.com (Lukas Smith) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? In-Reply-To: <28302.193.150.166.44.1053421830.squirrel@webmail.php-appli cations.de> Message-ID: <003e01c31eb4$a4cb4f80$4d00a8c0@vandal> > From: pear-admin@phpcenter.de [mailto:pear-admin@phpcenter.de] On Behalf > Of Tobias Schlitt > > Welche Klassen koennt ihr fuer folgende Aufgaben empfehlen? Im > > Vordergrund steht die einfache Wartbarkeit und die Performance. > > > 1. Datenbank > > > - DB oder MDB? Wo liegen die jeweiligen Vor- und Nachteile? > > > - Hat jemand schon DB_DataObject oder DB_QueryTool verwendet? Wenn ja, > > ist der Einsatz empfehlenswert? > > DB oder MDB ist eigentlich latte. IMHO für den Individual-Software- > Gebrauch > oversized. Wenn Du nur intern entwicklest, solltest Du aus Performance- > Gründen > auf eine Abstraction verzichten. Also für QueryTool gibt es schon einen Port zu MDB. Für DataObject ist grad einer in Planung. Generell würde ich heute sagen, wenn Datentypenabstraktion und Schemamanagement keine wichtigen Features für das Projekt sind, dann lieber mit DB gehen. DB ist einfach stabiler. Ich plane für MDB auch eine API Schlankheitskur in der näherer Zukunft. > > 2. Templates > > > - Gibt es brauchbare Alternativen zu HTML_Template_IT? > > > - Wuerdet Ihr eher eine Template Klasse verwenden, die nicht zu PEAR > > gehoert? > > IT ist IMHO ausreichend für die meisten Zwecke. Performanter (allerdings > wohl > auch komplizierter) dürfte Flexy sein. Findest Du auch in PEAR: > http://pear.php.net/package-info.php?pacid=111 Jo ich schaue mir auch grad Flexy und Xipe an. Ich hoffe immer noch auf einem Merge der beiden. > > 3. Formularverarbeitung > > > - Lohnt der Einsatz von HTML_QuickForm? > > Das kommt IMHO darauf an, wieviel Du mit Forms machst! Für 2-3 einfache > Formulare lohnt sich das nicht. Die kannst Du auch im Template basteln. > Bei > "echten" Anwendungen würde ich sowas jedoch vorziehen. > > > - Habe bereits mehrmals von HTML_OOH_Form gelesen, finde das Package > > aber im Package Browser auf der PEAR Website nicht. > > Habe bisher nur Quickform benutzt. OO-Form sollte dann dieses hier sein: > http://pear.php.net/package-info.php?pacid=157. Das Paket wird glaube ich grade wieder von den Toten auf erweckt. > > 4. Caching > > > - Fuer das Cachen ist mir wichtig, dass ich nicht nur den gesamten > > Output einer Seite, sondern auch einzelne Seitenfragmente (Seitenkopf, > > Spalte links, Spalte rechts, etc.) unabhaengig voneinander cachen > > moechte. Zudem moechte ich die Moeglichkeit haben, nach dem Lesen der > > Cache Dateien noch Veraenderungen vornehmen zu koennen (z.B. fuer > > Anzeige des eingeloggten Users etc.) > > Darin liegt nicht der Sinn eines Caching. Wenn Du erst Daten cachet und > dann > was darin veränderst (evtl. per Regex) verlierst Du wahrscheinlich mehr > Zeit > als Du beim caching gewonnen hast. > > Wenn Du für Header und Footer extra Templates benutzt, sollte aber das > Caching > hier auch kein Problem sein. Jo das hört sich nach Vergewaltigung des Cachings an. Jedoch es gibt eine Variante wie das Sinn machen könnte und was Du vielleicht auch meinst: Partial Caching D.h. man Cached alles nicht dynamische und lässt beim Rest entsprechende Platzhalter drin, die man dann in einem zweiten Schritt erst ersetzt. > > - Kommen wir zur entscheidenen Frage: Cache oder Cache_Lite? > > Egal! ;) Wenn Cache_lite ausreicht dann Cache_lite. Wenn nein dann Cache. > > Natuerlich werde ich die verschiedenen Packages durchtesten bzw. habe > > auch schon einige in der Mangel. Ich wuerde mich jedoch, trotz der > > Vielzahl meiner Fragen, ueber ein paar Tipps und Hinweise von Leuten > > freuen, die schon mehr praktische Erfahrungen mit der einen oder > > anderen Klasse gesammelt haben. > > Hoffe ich konnte helfen! Ein guter Anlaufpunkt ist auch immer > pear-dev@lists.php.net. Ausserdem freuen wir uns immer über fähige > Entwickler! > ;) User fragen aber an pear-general!!! Gruss, Lukas From tobias at schlitt.info Tue May 20 12:59:46 2003 From: tobias at schlitt.info (Tobias Schlitt) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? In-Reply-To: <003e01c31eb4$a4cb4f80$4d00a8c0@vandal> References: <28302.193.150.166.44.1053421830.squirrel@webmail.php-appli cations.de> <003e01c31eb4$a4cb4f80$4d00a8c0@vandal> Message-ID: <44213.193.150.166.44.1053424786.squirrel@webmail.php-appli cations.de> > Also für QueryTool gibt es schon einen Port zu MDB. Für DataObject ist > grad einer in Planung. Das hört sich sehr gut an! ;) > Generell würde ich heute sagen, wenn Datentypenabstraktion und > Schemamanagement keine wichtigen Features für das Projekt sind, dann > lieber mit DB gehen. DB ist einfach stabiler. IMHO würde ich für Projekte, die nicht unbedingt auf verschiedenste Datenbanken zugreifen auf die Abstraction verzichten. Kostet doch einiges an Performance... > Ich plane für MDB auch eine API Schlankheitskur in der näherer Zukunft. Ebenfalls sehr gut! ;) > Jo ich schaue mir auch grad Flexy und Xipe an. Ich hoffe immer noch auf > einem Merge der beiden. Ist da was in Planung? Habe auf der Liste bisher nix gelesen... Hab ich was übersehen? > Das Paket wird glaube ich grade wieder von den Toten auf erweckt. HTML_Form === OOForm?? > Jo das hört sich nach Vergewaltigung des Cachings an. Jedoch es gibt > eine Variante wie das Sinn machen könnte und was Du vielleicht auch > meinst: > Partial Caching > D.h. man Cached alles nicht dynamische und lässt beim Rest entsprechende > Platzhalter drin, die man dann in einem zweiten Schritt erst ersetzt. Sowas ähnliches mache ich in meinen Projekten. Ich habe ein großes Template, was mir die Seitenstruktur angibt und lasse dieses mit 2-3 kleinen Templates bzw. gecachtem Content füllen. > User fragen aber an pear-general!!! Hast natürlich recht! ;) Grüße! Toby -- From smith at backendmedia.com Tue May 20 13:03:36 2003 From: smith at backendmedia.com (Lukas Smith) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? In-Reply-To: <44213.193.150.166.44.1053424786.squirrel@webmail.php-appli cations.de> Message-ID: <004301c31eb7$15206980$4d00a8c0@vandal> > From: pear-admin@phpcenter.de [mailto:pear-admin@phpcenter.de] On Behalf > Of Tobias Schlitt > IMHO würde ich für Projekte, die nicht unbedingt auf verschiedenste > Datenbanken zugreifen auf die Abstraction verzichten. Kostet doch einiges > an > Performance... Naja, wenn man die Performanceverluste verkraften kann würde ich dennoch zu einer Abstraktionlayer tendieren. Die APIs sind einfach netter und man kann das selbe API Know-How für spätere Projekte einsetzen in den man vielleicht mit einer anderen RDBMS arbeitet. > > Jo ich schaue mir auch grad Flexy und Xipe an. Ich hoffe immer noch auf > > einem Merge der beiden. > > Ist da was in Planung? Habe auf der Liste bisher nix gelesen... Hab ich > was > übersehen? So offizielle sind die Gedanken da hingegen nicht. Aber ich bearbeite Alan ein bisschen :-) > > Das Paket wird glaube ich grade wieder von den Toten auf erweckt. > > HTML_Form === OOForm?? Keine Ahnung .. ich bab von HTML_OOHForm geredet. Gruss, Lukas From alexander.merz at web.de Tue May 20 13:06:45 2003 From: alexander.merz at web.de (Alexander Merz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? References: Message-ID: <3EC9FE35.3080708@web.de> Ralf Eggert wrote: > - DB oder MDB? Wo liegen die jeweiligen Vor- und Nachteile? DB - mehr Datenbanken MDB - höhere Abstraktion (DB-Schemen, bessere BLOB-Handling) MDB ist bis auf Kleinigkeiten mit DB kompatibel, wenn du erstmal auf DB setzt, kannst du später ohne großen Aufwand auf MDB "umschalten". > - Hat jemand schon DB_DataObject oder DB_QueryTool verwendet? Wenn ja, > ist der Einsatz empfehlenswert? Selber noch nicht im ernsthaften Einsatz gehabt, aber die Aussagen in Mailinglisten sind durchgängig positiv. > - Gibt es brauchbare Alternativen zu HTML_Template_IT? Kommt darauf, was du unter brauchbar verstehst bzw. ob du IT damit als unbrauchbar bezeichnest ;-) HTML_Template_Sigma ist IT mit integriertem Parser-Cache. HTML_Template_Xipe/Flexy gehen in Richtung Smarty. > - Wuerdet Ihr eher eine Template Klasse verwenden, die nicht zu PEAR > gehoert? Was die Frage auf "Soll ich Smarty statt den obigen benutzen?" reduziert ;-); persönlich mag ich Smarty nicht, deshalb keine Antwort darauf. > 3. Formularverarbeitung > - Lohnt der Einsatz von HTML_QuickForm? Unbedingt mal eine CVS-Version anschauen! Die Klasse unterstützt jetzt verschiedene Template-Klassen, da macht der Einsatz richtig Spass. > - Habe bereits mehrmals von HTML_OOH_Form gelesen, finde das Package > aber im Package Browser auf der PEAR Website nicht. Entwickelt wird daran, ist aber aufgrund einiger Probleme erstmal nur per CVS erhältlich (AFAIK!) > - Fuer das Cachen ist mir wichtig, dass ich nicht nur den gesamten > Output einer Seite, sondern auch einzelne Seitenfragmente (Seitenkopf, > Spalte links, Spalte rechts, etc.) unabhaengig voneinander cachen > moechte. Zudem moechte ich die Moeglichkeit haben, nach dem Lesen der > Cache Dateien noch Veraenderungen vornehmen zu koennen (z.B. fuer > Anzeige des eingeloggten Users etc.) Und wo ist das Problem, du cachst doch sowieso nicht die ganze Seite? Falls du meinst: ich will die komplette Seite im Cache halten, die kann aber noch einen Platzhalter enthalten; da fällt mir eigentlich nur eine Lösung mit HTML_Template_IT: Im ersten Durchgang Seite wie gewohnt erzeugen, beim IT-Konstruktor aber angeben, das nicht-ersetzte Platzhalten nicht-gelöscht werden sollen. Die Seite im Cache speichern. Beim regulären Seitenaufruf, die Seite aus dem Cache holen und erneut durch IT jagen (der Platzhalter ist ja noch da) und ausliefern. > - Kommen wir zur entscheidenen Frage: Cache oder Cache_Lite? Ein Cache ist sinnlos, wenn er selber mehr Zeit braucht, als er einsparen soll. Kurz: Testen! Ich selbst bevorzuge Cache_Lite, wenn irgendmöglich. From alexander.merz at web.de Tue May 20 13:15:20 2003 From: alexander.merz at web.de (Alexander Merz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? References: <003e01c31eb4$a4cb4f80$4d00a8c0@vandal> Message-ID: <3ECA0038.7060804@web.de> Lukas Smith wrote: > Jo ich schaue mir auch grad Flexy und Xipe an. Ich hoffe immer noch auf > einem Merge der beiden. " HTML_Template_Flexy started it's life as a simplification of HTML_Template_Xipe," > User fragen aber an pear-general!!! da fehlt das ;-) From wolff at 21st.de Tue May 20 13:33:24 2003 From: wolff at 21st.de (Markus Wolff) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? In-Reply-To: <3EC9FE35.3080708@web.de> References: <3EC9FE35.3080708@web.de> Message-ID: <3ECA0474.7040307@21st.de> Alexander Merz wrote: >> - Habe bereits mehrmals von HTML_OOH_Form gelesen, finde das Package >> aber im Package Browser auf der PEAR Website nicht. > > Entwickelt wird daran, ist aber aufgrund einiger Probleme erstmal nur > per CVS erhältlich (AFAIK!) Korrekt. Entsprechender Link wurde ja hier schon geposted. Als zusätzliche Lektüre zum Einstieg empfiehlt sich http://www.ulf-wendel.de/ Die Doku dort bezieht sich auf eine ältere Version, ist aber durchaus noch aktuell und prima zum Einstieg. Nur tunlichst dann die Skripte aus dem PEAR-CVS ziehen und nicht von dieser Site, die Version ist uuuralt ;-) Viele Grüße, Markus From alexander.merz at web.de Tue May 20 13:39:32 2003 From: alexander.merz at web.de (Alexander Merz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? References: <28302.193.150.166.44.1053421830.squirrel@webmail.php-appli cations.de> <003e01c31eb4$a4cb4f80$4d00a8c0@vandal> <44213.193.150.166.44.1053424786.squirrel@webmail.php-appli cations.de> Message-ID: <3ECA05E4.50100@web.de> Tobias Schlitt wrote: > IMHO würde ich für Projekte, die nicht unbedingt auf verschiedenste > Datenbanken zugreifen auf die Abstraction verzichten. Kostet doch einiges an > Performance... Ich habe in den Docs zu DB nicht grundlos geschrieben "An unified API for accessing SQL-databases" - "unified" statt irgendwas mit "abstract". Der großen Vorteil von DB und MDB liegen weniger in der Abstraktion von der verwendeten Datenbank, sondern: - einheitliche Befehle - eine Vielzahl von Hilfsbefehlen wie getRow, getOne etc. - einfache Anwendung - einfache Anbindung für Tools wie DataObjects etc. Du mußt weniger schreiben und weniger nachdenken! Ja, da durch wird das Programm langsamer - aber: die Entwicklung wird schneller! In einem aktuellen Projekt habe ich durch den Einsatz von DB grob geschätzt bereits 2 Entwicklerstunden eingespart. Für den eingesparten Arbeitslohn kannst du in den Webserver einen neuen Speicherriegel hauen, was den ganzen Server beschleunigt und nicht nur eine einzelnes Programm. From ths at 4bconsult.de Tue May 20 15:11:47 2003 From: ths at 4bconsult.de (Thomas Schulz) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? In-Reply-To: References: Message-ID: <3ECA1B83.9020406@4bconsult.de> Ralf Eggert wrote: > 1. Datenbank > > - DB oder MDB? Wo liegen die jeweiligen Vor- und Nachteile? > > - Hat jemand schon DB_DataObject oder DB_QueryTool verwendet? Wenn ja, > ist der Einsatz empfehlenswert? Ich würde mir, gerade wenn du mit wie auch immer geartetene Data Objects arbeiten möchtest, in jedem Fall MDB mal näher anschauen. Die durchaus vorteilhafte aber in der Progammieriung durch die Typwandlungen etwas aufwändigere optionale Metabase-Abstraktion kann man nämlich schön in die Objekte bzw. den QueryBuilder auslagern. > 2. Templates s.u.: Smarty ;-) > 3. Formularverarbeitung > > - Lohnt der Einsatz von HTML_QuickForm? Ja. Das arbeitet ab v3.0 auch prima mit Smarty zusammen. Dazu gibt es 2 Array-Renderer in Quickform mit denen man dynamische (alle Formelemente werden über einen Loop erzeugt) oder statische (manuelles positionieren der Formelemente) Smarty-Templates beschicken kann. Ich bin selbst vor einiger Zeit von OOH_Forms auf Quickform umgestiegen, weil die OOH_Forms nicht mehr so aktiv gepflegt wurden und sie mir persönlich zu komplex waren, um auftretende Bugs im Notfall selbst beseitigen zu können. > 4. Caching > > - Fuer das Cachen ist mir wichtig, dass ich nicht nur den gesamten > Output einer Seite, sondern auch einzelne Seitenfragmente (Seitenkopf, > Spalte links, Spalte rechts, etc.) unabhaengig voneinander cachen > moechte. Zudem moechte ich die Moeglichkeit haben, nach dem Lesen der > Cache Dateien noch Veraenderungen vornehmen zu koennen (z.B. fuer > Anzeige des eingeloggten Users etc.) Das kannst Du alles mit Smarty machen. Insbesondere Insert-Plugins sind hilfreich, wenn man in diesen wiederum mit Templates arbeitet: http://smarty.php.net/manual/de/plugins.inserts.php Hier mal ein Beispiel in Zahlen: http://4bconsult.de/smarty/part_cache.html > - Kommen wir zur entscheidenen Frage: Cache oder Cache_Lite? ...die stellt sich in dem Fall erst, wenn Du noch was nicht Ausgabe-Relevantes zu cachen hast :) ThS. -- Dipl. Ing. Thomas Schulz 4bconsult - Beratung für die Baubranche Engeldamm 22 b - 10179 Berlin büro 030 - 27 59 16 67 fax 030 - 27 59 16 68 http://4bconsult.de From ralf at in-greece.de Wed May 21 17:11:48 2003 From: ralf at in-greece.de (Ralf Eggert) Date: Wed Jul 30 03:31:31 2003 Subject: [pear] Welche Klassen verwenden? References: <3ECA1B83.9020406@4bconsult.de> Message-ID: Hallo Liste, erst einmal vielen Dank fuer die vielen Tipps und Anregungen zu den einzelnen Packages. Ich habe nun gestern damit begonnen, mich durch die empfohlenden Packages durchzukaempfen. Ich denke, ich werde damit schon zurecht kommen. Auf jeden Fall bin ich nun erst einmal mit Testen und Ausprobieren beschaeftigt. Auch Smarty werde ich mir einmal genauer anschauen. Nochmals Danke und viele Gruesse, Ralf