Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] phpdatei auslesen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Zitat von Slava
    $oTemplate->title = 'mein Titel';
    $oTemplate->products = array('Schere', 'Stein', 'Papier', 'Nagelfeile');
    darf eigentlich ohne überschriebener __set() methode nicht functionieren.
    warum nicht?

    Kommentar


    • #17
      das wundert mich auch, dass es funktioniert.
      ich glaube, dass ich "Java" denke.
      Slava
      http://bituniverse.com

      Kommentar


      • #18
        @Zergling: OK, jetzt ist mir das klar.

        @ALL: Nun weiter mit der Feature-Liste oder mit Kommentaren zu meinen ...
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design [B]before[/B] you start to write code!
        2. Discuss and review it together with [B]experts[/B]!
        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
        4. Write [I][B]clean and reusable[/B][/I] software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


        • #19
          Hallo,

          wo fang ich an?

          Ich setze mich im Moment mit PHPTAL als Template - System auseinander. Warum jenes? Gefällt mir einfach, ka, ist halt so

          Nun bin ich an dem Punkt, wo die als Template erzeugten Formulare validiert werden sollen. Und klasse wäre es natürlich, wenn das Template mitteilen würde, welches Feld den da sein muss und in welcher Form.

          Ist das überhaupt Aufgabe eines Templatesystems oder sollte rein der Kern über eine Validierung entscheiden?
          Ich sehe, dass dr.e dies als Anfordung an ein Templatesystem formuliert hat. Nur frage ich mich wer den diese Information nun ausliest/nutzt.
          Das Formular wird erzeugt, angezeigt und im Anschluss abgeschickt. Nun kommen die Daten beim Controller an. Woher weiss dieser nun, wie die Validierung stattfinden soll? Holt er sich die Info nochmal aus dem Template oder triggert er eine Funktion der Templateklasse?

          Für PHPTAL habe ich noch keine Lösung gefunden, grübel da noch.

          Hätte auch durchaus Interesse mehr zu dem Thema zu lesen oder vll auch etwas beizutragen, wenn mir das möglich ist.


          Bis dääähne.

          Kommentar


          • #20
            Hallo squig,

            Ich setze mich im Moment mit PHPTAL als Template - System auseinander. Warum jenes? Gefällt mir einfach, ka, ist halt so
            Hab mir das mal angesehen. Nutzt intern das HTML-DOM, wenn ich das richtig erkannt hat und erweitert es um tal-Attribute aus entsprechenden internen Namespaces. Ist eingentlich ganz hübsch.


            Nun bin ich an dem Punkt, wo die als Template erzeugten Formulare validiert werden sollen. Und klasse wäre es natürlich, wenn das Template mitteilen würde, welches Feld den da sein muss und in welcher Form.
            Richtig, das ist eine sehr wichtige Anforderung, da Formular-Validierung tausendfach eingesetzt wird und immer wieder ärgert man sich, dass man schon wieder alles selbst programmieren muss.


            Ist das überhaupt Aufgabe eines Templatesystems oder sollte rein der Kern über eine Validierung entscheiden?
            Im objektorientierten Ansatz ist die Formular-Geschichte in der Präsentations-Schicht angesiedelt, weil die Darstelllung von Formularen und evtl. Fehlermeldungen nun mal in HTML passiert. Da Präsentationsschicht nicht unbedingt heißt, dass man dort keine Logik verpacken darf - in der Tat benötigt man zur Steuerung und Ausgabe einer GUI einiges an Logik - so ist das auch im OO-Ansatz gerechtfertigt. Des Weiteren hat der Templatebauer, oder Entwickler damit die Möglichkeit mit einfachen Mitteln Formulare zu bauen und zu warten, ohne eine Zeile PHP-Code schreiben zu müssen.


            Ich sehe, dass dr.e dies als Anfordung an ein Templatesystem formuliert hat. Nur frage ich mich wer den diese Information nun ausliest/nutzt.
            Wie meinst du das?


            Das Formular wird erzeugt, angezeigt und im Anschluss abgeschickt. Nun kommen die Daten beim Controller an. Woher weiss dieser nun, wie die Validierung stattfinden soll? Holt er sich die Info nochmal aus dem Template oder triggert er eine Funktion der Templateklasse?
            Ich gehe hier - wie unter http://christian.zierpflanzenberatun...Seite=Tutorial beschrieben - folgenden Wege:
            Die Validierung und das Formular-Handling passiert vollständig in den Objekten des internen DOMs. Ein Controller wird immer im Context eines internen Document-Objekts aufgerufen und kennt dessen Attribute und den Objektbaum. Im Controller kannst du nun auf das Formular zugreifen und dir die Werte holen. Ich persönlich involviere hier aber nochmal den variablenHandler und lasse ihn die Werte aus dem Request auslesen, so dass ich sicher sein kann, dass diese Offsets auch wirklich bestehen.
            Im Fall des Kontaktformulars gibt es dann eine Business-Schicht, die sich um den Geschäfts-Prozess (=Abschicken des Formulars und weiterleiten auf einen anderen View) kümmert. Deswegen inizialisiert die Präsentations-Schicht ein Schnittstellen-Objekt, füllt es mit Daten und gibt es an die Business-Schicht weiter. Mehr Logik - wie das Handling von Benutzereingaben und die Ausgabe der GUI - sollte auch nicht in der Präsentations-Schicht verpackt sein.


            Für PHPTAL habe ich noch keine Lösung gefunden, grübel da noch.
            Die JUngs bieten soetwas nicht an und ich habe es auch in keiner Roadmap gefunden. Kann auch leider nicht beurteilen, wie man sowas in deren DOM einhängen könnte.


            Hätte auch durchaus Interesse mehr zu dem Thema zu lesen oder vll auch etwas beizutragen, wenn mir das möglich ist.
            Gerne. Ich habe auf meiner Demo-Seite und auch hier immer wieder Tipps genannt. Diese sind recht umfangreich und man muss sich auch ein bischen anstrengen, aber es führt in die objektorientierte Welt und deren Entwurfsmuster ein. Ich habe das Buch/die Bücher immer auf dem Tisch liegen, wenn ich implementiere. Ideen für meinen Page-Contoller sind diesem Buch entnommen. Hinweise dazu auf dem obigen Link.
            Viele Grüße,
            Dr.E.

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            1. Think about software design [B]before[/B] you start to write code!
            2. Discuss and review it together with [B]experts[/B]!
            3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
            4. Write [I][B]clean and reusable[/B][/I] software only!
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Kommentar


            • #21
              Hallo,

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

              Zitat:
              Ich sehe, dass dr.e dies als Anfordung an ein Templatesystem formuliert hat. Nur frage ich mich wer den diese Information nun ausliest/nutzt.

              Wie meinst du das?
              Damit bezog ich mich auf die Aussage von dr.e wobei in einem Template ein Formular komplett beschrieben werden sollte.
              Abstraktes Formular-Handling (Beschreibung eines Formulars komplett in XML-Tags)
              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.

              Kommentar


              • #22
                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?
                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.


                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.
                Diesen Ansatz bin ich auch gegangen, ist sicher der besste, weil man nur einmal an zentraler Stelle eine Funktion definiert.


                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 Wink
                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!


                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.
                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.


                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.
                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

                Code:
                <form:text name="AbsenderAdresse" class="eingabe_feld" style="width: 280px;" validate="true" validator="Text" button="KontaktSenden" />
                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.

                Klingt alles im Moment etwas abstrus, bin da selber noch am Sortieren.
                Wenn du fertig sortiert hast, wirst du sehen, dass es geil ist


                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?
                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...


                Bin dankbar für weitere Anregungen.
                Gerne jederzeit wieder...
                Viele Grüße,
                Dr.E.

                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                1. Think about software design [B]before[/B] you start to write code!
                2. Discuss and review it together with [B]experts[/B]!
                3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                4. Write [I][B]clean and reusable[/B][/I] software only!
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                Kommentar


                • #23
                  Wow, nen Haufen zu lesen, dankeschön.

                  Melde mich dann

                  Kommentar


                  • #24
                    @Zwerg: Konnte dir mit deinem Problem nun geholfen werden?
                    Viele Grüße,
                    Dr.E.

                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    1. Think about software design [B]before[/B] you start to write code!
                    2. Discuss and review it together with [B]experts[/B]!
                    3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                    4. Write [I][B]clean and reusable[/B][/I] software only!
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                    Kommentar


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

                      Kommentar

                      Lädt...
                      X