nicht angemeldet
Moin!
Eine andere Frage wäre, wie du ohne einheitliches Interface die Bearbeitung eines bis dato unbekannten Objektes handhabst.
Nun ja, ein "bis dato unbekanntes Objekt" setzt ja voraus, dass es überhaupt ein Objekt gibt. Ohne Objekt (dass man wollen mußte, und ins Leben rufen) kein unbekanntes Objekt. Mag jetzt spitzfindig klingen, aber in PHP im Programmieralltag eines durchschnittlichen Programmierers gibts nur sehr wenig Objekte, dafür aber sehr viele Strings, eventuell einsortiert in Arrays.
Bei uns im Projekt gibt es ein auf dem Java-Modell aufsetzendes Datenmodell, das auch einen Objekt-Editor zum "befüllen" der Objekte umfasst.
Wir reden hier im Thread von PHP, nicht von Java. In Java sind viele Dinge komplett anders - beispielsweise weil die Java-Applikation persistent (insbesondere im Hinblick auf die Daten) auf dem Server arbeitet, und durch das Framework die einzelnen Requests vor der Programmlogik gekapselt sind (nehme ich doch mal stark an, dass das so ist).
Bei PHP läuft das ja komplett anders. Da arbeitet man extrem requestorientiert, d.h. im Sinne einer hohen Performance wird man versuchen, pro Request ausschließlich a) den relevanten Programmcode einzubinden und b) nur die relevanten Daten zu beschaffen und auszugeben, bzw. übermittelte Daten zu verarbeiten und zu speichern.
Da dem Benutzer kaum Grenzen gesetzt sind wie er beispielsweise ein komplexes Objekt zusammensetzt kann die Anwendung auch nicht entscheiden was eine adäquate Darstellung wäre.
Der "Benutzer" ist ein Begriff, der zwei Bedeutungen haben kann: Entweder ist es derjenige, der die Webapplikation vor dem Browser bedient - dann muß der nehmen, was programmiert wurde. Oder es ist der gemeint, der ein Framework anwendet und zu einer Applikation zusammenstrickt. Dann hat der natürlich die grundsätzliche Freiheit, abstruse Kombinationen von Daten zusammenzustecken, bzw. das Framework täte gut daran, genau das zu erlauben.
Es ist aber aus PHP-Sicht ein Vorgang, der ziemlich weit entfernt ist von dem, was man so täglich mit PHP realisiert.
- Hallo Objekt, gib mir mal deine erste Eigenschaft! Ah, das ist ja ein String, dann zeige ich mal ein Textfeld an. Gut, dann gib mir mal die nächste. Ah, eine Aufzählung, dann sag mir mal alle Werte und ich mache dann eine Dropdown.
- Hallo Objekt, zeichne mal bitte {hier} deinen Editor!
Variante 1 hat ein Problem bzgl. der Wiederverwendung. Wenn du noch eine andere Stelle im Code hast, musst du das ganze nochmal machen. OK, zugegeben, man kann eine Funktion nehmen, das in eine Bibliothek auslagern etc. Ich persönlich bevorzuge aber mittlerweile diesen Grundsatz von "der dem's gehört soll's auch machen".
Letztendlich muß alles, was man macht, in HTML ausgegeben werden. Was wiederum bedeutet: Es ist ja nicht damit getan, das Objekt seinen Editor anzeigen zu lassen, sondern Werteveränderungen müssen auch wieder zurück ins Objekt.
Kann man natürlich als Affenformular realisieren, alle Editoraufrufe von Objekten registrieren ihren Datenbedarf, und je nachdem, ob das Formular neu angefordert oder (geändert) zurückgeschickt wurde, werden die Daten wieder auf die Objekte verteilt. Das ist aber nach meiner Ansicht ein ganz anderer Arbeitsansatz, als er bei PHP üblicherweise, um nicht zu sagen natürlicherweise vorherrscht.
- Sven Rautenberg
My sssignature, my preciousssss!