Noch ne Programmier-Bibliothek - Braucht man das? - Was braucht man?

[thorn]

Hallo,

bevor ich mich in http://www.websitebaker2.org/forum/index.php/topic,16881.msg110752.html#msg110752 weiter mit Englisch abquäle, um dort dann doch nur deutschen zu antworten  
hier also auch ein deutscher Faden zu dem Thema.

Practical Module Functions ist eine Bibliothek von - äh - "praktischen" Funktionen die ich geschrieben habe um bei meinen Projekten ein paar der "nervigsten" Aufgaben bei der Modul-Entwicklung zu umgehen.

Eine Übersicht und erste Einführung gibt es hier
pmf Übersicht (englisch)

Ein Download steht noch nicht zur Verfügung. - Mich würde erstmal eure Meinung dazu interessieren --  macht das Sinn? Braucht das jemand? -- Und vor allem: was gibt es noch an "ständigen Ärgernissen" oder "lästigen Aufgaben" bei der Modul-Entwicklung, die man vereinfachen könnte?


thorn.

Edit: Subject geändert.

[doc]

Hi,

ein paar Statements zur Ergänzung zu dem was ich schon im Englischen Thread gepostet habe.

Für mich macht ne Library Sinn, wenn diese auf ein "Produkt" zugeschnitten ist, mit diesem ausgeliefert wird und über mehrere Releases abwärtskompatibel zu Vorversionen bleibt. Diesbezüglich denke ich an ne Art API oder gar Framework innerhalb einer Anwendung wie einem CMS.

Sinn machen auch Libraries (oder Frameworks), welche eine lose Sammlung hochwertiger Lösungen für Standardaufgaben enthalten (Mail, Login, PDO ...). Ich denke hier u.a. an sowas wie PEAR, oder auch das Zend Framework, Symfony etc. Wenn man den Workflow mal durchschaut hat, geht die Umsetzung von Projekten recht zügig von der Hand. Die einzelnen Funktionen oder Module müssen sicher sein, gewartet werden. Vor allem sollten solche Libs gut dokumentiert sein und mit zahlreichen Beispielen einherkommen.

Was mir weniger gefällt sind Libs, welche einige wenige Aufgaben erfüllen, dafür aber wieder Abhängigkeiten erzeugen. Als Modulentwickler würde ich dann die Lib in jedes Modul packen, um möglichen Kompatibilitätsproblemen aus dem Weg zu gehen (sonst lohnt der Aufwand auch nicht wirklich). Nachteil. Jedes einzelne Modul enthält dann "Kopien" der Lib in der Version die zum Zeitpunkt des Moduls gerade aktuell war.

Wie immer gilt, der Aufwand des einlernens muss sich in gesteigerter Produktivität erkennen lassen. Die Lib sollte auch einfach erweiterbar sein (was z.B. beim überschreiben von Klassen recht einfach ginge).

Auffällig und Typisch:
Die bisher für WB verfügbaren "privaten" Libs decken die typischen Kernbereiche ab: 'Templates', 'Datenbankzugriff' und 'Mehrsprachigkeit'. Einige Lösungen erinnern etwas an PEAR, oder andere OS Libs.

wbLib: http://www.webbird.de/
rhTools: http://phpmanufaktur.de/cms/topics/rhtools.php
pmf: nctions:intro_en" target="_blank">http://nettest.thekk.de/doku.php/projects:practical_module_fu nctions:intro_en
xft2: http://www.websitebakers.com/pages/modules/listings/various/information.php

Fazit: Keine Ahnung ob es jemand braucht oder nutzen wird. Ich würde es mir auf jeden Fall anschauen und auch ein wenig damit rumspielen, so wie ich es mit den anderen WB Libs gemacht habe. Ich finde solche Libraries vor allem deshalb interessant, weil man sieht wie andere "Standardprobleme" angehen.

Gruss Doc

[thorn]

Auffällig und Typisch:
Die bisher für WB verfügbaren "privaten" Libs decken die typischen Kernbereiche ab: 'Templates', 'Datenbankzugriff' und 'Mehrsprachigkeit'. Einige Lösungen erinnern etwas an PEAR, oder andere OS Libs.

Was wohl bedeutet, daß WB selber in diesen Bereichen nur unbefriedigende Lösungen bietet.

