PHP Dateien frei von HTML halten?
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
aufbau
beispiel
code
datei
datenbank
datum
design
designer
entwickler
kern
kunde
objekt
parameter
projekt
prototyp
team
url
vorteil
woche
zeile
-
sebulon schrieb:
So, während der PHP-Entwickler den Kern für den Webshop schreibt, kann der Datenbankentwickler die Datenbank entsprechend den Kundenanforderungen modellieren. Der Designer kann in Photoshop rummalen und Designs erstellen, die dem Kunden vorgestellt werden, um ihn entscheiden zu lassen, was er will. der JavaScript-"Entwickler" kann Basisfunktionen schreiben, die nachher nur noch entsprechend eingebunden werden, wie Clientseitige Eingabeverifizierungen, Authentifizierung und Validierungsfunktionen für Daten/Formulare.
soweit ist noch alles gut. nehmen wir an, der PHP-Entwickler hat den Kern fertig, die Datenbank ist modelliert, Design vom Kunden ausgewählt.
Jetzt muss der Shop entsprechend der erwarteten Funktionalität zusammengebaut werden.
Kann man ohne irgendwelche Probleme auch ohne MVC erledigen, was du aber ja selbst schon gesagt hast.
sebulon schrieb:
Datenbank ist klar, der DB-Entwickler setzt seine Modellierung um, schreibt Prozeduren für den kontrollierten Zugriff und dokumentiert sie für den PHP Entwickler. Damit sind Daten von der Geschäftslogik getrennt. Der Designer schreibt sich entsprechend dem entworfenen Design seine HTML-Grundstruktur, styled die durch, baut einen Design-Prototypen(Design von Geschäftslogik getrennt). Der App-Entwickler schreibt weiter seine JavaScripts weiter, fängt aber schonmal an, mit dem Designer zu kommunizieren, bezüglich einbindepunkte des JavaScripts in das Design(gibt ja auch JS-funktionen, die man nur für das Design schreibt, wie ein/aus-Blenden von elementen, Slider, Fehleranzeige beim Greifen durch Clientseitige Eingabevalidierung.
Wär somit die 2. stufe, wir haben einen Kern, der an der datenbank hängt(am besten alle Datenbankeinträge als Objekte abgelegt, die den Aufbau der Datenbank wiederspiegeln, warum das so gemacht wird, erkläre ich später).
Und wir haben ein Design, was sich schonmal bewegt, also einen echten Design-Prototypen.
Und auch hier verstehe ich noch nicht warum das NUR durch MVC lösbar sein sollte... . Mal vorab ich habe nie gesagt das jeglicher Html-Code, PHP Code, Javascript etc. in einer einzigen Datei liegen! Sowas kann man ohne Probleme trennen und an den benötigten Stellen einbinden, auch ohne MVC. Sehen wir weiter...
sebulon schrieb:
diese 2 elemente müssen jetzt zusammengeführt werden. Da gibt es 2 Möglichkeiten:
1. der PHP entwickler nimmt sich das Deign daher und Frickelt das rein. Designer ist Arbeitslos, Prozess dauert länger
2. Der PHP-Entwickler schreibt eine Art Template-Engine oder nimmt eine fertige(wie Smarty) und stimmt sich mit dem Designer ab, welche Parameter übergeben werden un d wie die Platzhalter aussehen. Beide können gleichzeitig dran arbeiten. Es ist etwas umständlicher, aber man spart effektiv Zeit bis zur Fertigstellung des Projektes.
Zu 1. was muss denn der PHP Entwickler rein "frickeln", das Design? Inwiefern, sollte das jetzt ohne MVC so umständlich sein?
Der Designer ist arbeitslos? Stopfst du jetzt den Fortschritt gesammelt in eine einzige Datei und währenddessen ist der Designer arbeitslos? Kann man doch wohl auch ohne MVC regeln...
Bei 2. wäre der Punkt, dauert länger richtig!
a) Erstmal muss sich der PHP-Entwickler in Smarty, oder ähnlichem, einarbeiten was schon einmal einiges an Zeit kostet
b) Der PHP-Entwickler schreibt seinen eigenen Template-Engine/Framework und verliert dadurch noch gleich viel mehr Zeit!
Zudem was genau meinst du mit Platzhaltern und den Parametern?
sebulon schrieb:
In der Regel soltle man sich für Schritt 2 entscheiden. durch ein derart Striktes MVC kann man Ressourcen effektiver auslastne und Projekte schneller durchbringen. das wäre aber nur ein Vorteil, wenn man nicht alleine Arbeitet.
---------------------------------------------------------
Wenn ich einen Inhaltsbereich habe, in welchen ich meine Inhalte lade (können auch reine Html-Seiten sein), wozu brauche ich da jetzt einen aufwendig programmierten Controller?
sebulon schrieb:
so, jetzt ist etwas Zeit ins Land gegangen, das Team arbeitet bereits an einem anderen Projekt, der Kunde meldet sich wieder, will ein anderes Design.
Wenn wir in der 3. Stufe nach Methode 1 vorgegangen wären, würden wir jetzt PHP entwickler und designer/FrontEnd-entwickler beschäftigen, mit selbingem Zeitaufwand bei beiden, wie bei einer neuerstellung
Sind wir jedoch wie in schritt 2 vorgegangen, baut nur der Designer den neuen Design-prototypen, holt sich die Parameter und stellt das Neue Template rein, ohne eine php-datei anfassen zu müssen. Der zeitaufwand ist nur noch ein Bruchteil(Design könnte in 1 Arbeitstag komplett umgesetzt werden, während bei Methode 1 zB 1 woche vergeht, in der 2 Arbeitskräfte gebraucht werden, also 2 Arbeitswochen).
Ich weiß ja nicht wie du dir das gerade vorstellst aber wie kannst du über einen Aufwand sprechen der einer Neuerstellung gleicht?!
Wie hast du dir vorgestellt das, dass programmiert wurde - alles in einer einzigen Datei?
Welche Design-Anpassungen gibt es, die man jetzt ohne CSS mal gar nicht lösen kann?
Finde mal ein Beispiel und ich wette es lässt sich im Notfall mit reinen Html-Anpassungen beheben, bei den Inhaltsseiten - die ich einbinde.
Da brauche ich keinen PHP-Entwickler... . Nur den Designer.
sebulon schrieb:
und bezüglich der Objektorientierten Classenerstellung für Datensätze:
Der Kunde kommt nochmal später wieder, will seine Produktpalette umstellen, braucht also Änderungen an der datenbank. Der datenbankentwickler designt neu, gibt die Änderungen an den Entwickler weiter, der passt seine Klassen entsprechend an und das läuft neu weiter. ohne Objekte dürfte der Entwickler den halben Shop umbauen, mit Objekten weiß er genau: anpassung der Objekte, neue Parameter an den Designer weitergeben, der baut die ins Template ein. Effektiv 2-3 Personentage für 3 Mitarbeiter.
Nach Italienischem Programmierprinzip(Spaghetti-Code) würde der DB-Entwickler den selben arbeitsaufwand haben, der Designer müsste die neuen daten ins Design einpflegen, könnte dann aber nix mehr machen und der PHP entwickler bräuchte eine Woche, die Änderungen Fehlerfrei in seine 50000 Code-Zeilen einzupflegen...(10 Personentage)
--------------------------------------------
Jetzt fängst du noch mit OOP an...
Wer hat denn jetzt gesagt das man auf OOP komplett verzichten sollte oder muss, dass du es verteidigen und loben musst?
Ich meine wir reden jetzt rein von Model/View/Controller!
Das brauche ich auch dafür NICHT!
OOP ist hierbei nützlich und da stimm ich dir auch zu!
Außerdem sollte man mal über das Projekt nachdenken, was ist das für ein Projekt?
Soll der Kunde stets in der Lage sein, seine Webseite zu verwalten?
Neue Seiten erstellen, ohne großen Aufwand, rein über einen simplen Editor in einem Administrationsbereich?
Ja? Dann nehme ich ein entsprechendes CMS, beispielsweise Joomla oder ich habe ein eigenes CMS - welches ich entsprechend auf den Kunde anpasse.
Man kann sich irgendwo auch einreden das man MVC unbedingt benötigt... .
sebulon schrieb:
Der Kunde kommt nochmal später wieder, will seine Produktpalette umstellen, braucht also Änderungen an der datenbank. Der datenbankentwickler designt neu, gibt die Änderungen an den Entwickler weiter, der passt seine Klassen entsprechend an und das läuft neu weiter.
Wirklich?
Da frage ich mich jetzt aber langsam wirklich WIE aufwendig ist das denn am Ende für den Kunde?
Wenn ein Kunde seine Produktpalette ändern möchte, was absehbar ist, dann schreibe ich ihm eine Administrationsumgebung wo er diese auch nach seinem Geschmack anpassen kann und zwinge ihn nicht die Firma zu kontaktieren, die ihm die Webseite gemacht hatte bzw. um diesen Shop erweitert hatte! -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
@master4860:
Ich sehe anhand deiner Aussagen, dass du bisher noch keine Praktischen Erfahrungen mit der Arbeitswelt hast.
1. ein Designer hat in der Regel nur mit sehr viel Glück ahnung von HTML/CSS, in der Regel darf das entweder der PHP entwickler mitmachen, oder es ist ein Extra Front-End-Dev eingestellt. der Designer mit HTML/CSS Kenntnissen wird in deinen PHP-Dateien nix ändern wollen. Also nix da mit mal schnell in die Zeilen reinschauen und änderungen machen, Erfahrungsgemäß kann dann ein PHP-Dev danach 2-3h die datei wieder debuggen, weil da alles zerschossen ist...
2. reden wir hier nciht von projekten, wo du mit 1000-3000 Zeilen fertig bist, wir reden hier von einem Projekt(webshop) welches Gerne mal auf über 1 mio Zeilen anwachsen kann auch hunderte Dateien verteilt. Ich hab den scheiss hinter mir, uralt-Code durchzuackern, der 20fach ineinander verschachtelt includiert wird(nicht mal mit require_once, um schleifen bei fehlbedienung zu vermeiden). Bei Projekten in der Größe teilst du alles schön säuberlich auf.
3. habe ich in meinem beispiel vergessen, die Situation des Bugs aufzuführen. Nimm an es ist ein bug. du identifizierst als erstes wo der herkommt. mit sauberem MVC schaust du erstmal: kommt er von der datenbank, der Geschäftslogik oder vom Design? dann setzt du dich ran und behebst den, weil du fast von alleine in die Datei reinlangst, wo der Fehler entstanden sein könnte. beim anderen ist es egal, du schaust so rein und ackerst tausende Zeilen Code durch, um herauszufinden, wo der scheiss herkommt.
4. Nur den Code in einzelne Dateien zu teilen ist kein MVC, wichtig ist die Ausführungsreihenfolge, die sich in der Reihenfolge Logik -> Daten -> Design durchexerziert, außer du machst es über JSON, hast du Clientseitig nochmal denselben Ritus.
-------------------------------------------------------------------------
so, jetzt kommen wir zum Sinnvollen Punkt. ich ging von einem frischen Team aus, ohne Codebasis etc. der Entwickler baut sich idR seine eigene Codebasis auf. hat er seine eigene Template-Engine geschrieben und dokumentiert, fällt der Schritt bei folgeprojekten weg und der Designer weiß schon wie er ranzugehen hat, weil er es kennt(sagen wir es wird BI-Software geschrieben)
Zu 1. was muss denn der PHP Entwickler rein "frickeln", das Design? Inwiefern, sollte das jetzt ohne MVC so umständlich sein?
Der Designer ist arbeitslos? Stopfst du jetzt den Fortschritt gesammelt in eine einzige Datei und währenddessen ist der Designer arbeitslos? Kann man doch wohl auch ohne MVC regeln...
nein, das ist Käse. hast du schonmal mit anderen Leuten zusammen an einem Projekt gearbeitet? Du brauchst saubere übergabeschnittstellen, wenn der Designer dem Entwickler nciht den ganzen Arbeitstag auf dem Schoß sitzen soll... dann werden die einfach kommuniziert und beim rest hätte der Front-End-Entwickler/Designer freie Hand, diese gelieferten Daten umzusetzen, ohne Syntaxkenntnisse von PHP zu haben oder zu wissen, wie die Daten gekapselt sind.
nehmen wir außerdem an, es gibt einen Umstieg von HTML5 auf 6, dann holst du dir deine Template-Dateien raus und modernisierst die, ohne dass der PHP-Entwickler belästigt werden muss.
------------------------------------
Fazit:
Auch wenn du es mir immer noch nciht glaubst, du sparst Massig Zeit hinten rum ein... sagen wir, da kommt ein 2. Kunde, der so einen Webshop haben will... die 2. erstellung würde mit dem Modell von bspw. 1 Monat auf 1 Woche sinken.
---------------------------------------
Wirklich?
Da frage ich mich jetzt aber langsam wirklich WIE aufwendig ist das denn am Ende für den Kunde?
Wenn ein Kunde seine Produktpalette ändern möchte, was absehbar ist, dann schreibe ich ihm eine Administrationsumgebung wo er diese auch nach seinem Geschmack anpassen kann und zwinge ihn nicht die Firma zu kontaktieren, die ihm die Webseite gemacht hatte bzw. um diesen Shop erweitert hatte!
So? Sagen wir du machst eine Seite für einen Waffenladen. Ursprünglich wollten die nur Handschusswaffen verkaufen, die sie herstellen, mittlerweile stellen die aber auch Panzer und schusswesten her. Wenn du sinnvoll anhand der Attribute die Produkte auflisten willst, musst du die Struktur anpassen und zusätzlich eine t_panzer in die Datenbank reinmodellieren... Den Kunden sowas machen zu lassen, läuft in 80% aller Fälle schief. ich hab mittlerweile mein Projektvolumen über 1 Mio gesamtauftragswert gebracht, unter unterschiedlichen Arbeitgebern. dabei war von organisiert-rechtschaffen bis chaotisch-böse alles dabei.
Und wenn du versuchst einen Webshop mit einem fertigen CMS aufzubauen, dann schönen schrank... du schreibst Module, die beim nächsten Update nciht mehr funktionieren, updaten musst du, um sicherheitslücken zu schließen und eine fertige Software für große Webshops daher zu nehmen ist grob fahrlässig. Ich musste auch schon einige primitive Webseiten Migrieren, weil sie Ziele von Angriffen waren, weil bekannte Software mit bekannten Sicherheitslücken genutzt wurde. Jetzt schreib mal nen Webshop, über den mehrere hunderttausend € Aufträge im Monat rübergehen und lass das ding mal gehackt werden... Weißt du, was da für schäden raus entstehen? und das nur weil du nicht sauber arbeiten wolltest? Wenn sowas passiert, dann war das der letzte Auftrag, den du bekommen hast...
Wir reden hier von Profi-Arbeit und nicht amateurhaften zusammenschustern einer seite durch einen Hobby-bastler ohne Schulabschluss... wenn das so einfach wäre, dann würden die seiten ja alle von schülern für wenige hundert € geschrieben werden und nciht von unternehmen für mehrere Tausend €...
Übrigens, ich hatte auch schon einige kollegen, die mit der Einstellung wie du gearbeitet haben... dann haben sich bugs eingeschlichen, durch die behebung dieser bugs kamen neue bugs usw... im Endeffekt hab ich mich rangesetzt, mehrere Wochen arbeit von denen in die Tonne getreten und neu angefangen, weil der Code komplett unbrauchbar war... Wenn du ein projekt hast mit über 3000 Dateien und keine Datei unter 800 Zeilen, dann wirst du langsam begreifen, warum man das so macht. Übrigens laufen CMS wie Drupal nach einem ähnlichen Prinzip ab... warum wohl? weil es wesentlich einfacher erweiterbar ist, ohne Kernmodule antatschen zu müssen...
und wenn du davon ausgehst, dass man bei jedem Projekt in bestehende Technologien neue Einarbeitungszeit braucht, solltest du dich vom Thema Webentwicklung verabschieden. nur mal schnell eine Seite hinrotzen kann jeder.
Aber zurück zum Ansatz. damit du das begreifst, musst du wohl dich selbst mal an ein Anspruchsvolles Projekt setzen. ich würde mal sagen, wenn du Interesse hast, das zu begreifen, dann schreibe ich dir mal eine Spezifikation, was die Software erfüllen soll und du hast mit deinen 3 Leuten 2 Wochen Zeit. Dann machen wir hier eine Gruppe auf, als Übungsprojekt, dann will ich mal sehen, wie ihr das Koordiniert. Das wird ein einfacher Shop werden mit ganz kleiner produktgruppe, Später mach ich eine Anforderung das Design betreffend und wenn das fertig ist, mach ich eine Anforderung, Das Shop-Angebot betreffend.
Wenn du das projekt durchziehst, kannst du 1. stolz auf dich sein, 2. weißt du, wie solche projekte idealerweise ablaufen(kundengespräche und den scheiss erlasse ich euch, normalerweise führt man diese Gespräche, um überhaupt die Anforderungen an die Software zu ermitteln) das machst du am besten ohne MVC, so wie du es vorstellst, und dann einmal ein ähnliches projekt mit MVC, von der Pike auf. ich denke, dann wirst du durch learning by doing darauf kommen, wie sinnvoll es ist. Übrigens können die Teams von Projektart auch mal größer sein... mit linearem Wachstum der Teams wächst bei konventionellem Vorgehen der Aufwand exponentiell, diese Projekte durchzuführen. Mit MVC wächst der nur linear, also aufwandstechnisch absolut überschaubar...
Beitrag zuletzt geändert: 13.6.2014 18:29:00 von sebulon -
sebulon, ich bin mir sicher das du wesentlich mehr Erfahrung hast wie ich se habe - vor allem mit großen Projekten.
Was ich immer noch behaupte ist das MVC bedingt Sinn macht, damit meine ich das nicht jedes Projekt es benötigt. Es ist mehr Aufwand und bei derart großen Projekten, wie du als Beispiel nimmst, gebe ich dir Recht das es sich später auszahlen wird!
Aber nicht für jedes simple bis mittelgroße Projekt. -
master4860 schrieb:
Was ich immer noch behaupte ist das MVC bedingt Sinn macht,
Dem hat Sebulon auch nicht widersprochen. Lies seinen Beitrag noch mal in aller Ruhe.
Er hat nur ein Szenario dargestellt, bei dem die Anwendung sinnvoll ist.
Wenn man auf den Threadtitel eingehen will und damit auf das ursprüngliche Thema zurückkommt, wäre die Antwort ein eindeutiges Nein.
PHP ist ursprünglich als Hilfsmittel zur Auslieferung von dynamisch erstelltem HTML gedacht. Es ist nicht sinnvoll, PHP und HTML komplett zu trennen. Sinnvoll ist es nur, die Teile des PHP-Scriptings, die nichts mit der Ausgabe von HTML an den Browser zu tun haben, vom restlichen Code zu trennen. Dank Classes kein Problem.
Hier wurde ja bereits Smarty erwähnt. Was macht das? Nichts anderes, als das, wofür PHP ursprünglich entwickelt wurde. Man bastelt HTML mit Platzhaltern, die von einer Engine geparst werden. Ob das nun durch Begrenzer/Platzhalter/usw. wie "{...}"oder "<?php...?> passiert, ist doch letztlich wurscht. Das Einzige, was zählt. ist das, was eim Betrachter ankommt. Wie das erreicht wird, liegt im Ermessen, der Werkzeugwahl und dem Budget des Seitenbetreibers und des Gestalters. Einen Grabenkampf muß man dafür nicht starten. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
