squig

Hallo,

danke für die bisherigen Anregungen, ich versuche eine meiner Ausagen nun etwas zu erläutern.

Damit bezog ich mich auf die Aussage von dr.e wobei in einem Template ein Formular komplett beschrieben werden sollte.
Nun frag ich mich, wieweit diese Beschreibung gehen sollte, soll man in diesem Template auch festlegen, bei welchen Feldern es sich um Pflichtfelder handelt und welche Datentypen usw als Eingabe erwartet werden?
Mein Ziel ist es meine Formularvalidierung nur einmal zu schreiben, ich plane eine Klasse "Validator", welche statisch verschiedene Methoden zur Validerung von Formulardaten bereitstellt, das ganze unter Nutzung der neuen Filter - Extension.
Nun würde ich gerne nicht mehr in meinem PHP - Code festlegen, wie ein Formular zu valideren ist, sondern die nötigen Schritte sollen entweder im Template oder alternativ in einer "Formularbeschreibungs - Datei" festgehalten werden.
Nach dem Abschicken des Formulars möchte ich die Information, was wie zu valideren ist, an meinen Controller geben und dieser ruft die entsprechenden Routinen des "Validator" auf. So müsste man nie wieder eine projektspezifische Validierung implementieren, sondern "nur" die Validierung beschreiben, in der Theorie

Das Template wird dann angezeigt, das Formular ausgefüllt und abgeschickt und nun kommt der Haken. Sind die Validierungsschritte im Template enthalten müsste ich dieses ja nun nochmal durchgehen und nach diesen Schritten suchen, besser wäre es vll, wenn das Templatesystem, bei der Ausführung des Templates diese Schritte schon auslesen und sich merken würde. Bei PHPTAL im Moment nicht der Fall, müsste man selbst Hand anlegen.
Alternativ könnte man die "Validierungsbeschreibung" in einem zum jeweiligen Template korrespondierenden File ablegen und von dort laden. Nachteil es müssen 2 Dateien geändert werden sollen Änderungen am Formular stattfinden.

Klingt alles im Moment etwas abstrus, bin da selber noch am Sortieren.

Forder ich den zuviel von einem Templatesystem, indem ich versuche die Validierung in solch einer Form zu beschreiben? Geht das über die Aufgabe der Templates hinaus und sollte generell in Geschäftslogik abgehandelt werden?

Bin dankbar für weitere Anregungen.


Bis dääähne.

Mister Ad

dr.e.

Genau das war meine Aussage und genau diese Vorstellung habe ich umgesetzt. In der Tag-Beschreibung unter http://christian.zierpflanzenberatun...ite=TagLibTags unter dem Punkt 2.3.16. Validator hat der Template-Entwickler die Möglichkeit die Attribute

- validator
- button
- field
- ...

eines Validators, oder auch eines Feldes direkt, zu setzen und so die Validierung bereits hier zu beschreiben. Mit dem Attribut "validator" kann man indirekt eine statische Methode "myValidator" ansprechen um die Eingabe zu validieren. Hier bist du also generisch und könntest auch Telefonnummern oder Datums oder sonstwas validieren in dem du einfach im Template die benötigte Methode einträgst. Bei mir heißen die Methoden dann "validateEMail" und im Tag muss ich nur "EMail" eintragen - der Einfachheit halber.


Diesen Ansatz bin ich auch gegangen, ist sicher der besste, weil man nur einmal an zentraler Stelle eine Funktion definiert.


Das ist 1:1 meine Implementierung, nur mit dem Unterschied, dass ich nochmal zwischen Tag-Logik und Controller im MVC-Sinn unterscheide. Der Tag an sich - schau dir dazu einfach mal die Dateien unter apps/tools/form/taglib/* an - kampselt die Logik des Validierens und der Ausgabe seiner selbst und der DocumentController kümmert sich um die Ausgabe eines Document-Knotens im DOM. Wenn dir das so noch nicht klar ist, kannst du dir auch die CHM-Datei für die Tools ansehen, dort sind die Klassen nochmals dokumentiert und man sieht das Zusammenspiel. Wenn du dir das Kontakt-Formular-Beispiel näher ansiehst (Template formular.html), dann repräsentiert jedes Tag (html:form, form:text, ...) ein Objekt im DOM. Jedes Objekt wird durch eine PHP-Implementierung mit "Leben" gefüllt. Jeder Tag hat quasi seine TagLib, die die Logik in PHP gießt. Diese TagLibs sind so aufgebaut, dass sie die nötigen Funktionen für die Darstellung eines Tags inne haben, so dass beim Transformieren des Objektbaums einfach nur noch die Methode transform() auf jedes Element aufgerufen wird und so die Ausgabe erzeugt wird. Schau's dir einfach mal an und versuche damit mal ein Formular zu bauen, du wirst sehen, es ist einfacher als du denkst. Musst einfach nur noch ein paar Tags zusammenbastelt und dann funktioniert das. Solltest du noch Fragen haben -> frag!


Genau. Das ist eben der Vorteil eines durchgängigen generischen DOMs, bei dem man beliebige Tag-Objekte einhängen kann. Dadurch kann man von jedem Objekt auf jedes andere "springen" und die Attribute oder Variablen auslesen. Im Fall des Formulars ist das so, dass eine Form ein Kind-Objekt eines Documents ist und man mit $this->__getForm('formname'); auf das Objekt zugreifen kann. Dieses besitzt die Eigenschaft "isValid" und indiziert, ob ein Formular _korrekt_ ausgefüllt wurde. Damit muss man im DocumentController (siehe Beispiel unter http://christian.zierpflanzenberatun...Seite=Tutorial -> kontakt_v4_controller.php) nichts weiter tun, als diese Eigenschaft abzufragen. Einfacher geht es nicht.


Das ist der Nachteil der Variante. Man müsste sich zudem eine Syntax überlegen, die klar und deutlich beschreibt, was validiert und wie validiert werden soll. Im Template, btw. im Tag eines Text-Feldes ist es einfacher - zumindest denke ich so. Ein

ist zudem charmanter, weil man keine zusätzliche Assoziations-Beziehung zwischen Tag (hier ein E-Mail-Feld) und dem Config-Offset mehr schaffen muss. Vorteil wäre, dass man hier eine mehrdeutige Assoziation schaffen könnte, und man nur einmal eine E-Mail-Validierung definieren möchte. Das ist jedoch wieder ein Nachteil, wenn man für unterschiedliche Felder unterschiedliche Text-Meldungen (siehe mein Beispiel) ausgeben möchte. Da frisst einen das Filehandling die dadurch gewonnene Performance wieder weg. Und die paar kB im Speicher machen meiner Einschätzung nach keine Probleme.

Wenn du fertig sortiert hast, wirst du sehen, dass es geil ist


Wie ich bereits erläutert habe: nein. Oder war das eine Frage in die Runde? Ansonsten bei Fowler nachlesen, was Aufgaben der Präsentations-Schicht sind. Er weiß es...


Gerne jederzeit wieder...

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

squig

Wow, nen Haufen zu lesen, dankeschön.

Melde mich dann

dr.e.

@Zwerg: Konnte dir mit deinem Problem nun geholfen werden?

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

zwerg

Jap,die Funktion "parserchen" von Slava funktioniert einwandfrei.
Vielen Dank für die viele Hilfe und Tipps.
Gruß,
zwerg