Ich finde solche Libraries vor allem deshalb interessant, weil man sieht wie andere "Standardprobleme" angehen.

Dann war es ja doch noch für was nützlich ... 


thorn.

[maverik]

als nicht coder weiß ich natürlich mit solchen libs nichts anzufangen aber als anwender finde ich es nicht gut wenn ich erst überlegen muss welches modul ich gerade installiere und welche lib ich dafür brauche. installiere ich ein modul von wbbird brauche ich wblib, installiere ich ein modul von ralf brauche ich rhtools und maybe noch das db packet. so habe ich nachher 5 module installiert obohl ich nur 2 installieren wollte.

hier sollte man seine kraft bündeln und zusammen eine lib entwickeln die dann im installpacket vorhanden ist und auf den dann alle entwickler aufsetzen.

[doc]

Hi,

Bleibt nur zu hoffen, dass egal wie die Entscheidungen ausfallen, die phpLib "rausgeklopft" und durch etwas logisches ersetzt wird.

Bei den meisten WBLibs gehts um wesentlich mehr als ne rein Template Engine. Template Engines gibts wie Sand am Meer (z.B. hier, auf PEAR > 6, in jedem grösseren CMS ...) Fast genauso alt ist auch die Diskussion über das Pro und Con von Templateengines (Performance, PHP ist selbst ne Template Engine ...).

Ich denke es macht keinen Sinn, die phplib rauszunehmen, da x Module darauf basieren und der ganze WB Core darauf aufbaut. Dann lieber ne weiter Templateengine in den /include Ordner aufnehmen; wenn den mal eine für WB geeignete gefunden wurde

Was mir hier fehlt:
Ich fände es schön, wenn mal Abseits der "Templateengine" Wortmeldungen in Richtung WBLibs kämen. Also was wünscht sich der die ambitionierte Entwicklerin, was muss was sollte rein, wann würde sich der Aufwand für jemanden lohnen ...

Gruss Doc

[WebBird]

Dass sowas mit Biankas Lib einfacher geht (hat ja auch eine logische template engine) bezweifle ich nicht - bin ich mir sicher.
Ob sie an die Einfachheit von PMFs Methode herankommt, das müßte sie selbst dann anschauen, wenn sie dann da Lust zu hat.

Ich denke, das ist eine Frage des Standpunkts.

Sprachstrings

PMF -> <h1>{{=pmf_t('eCard Settings')}}</h1>
wblib -> <h1>{{ :lang eCard Settings }}</h1>

Loops und bedingte Anweisungen

PMF -> {{foreach($tpl_sort_thumbs as $v=>$text):}}
        <option value="{{_$v}}" {{if($tpl_sort_thumbs_selected==$v):}} selected="selected" {{endif;}}>{{_$text}}</option>
    {{endforeach;}}

wblib -> {{ :loop tpl_sort_thumbs }}
        <option value="{{ value }}" {{ :if selected }} selected="selected" {{ :ifend }}>{{ text }}</option>
    {{ :loopend }}


Ob man das eine oder das andere lieber mag, ist so individuell wie die Farbe der Unterhosen.

Mal abgesehen von der Template Engine, ist meine Lieblings-Lib eigentlich der ListBuilder.

$list->buildList( $list->buildRecursion( $pages ) );

Angenommen, man hat in $pages die pages-Tabelle von wb, kriegt man damit ein komplettes Navigationsmenü als Baum. Ich hab das jetzt auch schon im Backend der Foldergallery und verschiedenen anderen Modulen benutzt, um aus einem Array einen Baum zu generieren, und möchte das wirklich nicht mehr missen.

[WebBird]

Practical Module Functions ist eine Bibliothek von - äh - "praktischen" Funktionen die ich geschrieben habe um bei meinen Projekten ein paar der "nervigsten" Aufgaben bei der Modul-Entwicklung zu umgehen.

Hm, vermutlich geht das jetzt unter, aber mich würde mal eines interessieren:

Du gehst beim Template Parser den Weg, eine Quasi-Markup-Sprache zu verwenden, die an PHP angelehnt ist. (foreach etc.) Der Parser "compiliert" dann das Template, wandelt also die Pseudo-Statements in echte Statements um. Da frage ich mich, warum dann überhaupt diesen Umweg gehen? So viel hübscher als ein direktes "<?php foreach()...?>" ist es doch auch nicht, oder? (Vgl. Savant3 Template Engine)

Ich will nicht provozieren, ich interessiere mich wirklich für die Gründe. Ich persönlich habe mich ja von Savant3 getrennt, weil ich die xft2 Markups deutlich simpler fand, und habe dann sozusagen eine Mischung aus xft2, HTML::Template (Perl) und PmWiki-Markup draus gemacht. (Letzteres aus der Erfahrung heraus, daß mit dem Wiki-Markup auch Nicht-Entwickler gut klar kommen.) Du hast Dich jetzt anders entschieden, und mich würden interessieren, warum.

[Waldschwein]

Hallo!

Für alles, was nicht direkt mit thorns Modul zu tun hat habe ich die Themen einmal auseinandergefiesel t und es geht dann munter hier weiter: http://www.websitebaker2.org/forum/index.php/topic,16904.html

Gruß Michael

[Stefek]

Dass sowas mit Biankas Lib einfacher geht (hat ja auch eine logische template engine) bezweifle ich nicht - bin ich mir sicher.
Ob sie an die Einfachheit von PMFs Methode herankommt, das müßte sie selbst dann anschauen, wenn sie dann da Lust zu hat.

Ich denke, das ist eine Frage des Standpunkts.

Sprachstrings

PMF -> <h1>{{=pmf_t('eCard Settings')}}</h1>
wblib -> <h1>{{ :lang eCard Settings }}</h1>

Loops und bedingte Anweisungen

PMF -> {{foreach($tpl_sort_thumbs as $v=>$text):}}
        <option value="{{_$v}}" {{if($tpl_sort_thumbs_selected==$v):}} selected="selected" {{endif;}}>{{_$text}}</option>
    {{endforeach;}}

wblib -> {{ :loop tpl_sort_thumbs }}
        <option value="{{ value }}" {{ :if selected }} selected="selected" {{ :ifend }}>{{ text }}</option>
    {{ :loopend }}


Ob man das eine oder das andere lieber mag, ist so individuell wie die Farbe der Unterhosen.

Liebe Bianka,
diesmal habe ich eher vom Gesichtspunkt des Programmierers gesprochen, als ich schrieb: "Ob sie an die Einfachheit von PMFs Methode herankommt, das müßte sie selbst dann anschauen..."
Für die Verwendung in den Templates selbst, muss man sich natürlich die Eigenheiten merken oder einen "Schummelzettel" (Cheatsheet) verwenden.
Es ging mir aber um die Bereitstellung der Template Variablen im Skript selbst.
So viel ich weiß, ist es bloßes PHP und auch die Templates an sich verwenden nur "Equivalente" von PHP - es wird einfach die alternative Syntax verwendet, anhand von Equivalenten, die man sich eben merken muss (was aber leicht ist, weil es nicht so viele sind).
Das ist einfach für den Coder und für den Designer.
(Der Coder braucht sich die Eigenheiten kaum zu merken, da es auf den ersten Blick ersichtlich ist, wenn er zwischen Skript und Template switcht - praktisch.)

Plus ein Pluspunkt -> der Designer wird dank der alternativen Syntakt ein wenig an (einfache) PHP Logik herangeführt.

Ich denke man kann es sich später am besten anhand eines richtigen Beispielsanschauen, wenn das Teil veröffentlicht ist.

LG,
Stefek

[WebBird]

Es ging mir aber um die Bereitstellung der Template Variablen im Skript selbst.

Kapier' ich grad nicht. Ich beantworte es mal so, wie ich es verstehe...

Du baust Dir im Script ein Array zusammen. Schlüssel ist der Name des Platzhalters, Wert was-auch-immer. Loops sind dann halt Schlüssel, die statt eines Strings ein Array beinhalten.

Wenn Du alles beisammen hast, übergibst Du den gesamten Plumquatsch den Parser, wahlweise mit "gib mir das Ergebnis zur weiteren Bearbeitung" oder "spuck's gleich aus" (=echo).

Beispiel hier: http://www.webing.de/webbird/wblib/de/index.php?n=Klassen.WbTemplateWB

[thorn]

Hallo,

Du gehst beim Template Parser den Weg, eine Quasi-Markup-Sprache zu verwenden, die an PHP angelehnt ist. (foreach etc.) Der Parser "compiliert" dann das Template, wandelt also die Pseudo-Statements in echte Statements um. Da frage ich mich, warum dann überhaupt diesen Umweg gehen? So viel hübscher als ein direktes "<?php foreach()...?>" ist es doch auch nicht, oder?

Ne ne, das Template ist ein PHP-Template. Ich habe nur <?php ?> durch {{ }} ersetzt, damit das etwas einfacher zu schreiben/übersichtlicher ist.

Siehe dieses Beispiel, das ist reines PHP (denk dir einfach die {{ }} durch <?php ?> ersetzt):

Code:

{{if(!empty($tpl_extra_fields)):}}
    {{foreach($tpl_extra_fields as $field):}}
        {{switch ($field['type']):
          case 'text':}}
            <tr>
                <th>{{-$field['text']}}:</th>
                <td><input type="text" name="{{-$field['name']}}" value="{{-$field['value']}}" size="40" {{-$field['style']}} /></td>
            </tr>
            {{break;}}
        {{case 'textarea':}}
        {{case 'editarea':}}
            <tr>
                <th>{{-$field['text']}}:</th>
                <td><textarea id="{{-$field['id']}}" name="{{-$field['name']}}" cols="40" rows="5" {{-$field['style']}}>{{-$field['value']}}</textarea></td>
            </tr>
            {{break;}}
        {{case 'array':}}
            {{foreach($field['values'] as $key=>$value):}}
            <tr>
                <td colspan="2">
                    <table class="textfields" width="100%" cellpadding="2" cellspacing="0" border="0">
                        <tr>
                            <th>{{-$field['text']}}:</th>
                            <td style="width:20%;"><textarea id="{{$id=uniqid(); $tpl_list_growfield[]=$id; echo $id;}}" name="{{-$field['name'].'[k][]'}}" style="width:95%;" rows="1" />{{-$key}}</textarea></td>
                            <td><span class="arrow">=></span></td>
                            <td style="width:60%;"><textarea id="{{$id=uniqid(); $tpl_list_growfield[]=$id; echo $id;}}" name="{{-$field['name'].'[v][]'}}" style="width:95%;" rows="1" />{{-$value}}</textarea></td>
                        </tr>
                    </table>
                   </td>
            </tr>
            {{endforeach;}}
            {{break;}}
        {{endswitch;}}
    {{endforeach;}}
{{endif;}}

Es geht also auch sowas:

Code:

{{
    // this is a block of PHP-code
    $str = 'undefined';
    if($a=='test' && $i==0) {
        $str = "Test-0";
    }
}}
<em>{{-$str}}</em><br />

Der Sinn des ganzen war es ja gerade, daß der Designer nicht noch eine "Template-Sprache" lernen muß, sondern er direkt mit PHP arbeiten kann (die meisten Web-Designer können genug PHP um damit klar zu kommen).


Und zu der obigen Frage zu pmf_t()

Code:

PMF -> <h1>{{=pmf_t('eCard Settings')}}</h1>
wblib -> <h1>{{ :lang eCard Settings }}</h1>

Der pmf_t()-Aufruf ergibt sich natürlich daraus, daß das PHP ist und dort eigentlich dies steht:

Code:

<h1><?php echo pmf_t('eCard Settings') ?></h1>

Und die Handhabung von Variablen (was man tatsächlich eher selten braucht in den Templates) kann man leicht über sprintf() abwickeln

Code:

{{=sprintf(pmf_t('Send me an <a href="mailto:%s">eMail</a>'), $email)}}

Gleichzeitig ist pmf_t() die Kennung für die automatische Erzeugung der Sprachdateien, und (experimentell) zur Erzeugung der  .pot-Datei [gettext] (nagut, die .pot-Datei ist im WB-Umfeld eher nicht nützlich).

Das pmf_t() zu ersetzen, vielleicht: {{X eCard Settings }}, erscheint mir nicht so praktikabel.
Siehe http://nettest.thekk.de/doku.php/projects:practical_module_fu nctions:language_files_en

Code:

{{X One member deleted | %d members deleted | 3 | Members are the displayed elements in the list-view }}

ne, da nehm ich lieber pmf_t() und sprintf() ... obwohl ... !?


thorn.

[WebBird]

Danke für die Erläuterung. Das erklärt wirklich einiges.

[thorn]

Es ging mir aber um die Bereitstellung der Template Variablen im Skript selbst.

Kapier' ich grad nicht. Ich beantworte es mal so, wie ich es verstehe...

Er meint wahrscheinlich, daß für einen Programmierer ohne OOP-Erfahrung dies:

Code:

$id = pmf_tpl_create(dirname(__FILE__).'/templates/settings.htt');
 
pmf_tpl_setvar($id, array(
    'sort_thumbs' => $sort,
    'sort_thumbs_selected' => $settings['sort_thumbs']
));

pmf_tpl_echo($id);

einfacher aussieht als das:

Code:

$lang = new wbI18n( LANGUAGE );

$tpl  = new wbTemplate( array( 'lang' => $lang ) );

$tpl->setPath( dirname(__FILE__).'/../templates' );

$tabs = array(
  'categories'
      => array(
             'title' => 'Categories',
             'p'     => ''
         ),
  'modules'
      => array(
             'title' => 'Modules',
             'p'     => 'mod',
         ),
  'settings'
      => array(
             'title' => 'Settings',
             'p'     => 'set',
         ),
);

$current = 'modules';
$tabs[ $current ][ 'selected' ]   = ' id="current"';
$tabs[ $current ][ 'liselected' ] = ' id="active"';

$tpl->printTemplate(
    'mytemplate.tpl',
    array(
            'navlist'        => $tabs,
            'AR_URL'         => AR_URL,
            'url'            => 'http://...',
    )
);

(hab ich jetzt einfach mal von deiner Seite kopiert, und zusammengestückelt, ohne auf den Sinn zu achten. Hoffe das Beispiel stimmt soweit)


thorn.

[WebBird]

Hm. Warum fühlst Du Dich angegriffen, nur weil ich auf Savant3 verlinke? Ist doch nie schlecht, über den Tellerrand zu gucken?

Was die Sprachfiles angeht, bin ich ja ganz bei Dir. Ich habe in Perl meist mit Locale::Maketext gearbeitet und wbI18n daran angelehnt. Thorn hat zufällig das selbe gemacht. Das zeigt IMHO, daß der Ansatz nicht ganz doof ist. 

GNU Maketext hat halt gewisse Problematiken, weil die Sprachdateien compiliert werden, was wiederum erfordert, daß Maketext auf dem Zielsystem installiert ist, was man nicht voraussetzen kann. Außerdem muß man den Mist dann bei jeder Änderung neu compilieren. Locale::Maketext umschifft dieses Problem recht elegant, weshalb ich es mir auch als Vorbild genommen habe. (Thorns Vorbild kenne ich nicht. *g*)

[WebBird]

Du unterstellst mir hier Dinge, die einfach unwahr sind. Auf dieser Basis wird nie etwas Konstruktives rauskommen. Du scheinst lieber (falsch) zu interpretieren als lieber zu lesen, was wirklich da steht. "Du schweifst vom Thema ab" und "ich kann einfach sehen, daß..." sind ganz typische Aussagen, wenn man jemanden angreifen will. Ich weiß nur nicht, warum Du glaubst, mich angreifen zu müssen. Ich habe hypothetisch gesagt, daß es Thorn egal sein dürfte, ob ich seine Lib nun mag oder nicht - und Du interpretierst das Schlechte, daß ich sie nämlich nicht mag. Das habe ich aber gar nicht gesagt. Außerdem unterstellst Du, daß ich sie gar nicht kenne - tatsächlich habe ich mir aber gestern bereits den kompletten Quellcode angesehen.

Ich mag tatsächlich seinen Ansatz nicht, was das Templating betrifft - aber was ist da so schlimm dran? Ich habe mich lange genug mit den verschiedenen Ansätzen befaßt, um eine Meinung dazu gebildet zu haben. Ich habe aber auch mehrfach laut und deutlich gesagt, daß meine Meinung _meine Meinung_ ist, mehr nicht. Und das Recht nehme ich mir heraus, eine andere zu vertreten als Du oder Thorn. Das hat doch nichts damit zu tun, ob ich in meinem Stolz gekränkt bin. Warum sollte ich denn? Weil Thorn es anders macht als ich? Oder weil Du seine Lib magst und Dich mit meiner noch nie beschäftigt hast? Wenn meine Welt so aussähe, wäre ich schon längst von der Brücke gesprungen...

Also, bitte, komm mal wieder runter und bleib sachlich. _Du_ beschwerst Dich, _ich_ würde vom Thema abschweifen? Dann werde bitte nicht persönlich und wirf mit Unterstellungen um Dich.

[mr-fan]

....genug über "Template" Engines geredet. Mich würde mal interessieren welche anderen Funktionen man sinnvoll...

Genau!

mich als Mensch der sich vielleicht die nächste zeit (dieses jahr) ein wenig mehr mit PHP auseinandersetzt
_und_ quasi als evtl. als "benutzer" solcher "vereinfachten" konstrukte auftreten könnte, da ich daran zweifle mir mein eigenes toolkit machen zu könnnen......

funktionen wie automatische specialchars, sqlinjection vorbeugen, listbuilder, db connectoren usw.  usw....wären sicherheitstechnisc h sinnvoll

and with such importend tools for example to prevent sqlinjection or use htmlspecialchars and so on...it would may be easier to use PHP right and get the trust to try out more....

wenn Bianka und Thomas und ich würde evtl. auch andere die mitlesen und "Programmierer" sind....bitten vielleicht kurz ihre "fachliche" meinung zu äußern!

Ich habe vertrauen in bezug auf die unterschiedlichen stiele und eigenheiten...ich vertraue darauf

1.) das _alle_ programmierer und damit meine ich _alle_  hier gute arbeit leisten egal ob snippet/modul/droplet das mehr kann als 1+1 z.b. der minikalender usw./core/...
2.) das dies die programmierer auch selber wie schon von thorn, doc und webbird erwähnt wissen!
3.) das für den Core hinsichtlich Templates zu gegebener Zeit geeignete lösungen gefunden werden bis auf ein paar ausnahmen haben die meisten im dev-team die dort coden auch mit design zu tun (spontan fallen mir da ruud,aldus,magnal und natürlich auch bianka ein bei einigen weis ich es schlicht nicht...)  ->wir haben doch so viele baustellen besonders für unsere coder - also bitte keine vorwürfe mehr oder solche die als solche verstanden könnten werden       

also bitte wieder zum thema von Thomas zurückkehren - sonst gibt es hier gleich noch einen threat ableger....und mose bekommt ein burn-out syndrom.....

Fragen die ich als Lai noch hätte - an alle die auch thorn anspricht - nähmlich programmierer zwegs seiner Lib!!!! nicht die nichtprogrammierer ob eine weitere sinn macht oder nicht - denn ein nichtprogrammierer sieht gleich oh gott nicht noch eine.....

:: in punkto datenbank handling - unterschiede zu bestehenden libs - @thomas dein ansatz dabei? @anderen unterschied zu den jeweiligen anderen lösungen (dbconnect (hab ich schon mal angetestet), wblib)

:: in punkto settings handling steht noch nichts auf der seite... @thorn was fällt da drunter? valdierung ähnliche dinge wie formbuilder listbuilder

::was mich interessiert, weil ich es noch nicht so gut "lesen" kann ist welche funktionen die beiden klassen in den rhtools zur verfügung stellen? und ob es in den PMF dafür ähnliches gibt? unterschiede?

::was würde noch hilfreich sein oder sinnvoll für solche toolkits oder ein generelles WB Toolkit?

::meine wünsche für WB Lib   

- db connector der einfachere install scripte erlaub und sicheres db handling erleichtert
- wie ich grad gelesen hab schon dopplet gewünscht einfache wysiwyg einbindung in module per stadardlösung
- vom core gestellte sichere/gewartete dateiupload anbindung - imagehandling

so genug dumme fragen 

mfg martin

[doc]

Hi,

ich fände ne Datenbankabstraktio n nicht schlecht, um verschiedene Datenbanken mit einer einheitlichen Syntax nutzen zu können (wie z.B. SQlLite etc.).

Auch gut fand ich den leider "eingeschlafenen" Ansatz von Iceat mit OBOTRA.

Schön wären auch ein paar nützliche Funktionen zur Validierung und Filterung von Benutzer Eingaben.

Handlung und Umwandlung von Terminen, Daten, Umrechnung, Zeitrechnung und Ausgabe / Formatierung Zeit- oder datumsbezogenere Daten.

Möglichkeit, CSS und Javascript in nicht von WB unterstützten Seiten zu verwenden (z.B. erweiterte $wb Klasse, wie etwas in AFE).

Und einige Funktionen mehr ...

Doc

P.S.: Ja ich weiss, einige der angesprochen Sachen gehen auch mit PHP 5 oder den PHP SPL

[WebBird]

Richtig. Formdaten-Validierung und Absicherung gegen SQL Injection sind ganz große Baustellen. wbFormBuilder und wbValidate sind meine (unfertigen) Lösungen dafür, aber sowas gehört unbedingt in den Core. In Sachen Validierung gibt es in PHP 5 auch schon was Fertiges (http://www.php.net/manual/de/function.filter-var.php), man muß es halt nur nutzen. Wenn der Core den direkten Zugriff auf die Superglobals $_REQUEST etc. unterbinden und die Validierung erzwingen würde, wäre schon viel gewonnen.

Ansatz (nur ein grobes Beispiel):

$wb->param( 'fieldname' ) - Zugriff auf das Formularfeld "fieldname", welches dann schon mal per Default vom Gröbsten gesäubert wird   - also durch htmlentities() schieben um <script>...</script> zu entschärfen etc

Für alles Weitere müssen dann natürlich erweiterte Funktionen zur Verfügung stehen, wenn man also etwa HTML erwartet oder sicher gehen will, daß der Wert einer Variablen den richtigen Typ hat. (Integer, Bool, Datei, ...)

Edit: Meine Tasta klemmt, dauernd fehlen irgendwo Buchstaben...

[Waldschwein]

Hallo!

Zu den Features, die ich mir wünschen würde und noch nicht (glaube ich zumindest, habe mir nicht alles durchgelesen) genannt wurden:
- Eine Kommentar-/Formularfunktion, die WB-übergreifend alle Kommentare / Forms / wie-auch-immer zentral handhabt. Gerade bei Benutzereingaben im Frontend, wo prinzipiell jeder rankann ist die Sicherheitsgefahr am größten. Würde so etwas zentral zur Verfügung gestellt (ich glaube Typolight hat sowas wenn ich mich nicht irre) könnte man ein Forum in kürzester Zeit erstellen, aber auch Gästebuch, Bildergalerie incl. Benutzerupload etc. pp.

Gruß Michael

[mr-fan]

Interessante Ausführung, so kannst du jeder Seite ein anderes Aussehen geben, ist die CSS nicht vorhanden, dann StandardDesign.

hi,

das geht doch mit WB templates auch schon einfach mit PHP

Code:

<?php
$filename = PAGE_TITLE;
$default = 'basic.css'

if (file_exists($filename)) {
    $file = $filename;
} else {
    $file = $default;
}
?>
// CSS Ausgabe
<link href="<?php echo TEMPLATE_DIR; ?>/<?php echo $file; ?>.css" rel="stylesheet" type="text/css" media="screen" />

so oder ähnlich ->ungetestet.....hmm müsste man ein droplet bauen...egal!

Das hat schon wieder nur mit den Templates zu tun mir fehlen die ganzen anderen Aspekte einer Lib / Toolkit für Programmierer???

wobei solche Funktionen natürlich teil einer solchen WB Lib sein/werden könnten.

Vorgegebene Templatefunktionen wie wechselnde Headerbilder/Bilder - CSS - JS und jQuery Dateien....wobei das mit WB auch evtl. in naher Zukunft mal per Backend steuerbar sein wird  

so nun würden mich diese fragen doch interessieren falls dazu einer was weis - ich nicht sonst hätt ich nicht gefragt....und überraschung es geht nicht um template engines....

:: in punkto datenbank handling - unterschiede zu bestehenden libs - @thomas dein ansatz dabei? @anderen unterschied zu den jeweiligen anderen lösungen (dbconnect (hab ich schon mal angetestet), wblib)

:: in punkto settings handling steht noch nichts auf der seite... @thorn was fällt da drunter? valdierung ähnliche dinge wie formbuilder listbuilder

::was mich interessiert, weil ich es noch nicht so gut "lesen" kann ist welche funktionen die beiden klassen in den rhtools zur verfügung stellen? und ob es in den PMF dafür ähnliches gibt? unterschiede?

mfg martin

[thorn]

Hallo,

@mr-fan

:: in punkto datenbank handling - unterschiede zu bestehenden libs - @thomas dein ansatz dabei? @anderen unterschied zu den jeweiligen anderen lösungen (dbconnect (hab ich schon mal angetestet), wblib)

:: in punkto settings handling steht noch nichts auf der seite... @thorn was fällt da drunter? valdierung ähnliche dinge wie formbuilder listbuilder

Du verwechselst pmf mit so einem full bloated framework -- das will pmf aber gar nicht sein. Würde ich auch für ziemlich übertrieben halten.

pmf ist eine Ansammlung praktischer Funktionen:

Sprachdateien:

unpraktisch	praktisch
kryptische Kürzel als Keys	ausgeschriebener Text
jede Sprachdatei von Hand anpassen/erweitern müssen	automatisches Erzeugen der Sprachdateien
Sprachdateien laden müssen	automatisches laden der richtigen Sprachdatei

Templates:

unpraktisch	praktisch
Ausgabe von übersetztem Text umständlich über Sprachdatei -> PHP-Code -> Template	Ausgabe von Text direkt im Template
aufwendige Handhabung von Schleifen/Blöcken	Benutzung von PHP
"Steuerungslogik" muß im Programm programmiert werden	"Steuerungslogik" im Template
langsam	schnell

Settings (Einstellungen des Moduls/Config):

unpraktisch	praktisch
Settings müssen aus DB geladen werden	Settings stehen automatisch zur Verfügung

Database retrieval:

unpraktisch	praktisch
lästiges if($query→numRows()>0) und while($res=$query→fetchRow())	Daten sind "einfach da"
man muß selber auf SQL-Injections achten	Grundschutz eingebaut

Caching von Daten:

unpraktisch	praktisch
fehlt	vorhanden

Caching von Daten:

unpraktisch	praktisch
fehlt	vorhanden

Debugging:

unpraktisch	praktisch
fehlt	vorhanden

thorn.

[mr-fan]

danke dir für die erklärung!

Bis auf die Template Engine ist PMF ja doch eher eine Art toolkit, als eine Lib mit vielen Funktionen...aber egal!

Da ich gern lerne werd ich es mir einfach anschaun, genau so wie ich aktuell mit xft2 arbeite (fürs frontend) und mit wblib, dbconnect und anderen experiementiere, ob ich damit "irgendwas" zustande bringe... (ich lerne fast nur durchs ausprobieren und abgucken und dumm fragen natürlich;) )

Was mich dann an PMF am meisten interessiert sind die Datenbankabfragen für Snippets oder Droplets, mit den beiden dingen probier ich schon mal rum, das ist für meinen horizont noch übersichtlich.

wenn man PMF dort einbinden kann/verwenden kann - erleichtert das DB abfragen und bei snippets hab ich wie du schreibst nen "grundschutz" das ich bei db/wb sachen keine grube grabe in die andere böse dinge schmeisen können....

bin mal gespannt auf dein PMf -- deine fragen waren "braucht man das?" und "was braucht man?"

zur frage "Was braucht man?" disskutieren hier einfach zu wenig programmierer leider!!

"braucht man das? hmm ich glaube diese frage ist ein wenig falsch gestellt - ich denke Du brauchst das schon mal auf alle Fälle - sonst hättest Du das konzept/ganze nicht entwickelt.... und ob es andere brauchen zeigt sich erst - die bestehenden Libs zeigen ja auch schon das diese hauptsächlich von den eigenen entwicklern genutzt wird und weniger von anderen modulentwicklern... wobei dann für später wirklich gar nichts dagegen spricht einige dinge aus den verschiedenen ansätzen für eine nextgen oder ähnliches (API?) zu übernehmen....im gegenteil man hat schlicht eine auswahl an möglichkeiten...so sehe ich das mal.

auf die frage "ist das interessant?" würde ich dir schon mal mit ja antworten und einige andere auch (z.B. doc denk ich mal sicher und andere auch) denn arbeitsweisen und andere ansichten sind immer interessant!

grüße aus dem jetzt auch verschneiten süden
martin