Blog - Hannes Pries - Webdeveloper Blog - Entwicklung mit Shopware, PHP, HTML5 und JavaScript

React mit Hooks.. echt praktisch

Manchmal hat man bei React trotz besserem Wissens sich Strukturen gebaut, die es schwierig machen, den Datenfluss sauber abzubilden. So passierte es plötzlich, dass in einer Child-Component etwas geändert wurde und diese Änderung es verlangte, dass in einer Geschwister Child-Component eine Liste neu geladen werden sollte. Diese Component lud die Liste von einer REST-API selber und bekam die Liste nicht von der Parent-Component. Doof. Per Callback wurde die Parent-Component von der Änderung unterrichtet, aber diese konnte das Neuladen ja nicht so einfach anstoßen, weil es an sich keine State-Änderung gab.

Man braucht ein Flag, dass sich ändert, wenn ein Refresh der Child-Component nötig wurde. Da reicht ein bool-Flag, das bei jeder Änderung seinen Zustand ändert.

Hier wird es einmal sehr gut erklärt, aber mit den neuen Hooks von React geht es sehr elegant umzusetzen.

Hier der Code aus der Parent-Component:

const[trigger,setTrigger] = useState(false);

return (
<>
<child1 onSubmit={() => {setTrigger(!trigger)}}/>
<child2 refresh={trigger}/>
</>
);

Damit child2 nun was laden kann muss man nicht mehr groß selbst prev-props mit next-props vergleichen sondern kann useEffect() verwenden:

useEffect(() => {reloadList()}, props.refresh);

Schön einfach und kompakt. Das man mit useEffect() direkt auf einzelne props/Änderungen reagieren kann, macht mir React schon sehr viel sympathischer. Erinnert mich an Watcher und Proxies aus Vue, nur sehr viel einfacher zu verwenden.

IDE einrichten für Einsteiger - Teil 2 - Tomcat

Java + Tomcat (Teil 2)

Nachdem wir uns im letzte Teil schon eine Entwicklungsumgebung für Java eingerichtet haben, können wir Desktop Anwendungen schreiben. Aber für Serveranwendungen benötigen wir einen Servlet Container oder einen Application Server. Für Microservices gibt es auch andere Frameworks, aber wir beschränken uns hier erstmal auf eine einfache JSP-Seite.
Ein kleines Servlet kommt auch noch hinzu. Man könnte auch direkt mit JSF anfangen, aber um sich mit dem Thema Webdevelopment in Java vertraut zu machen fangen wir ganz einfach an. Mit JSP und Servlet kann man auch alles bauen. Von einfachen Webanwendungen mit einzelnen Pages, über MVC-Frameworks bis hin zu REST-APIs. Für das meiste gibt natürlich fertige Frameworks, aber es in einem kleinen Beispiel mal selbst zu versuchen, bringt einen oft einen besseren Einblick in diese Bereiche und man versteht, die vorhandenen Frameworks besser und auch warum sie so funktionieren wie sie funktionieren.

Zuerst downloaden wir uns einen aktuellen Tomcat 8. Den Tomcat Servlet-Container gibt es schon seit vielen Jahren.. eigentlich seit Anfang an und entsprang dem Jarkata-Projekt von Apache. Ich bin 2004/2005 mit dem Tomcat 4 angefangenm wo noch alles unter Apache Jarkata tomcat lief und erst später dann mit der 5er Version zum Apache Tomcat wurde. Man wird aber den Begriff Jarkata noch oft genug bei den Libs und Klassen des Tomcat finden.

Download Apache Tomcat 8.0.x

Einfach die passende ZIP-Datei downloaden und an einen beliebigen Ort entpacken. Da wir alles über Eclipse steuern, müssen wir erst einmal da nichts weiter machen. Wer den Tomcat auch mal so ausprobieren möchte muss JAVA_HOME bei den Umgebungsvariablen von Windows setzen und auch den Pfad zum JRE (zum Bin-Verzeichnis) im Path von Windows hinterlegen. Dann kann man im Tomcat-Verzeichnis mit bin/startup.bat den Tomcat starten. Die einfache Startseite sollte dann unter http://localhost:8080/ aufrufen.

Aber jetzt zurück zu Eclipse. Wir laden unseren Workspace aus dem letzten Teil oder einen anderen den wir benutzen möchten. Wir öffnen Window -- Preferences -- Server - Runtime Environments.
Dort clicken wir auf Add..., um den Tomcat hinzu zufügen.

Wir wählen den Tomcat 8 aus und clicken auf Next. Dann wählen wir unser Tomcat Verzeichnis aus.

Wenn noch keine Server-View angezeigt wird, müssen wir uns diese nochmal hinzufügen.

Dort clicken wir auf den Link, um einen neuen Server hinzu zufügen. Da wir nur eine Runtime haben, wird uns diese auch direkt vorgeschlagen. Wir übernehmen alle Vorgaben und wählen Finish.

Damit haben wir unseren Server fertig eingerichtet und können nun zu unserem kleinen Beispiel-Projekt übergehen. Wir fangen ganz einfach mit einer JSP-Seite an, bei der wir ein Input-Feld für einen Namen haben, der dann an die Seite übergeben wird und diesen mit Hallo {name}! wieder ausgibt. Klassisch, einfach und die wichtigsten Dinge wie Forms, Request und Ausgabe sind dabei.

Wir brauchen ein Dynamic Web Project:

Das Projekt fügen wir auch gleich zu den Projekten hinzu die automatisch bei Änderungen neu auf dem Tomcat deployed (wichtiges Wort in der Java-Welt!) werden. Wenn also etwas geändert wird, wird Projekt einmal auf dem Tomcat entfernt und neu hinzugefügt, so dass die Änderungen über einen Webbrwoser betrachtet werden können. So etwas kann bei größeren Projekten paar Sekunden dauern.. aber zum Glück muss nur bei Java-Dateien neu deployed werden. HTML, CSS oder JavaScript Dateien erfordern kein erneutes Deployment und Änderungen sind einfach so verfügbar, weil direkt auf die Dateien zu gegriffen wird und nichts kompiliert werden muss.

Nun fügen wir uns eine index.jsp hinzu. JSP-Seiten werden im WebContent angelegt, um gefunden zu werden. Die index.jsp ist wie eine index.html und wird beim Aufruf verwendet, wenn keine andere Seite angegeben wurde. Das Verhalten kann man über eine web.xml definieren. Dort kann man auch Servlet-Mappings und Resources definieren. Aber so eine brauchen wir erst einmal nicht.

Auf die Seite kommt eine einfache Form und die Ausgabe des Namen, wenn im Request ein Name gefunden wird. Wir übergeben einfach mal den Namen per GET damit man sehen kann, wie der Parameter über die URL übergeben wird. Normal sollte man Form-Eingaben über POST übergeben. Aber die Änderung ist ja im Form-Tag schnell gemacht.

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Blog-Beispiel</title>
</head>
<body>
<%
if(request.getParameter("name")!=null && request.getParameter("name").length()>0){
%>
Hallo <strong><%=request.getParameter("name") %></strong>! <a href="index.jsp">reset</a>
<%
}
else{
%>
<form method="get">
<input type="text" name="name" /><br/>
<input type="submit" value="ok"/>
</form>
<%
}
%>
</body>
</html>

Aufrufen können wir diese Seite mit der URL nach dem Schema http://localhost:8080/{projectname}/ bei meinem Beispiel als http://localhost:8080/BlogTomcat/.

Eine JSP-Seite ist ja nur die Ausgangsdatei und diese wird in ein Servlet kompiliert. Servlets sind gerade für Dinge noch sehr gut, wenn man keine große Ausgaben hat, z.B. für Uploads, Downloads (mit vorherigen Benutzercheck) oder REST-APIs, die einfach immer ein Object in JSON umwandeln. Um schon mal ein Servlet gesehen zu haben erstellen wir unser Beispiel noch mal direkt als Servlet.

package de.hannespries.blog.ides.tomcat;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(name="nameservlet",urlPatterns={"/name"})
public class NameServlet extends HttpServlet{
private static final long serialVersionUID = 609957577169396811L;

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
String out="<html><head><title>Blog-Beispiel</title></head><body>";
if(req.getParameter("name")!=null && req.getParameter("name").length()>0){
out+="Hallo <strong>"+req.getParameter("name")+"</strong>! <a href="/name">reset</a>";
}
else{
out+="<form method="get"><input type="text" name="name" /><br/><input type="submit" value="ok"/></form>";
}
out+="</body></html>";
resp.getWriter().println(out);
}

@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
this.doGet(req, resp);
}
}

Das URL-Pattern ist hier sehr einfach gehalten. Man kann auch Wildcards und ähnliches setzen, was sehr praktisch ist, wenn man Werte in URLs einbauen möchte, was sehr gut für SEO ist. Beipsiel /service/item/2/ wobei 2 die Id des Item in der Datenbank ist und darüber geladen werden kann.

Wobei wir zum Thema Datenbanken im nächsten Teil kommen, wo wir uns eine Entwicklungsumgebung für PHP einrichten. Da auch dort Eclipse zum Einsatz kommt, sollte man auch wenn man sich nur für Java interessiert den Teil doch mal durchlesen und gerade der Bereich mit der Einrichtung einer MySQL-Datenbank ist interessant, wenn man eine Webanwendung im Tomcat entwickelt. Das Anlegen einer Datasource in der Config des Tomcats werde ich dort auch nochmal kurz erläutern.

curl auf Windows

Wer mal curl benötigt aber gerade nur Windows zur Verfügung hat, kann es sich leicht nach installieren. Oracle hat eine gute kleine Anleitung veröffentlicht.

Bei mir reichte es dir Schritte 3 und 4 auszuführen.

http://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/objectstorage/restrict_rw_accs_cntainers_REST_API/files/installing_curl_command_line_tool_on_windows.html

Kleine SEO Checkliste

Ein paar Dinge auf die Ich geachtet habe und am Ende wohl auch etwas gebracht haben. Jedensfalls gehen Klicks und Impressions seit den Änderungen weiter nach oben. Jetzt nicht so dass man dieSeiten als erfolgreich bezeichnen könnte.
Aber die Seiten werden gefunden!

* ist der Viewport über ein <meta>-Tag gesetzt? (Wegen Mobile-frundlichern Setien und Google)
* Hat der Title alle 4-5 wichtigen Keywords und ist auf für Menschen noch gut lesbar? (kein zu langer Name am Anfang!)
* enthalten Links als Text und Title Keywords?
* Wird Mapping über Rewrites verwendet um nciht immer auf index.php oder zu verlinken? (in der URL Keywords verwenden)
* werden <nav>-Tags verwendet?
* werden <article>,<header>,<section> Tags verwendet? (Gerade bei Blogs und Newsseiten)
* Ist der meta-Description Text für Besucher ansprechend? (Der Text ist eher für Menschen als für die Suchmaschinen-Bots)
* Wurde eine Sitemap bei Google eingereicht?
* sind die Ladezeiten der Seite ok? (nicht so wichtig, aber ist für die Besucher schöner. Zur Not.. Profiling und Code-Analyse)

Projekte bewerten und abschalten können

Was gibt es für Gründe ein Side-Project zu haben? Spaß, Lernen, Angeben, als Referenz verwenden und vielleicht ja auch etwas Geld damit verdienen. Der letzte Punkt ist irgendwie immer mit dabei, aber man weiß selbst wie unrealistisch der doch ist. Ich gehe mal davon aus, dass 50% der angefangenden Projekt nie weiter weiter als Prototyp-Status kommen wird.
Meistens hat man dann einen Beweis, dass etwas funktioniert oder nicht funktioniert. Im besten Falle hat man bei Facebook einen Link gepostet, der sagt: "Guckt mal, so etwas ist doch in relativ kurzer Zeit zu machen.. mal gucken ob ich das zu einer echten Anwendung ausbaue". In 50% dieser Fälle wird man es nicht machen. Oft ist die Idee doch nicht so gut, oder die Zeit fehlt.
Auch ist vielleicht die Idee gut und die Zeit wäre auch da, aber es gibt so eine Anwendung schon und weiß nicht, ob man die Zeit dann doch nicht lieber für was anderes verwenden sollte.

Also werden schon 75% alles Projekte von einem sowie nie zu Ende gebracht bzw vorher aussortiert.

Aber dann bleiben die 25% übrig, die man dann wenigstens soweit bringt, dass sich jemand das angucken kann oder man versucht die erste Version einer App irgendwo einzureichen. Hier trennt sich dann der Rest. Wenn die App oder Website nicht angenommen wird, verschwindet auch diese in der Versenkung. Aber ganz so einfach klar und einfach ist es an dieser Stelle dann doch oft nicht.
Man könnte ja nochmal nachbessern oder die Präsentation ist nicht gut genug. Gerade im Bereich vom Webdevelopment mit Websites und Web-Apps muss man sich gleich richtig präsentieren. Eine kryptische Subdomain? Damit findet doch niemand die Seite und wirklich seriös wirkt es damit auch nicht. Also erst einmal eine Domain bestellen. Domains sind zum Glück ja günstig. Erstes Jahr meistens nur 12 Euro. Dann braucht man noch die Zeit, damit Google die Seite crawled und in den Index aufnimmt. Danach muss man abwarten wie sich alles entwickelt. Das dauert natürlich viel zu kurz, um fest zu stellen, ob das Projekt eine Zukunft hat oder nicht. aber die Zeit ist auch zu lang, um das Rückgaberecht in Anspruch nehmen zu können.

Irgendwann guckt man auf seine Rechnung und guckt mal wie viel man Zahlt und wie viel wirklich einen noch was bringt oder einfach schon tot ist.

Privat hat man einfach zu wenig Zeit, um sich um viele Projekte zu kümmern und man kann die Zeit nicht so einteilen, dass alle Projekte wirklich die Aufmerksamkeit bekommen, die sie bräuchten.
Die neuen Projekte sind spannender und und durch die eigene Erfahrung auch viel leichter zu pflegen. Die alten sind nicht so toll. Gleiche Änderungen brauchen viel mehr Zeit und Aufwand. Also lässt man die lieber erst einmal so wie sie sind und sagt sich, dass man die noch mal komplett überarbeiten wird.
Projekte die man selbst nicht mehr pflegt, die auch von niemand anderen verwendet oder besucht werden, verbrauchen am Ende nur Geld. PHP 5.2 zu verwenden kostet bei einigen Hostern Geld. Ältere PHP Versionen auch. Wenn man also nicht mindestens auf PHP 5.5 wechseln kann, kostet es noch mehr Geld als eine Domain.

Private Side-Projects zu haben ist toll. Man lernt viel, zeigt sich der Welt, sieht mal eine andere Welt als die Enterprise-Welten bei der Arbeit. In Bewerbungen gehören diese Projekt schon eigentlich mit dazu. Man kann sich auch mal mit neuen Technologien befassen, die für einen ernsthaften Einsatz noch zu "neu" sind.

Aber diese Projekte sollen auch nicht Zeit und Geld rauben, wenn klar ist, dass sie keinen der oben genannten längerfristigen Ziele dienen. In Bewerbungen kommen alte Projekte nicht gut, weil man sich ja möglichst von der neusten und tollsten Programmierer-Seite zeigen möchte. Das man früher mal schlechten Code produziert hat glaubt einen jeder auch ohne einen Beweis dafür gesehen zu haben.

Jeder hat mal JavaScript ohne Closures geschrieben. Funktioniert wohl auch alles noch gut, aber zeigen mag man es dann doch auch nicht mehr so wirklich. Ich müsste da auch noch mal ein alte Projekte
überarbeiten.

Also.. auch wenn es einem schwer fallen mag, alten Projekte aus dem Internet entfernen. Bei mir waren mp4togif.com und webm-maker.com so ein Fall. Die erste Anwendung lief nicht schlecht, aber sie waren alt und optisch so wie bedienerfreundlich nicht ganz auf der Höhe meines Könnens. Webm-Maker konnte mehr, lief auf mobilen Geräten und war einfach sehr viel besser strukturiert und entwickelt worden. Nur die
Domain war wirklich brauchbar. Also die Anwendung gelöscht und durch eine Kopie des Webm-Maker Codes ausgetauscht. Seit dem läuft es ganz ok und ich überlege eher die Webm-Maker Seiten wieder einzusparen.

Andere Domains wo nur noch Test-Projekte liefen oder auch die einfach durch Namenswechsel nicht mehr aktuell waren und nicht wirklich benutzt wurden, habe ich dann auch vor kurzen gekündigt. Über 24 Euro mehr im Jahr sind jetzt nicht so viel, aber einmal Pizza bestellen oder einmal klein Essengehen sind da schon drin.

Wenn Projekte schon kein Geld oder Spass/Freude/Erkenntnis bringen, sollen sie auch kein Geld verbrauchen.

Jedes halbe Jahr sollte man die eigenen Projekte nochmal bewerten und gucken, welche keine Zukunft haben und wo man sparen kann. Das ist privat genau so sinnvoll wie bei Firmen. Hier sollte man so denken als wäre man eine kleine Firma und auch mal etwas wirtschaftlich denken.

Frameworks schreiben.. aber richtig

In meinen 11 Jahren habe ich schon einige Frameworks geschrieben. Ich mag Frameworks und lieb es so etwas zu entwickeln. Aber Frameworks sind schwer richtig zu entwickeln. Die meisten Framework-Entwicklungen Enden ohne etwas Brauchbares in der Hand zu halten. 50% der Frameworks, die ich im Laufe der Zeit geschrieben habe waren einfach Schrott.
Neben diesen gibt es dann die, die am Ende nutzlos sind. Das kann damit zusammen hängen, dass die Vorteile und die Arbeitszeitersparnis einfach nicht eintreten. Die wirklich brauchbaren kann ich an paar Fingern abzählen. Aber auch viele große Frameworks haben ihre Probleme, es ist also kein Problem was nur die Arbeit einzelner Entwickler oder kleiner Gruppen betrifft. Ein gutes Beispiel für so ein Framework ist JavaFX 1.x. Viele Ideen, viel Arbeit wurde investiert und am Ende wollte es niemand verwenden. JSF 1.x war auch noch weit davon entfernt wirklich rund zu laufen bei der Entwicklung und zeigte oft Unzulänglichkeiten. Allein dass mit Tomahawk alle möglichen HTML-Tags wie DIV nochmal für JSF implementiert wurden, weil es kaum möglich war JSF und HTML sinnvoll zu mischen.
Aber das Scheitern großer Frameworks soll hier gar nicht das Thema sein. Es soll darum gehen, wie man es richtig macht bzw. wie man weniger falsch macht.

Ich hatte vor einiger Zeit APF2 (annonyme php framework 2) angefangen. Es sollte alles richtig machen was ich bei aoop falsch gemacht hatte. Es sollte nicht der Content direkt raus geschrieben werden beim Funktionsaufruf. Es war so nicht möglich über den Content-Bereich aus den Title zu ändern und so war auch die Möglichkeit nicht da einen Titel eines Blog-Post zu setzen, wenn man den BLog-Post geladen hatte, weil dann der HTML-Head schon gesendet worden war.

Es sollte ein richtiges Routing haben, um so zum Zend Framework 2 aufschließen zu können. Damit sollte SEO einfacher werden, weil nicht alles auf die index.php ging.

APF2 ist tot. Es fehlte einfach viel was aoop schon hatte, denn ein unvollständiges Framework ist sinnlos und aoop zu "reparieren" ging schneller als gedacht. Alles komplett neu und besser zu machen braucht viel Zeit und man kann es nicht alles besser machen und dabei kompatibel bleiben. ZF1 zu ZF2, JSF 1.x zu JSF 2.x, AngularJS 1.x zu AngularJS 2.x.. JavaFX. Ein Framework neu zu schreiben lohnt sich nur wenn man auch etwas komplett neues damit entwickeln will. Das Framework nur neu zuschreiben und die darauf basierende Anwendung portieren zu wollen endet eigentlich immer damit dass man die Anwendung auch fast komplett neu schreibt. Man hat ja damals nichts auf Hinsicht eines neuen noch nicht existenten entwickelt. Deswegen werden alte Framework Versionen auch ewig weiter gepflegt, weil das Portieren auf ein komplett neues Konzept nicht so einfach möglich ist, weil man sich eben auf das alte Konzept eingelassen hat und sich daran orientiert hat bei der Entwicklung.

Also der erste Punkte: Man muss für die Zukunft etwas neues machen und nicht versuchen alte Sachen zu reparieren. Eine neue Version ist auch ein neues Framework.

Auch die Frage, ob es in einem bestimmten Bereich wirklich ein noch ein weiteres Framework braucht, dass wieder nur Nuancen anders macht. Ja.. die Konzepte sind alle sehr ähnlich, die meisten kommen bei den selben Problemen zu den selben Lösungen. Es gibt viele Lösungen aber nur wenig gute und man ist nicht so genial, dass nicht auch viele andere zu der Lösung kommen. Außerdem ist man durch viele bekannte Konzept schon so geprägt, dass man diese auch aufgreifen wird. MVC und MVVM... am Ende kann
man noch so viel nachdenken.. die Konzepte sind schon gut. MVC, MVC2 oder MVVM sind auch sehr ähnlich und oft ist es auch Interpretation ob nicht eines der Konzepte, dass andere schon vorweg genommen hat und es nur nicht in der Masse erkannt wurde.
Würde ich heute noch cJS neu entwickeln? Nein. Es funktioniert echt toll und als ich vor paar Tagen mp4togif.com doch mal wieder erweitert habe, ging es einfach, schnell und problemlos. Aber AngularJS kann das auch alles und noch mehr und gerade das Handling von Arrays "item.name for item in items tracking by item.id".. so eine kleine Sache macht es für mich so toll. Das Wichtigste ist aber, dass AngularJS aktiv und mit soviel Man-Power weiter entwickelt wird, wie ich es nicht neben bei leisten könnte. Ich entwickle aoop aktiv weiter. Das ist schon viel Arbeit.

Also Punkt Nummer 2: Wenn man nicht die Zeit hat es durch gehend weiter zu entwickeln, sollte man es lassen und eines von jemanden verwenden, der oder besser die die Zeit investieren. Also auch mal an die Framework Entwickler denken und diese auch bei Gelegenheit etwas unterstützen. Denn die geben ihre Arbeit meistens kostenlos ab und sparen uns damit so viel Zeit, die wir wieder in etwas investieren, mit dem wir Geld machen oder es jedenfalls hoffen mal Geld zu machen :-)

Aber was ist, wenn es kein anderes Framework gibt, das das macht was ich brauche? Dann sollte man versuchen möglichst viele Leute zu finden, die es verwenden und somit den Bedarf schaffen, Zeit zu investieren. Gerade in Teams mit einem eigenen Framework (bei mir war es eins um XML-Templates in PDFs umzuwandeln, man also kein iText lernen musste sondern HTML und CSS reichte) muss es sich wirklich durch setzen. Wenn man nicht den Rückhalt hat, wird jede investierte Zeit als verschwendete Zeit gesehen.
Wenn man HTML + CSS Templating für ein Team entwickelt, dass zum großen Teil nie mehr als Java-Code und dort nur SWT für GUI gesehen hat, hat man schon einmal einen schlechten Start. Wenn das Framework dann besonders schnell entwickelt wurde, an einigen Stellen noch Probleme hat und nicht besonders schnell ist, hat es es sehr schwer sich jemals wieder von diesem Ruf zu erholen.
CSS ist teilweise etwas undurchsichtig und wenn sich dann Entwickler nicht merken können ob # nun sich auf eine Id oder eine Class bezieht, hat das Framework einfach keine Chance.

Damit wäre Punkt 3: Das Framework muss von den Entwicklern benutzt werden können. Wenn man nur ein Framework für sich selbst schreibt, scheint dieses egal zu sein, aber man weiß nie, ob nicht doch jemand anderes mal ein Projekt von einem übernehmen wird. Wenn man in einem festen Team arbeiten, muss man sich nach dem Wissen und den Vorlieben des Teams richten, damit das Framework angenommen wird.

Wenn wir nun ein neues Projekt mit einem Framework beginnen wollen, wollen wir nicht erst einmal viel Doku lesen oder einrichten müssen. Wir wollen (ich gehe mal vom Webbereich aus) das Framework deployen, es aufrufen und eine kleine Seite sehen. Vielleicht weißt das Framework einen nochauf eine fehlende Datenbank-Verbindung hin. Was wir an sich nicht machen wollen ist, den Server erstmal umständlich konfigurieren zu müssen. Erstmal die Config des Tomcats oder Apaches ändern zu müssen nervt. Wenn wir aber nun das Framework an sich zum Laufen bekommen haben, wollen wir unsere Anwendung anfangen zu entwickeln. ZF2 braucht gefühlt sehr viel Konfiguration und es müssen viele Dateien angelegt werden. Die Modul-Klasse, das Mapping des Namespaces, das Laden der Config-Dateien, was man alles in PHP umsetzen muss. Als Anfänger hat man sehr damit zu kämpfen, wil man oft auch nicht genau weiß, in welcher der Dateien nun was noch mal stand. Default-Werte sind unbekannt und die endlose Verschachtelung der Arrays ist
alles andere als übersichtlich.
Ich habe ein SWT-Framework erlebt wo man erst einmal 5 Klassen ableiten musste, mindestens 6 Methoden überschreiben sollte, die aber auch nicht abstract waren und man sowie so noch alle möglichen Pfade und Klassen an den richtigen stellen anpassen musste. Das war schon keine Konfiguration mehr sondern wirkliches Ändern und Anpassen von elementaren Code-Teilen.
Ein Update auf eine aktuellere Version des Frameworks,war also auch kein einfaches Kopieren von Dateien sondern man musste wieder den Code anpassen und hoffen, dass es immer noch die selben Stellen waren, wo es zu ändern war.

Punkt 4: Die Installation sollte an sich lauffähig sein und das Anlegen eines eigenen Moduls oder ähnlichen sollte über eine einzige Datei möglich sein. Diese Datei sollte kein Programm-Code sein und deutlich strukturiert sein. Auch Default-Werte sollten immer vorhanden sein, falls man einen Wert nicht in der Config setzt.

Und gleich Punkt 5 dazu: Wenn man ein Update macht sollte man die Dateien einfach kopieren können ohne eine der Dateien ändern zu müssen oder Angst haben zu müssen die momentane Config ausversehen wieder mit der mitgelieferten Default-Config zu überschreiben. Am besten ist ein zentrales Verzeichnis für die Config und dass ohne Inhalt einfach auf die default-Config zurück springt.

Fazit: Wenn man diese Punkte beachtet, steigen die Chancen, dass das eigene Framework brauchbar ist und auch von anderen Entwicklern angenommen wird. Zusätzlich sollte das Framework natürlich gut, schnell und möglichst fehlerfrei sein. Aber meistens scheitert das eigene Framework einfach daran, dass man zu wenig Zeit investiert, nur auf den momentanen eigenen Bedarf hin entwickelt und sich zu wenig Gedanken macht wie man selbst oder andere beim nächsten Projekt damit einen möglichst einfachen und entspannten Einstieg haben.

Virtualhost im Apache einrichten

Wenn man lokal entwickelt muss man sich oft eine Subdomain für "localhost" einrichten. Das ZF und ZF2 sind am liebsten so installiert und Folders in einer Domain funktionieren nicht immer ganz so gut. Außerdem kann man dann so einfach alles auf die produktive Domain kopiren ohne die htaccess anpassen zu müssen.

So etwas einzurichten ist auch ganz einfach. Es geht in der httpd.conf oder man richtet sich die extra/httpd-vhost.conf ein.

<VirtualHost *:80>
DocumentRoot "C:/workspaces/php/projectXYZ"
ServerName xyz.localhost
ServerAlias www.xyz.localhost
<Directory "C:/workspaces/php/projectXYZ">
DirectoryIndex index.php
AllowOverride All
Require all granted
</Directory>
</VirtualHost>

Mit AllowOverride erlaubt man das Verwenden von Rewrites

Angular und native Forms

Wer mal eine <select> mit Angular gefüllt hat, kennt das Phenomen, dass die Ids nicht im Value der Option stehen sondern über Angular später gesetzt werden sollen. Wenn man mit ng-model arbeitet ist das auch alles kein Problem. Nur wenn man das <select> klassisch über eine Form submiten möchte kommt es zu Problemen.

ng-options="item.id as item.name for item in items"

Was hilft ist das hier

ng-options="item.name for item in items track by item.id"

Damit wird nicht mehr der Index des Arrays verwendet sondern wirklich die Id aus dem Objekt.

CSS Frameworks

In der letzten Zeit habe ich mit CSS-Frameworks zu tun gehabt. Bootstrap, Foundation und UIKit. Mit Bootstrap hatte ich ja schon etwas länger Kontakt. Foundation jetzt so 3 Wochen und UIKit 2 Tage. Bootstrap gefällt mir von der standard Optik aber immer noch am Besten. Bei UIKit gefallen mir die mitgelieferten Icons. Foundation macht was es soll, aber sieht mir an einigen Stellen doch zu sehr nach plain-HTML aus und die Dokumentation sagt mir am wenigsten von den Dreien zu.

Aber am Ende machen doch alle drei genau das Selbe und das auch sehr ähnliche Weise. Was ich mit dem einen hinbekomme, kann ich ohne große Probleme auch mit den anderen erledigen. Oft muss man nur die CSS-Class's austauschen.

Ob man nun soviele ähnliche Frameworks braucht lasse ich mal dahin gestellt und versuche erstmal für mich heraus zu finden, welches ich nun als primäres verwenden sollte.

HHVM und PHP7

Der erste Release Candidate von PHP 7 ist verfügbar und der auch von HHVM gibt es eine neue Version. Ich würde mir beides gerne mal ansehen. Aber ich habe nicht die Zeit mir alles komplet einzurichten und mir noch extra ein Linux zu installieren. Ich benutze Windows und werde auch erstmal dabei bleiben. Also fällt leider HHVM schon mal für einen kurzen Test raus. Aber PHP7 ist für Windows verfügbar und auch Bitnami bietet schon ein WAMP-Paket mit PHP7 an. Also werde ich mir das in den nächsten Tagen mal ansehen. Einmal kurz gucken, ob aoop darauf funktioniert oder nicht. Ich bin mal gespannt.

User	annonyme	Date	2016-01-10 15:44
Tags	curl, hannes pries, openssl, oracle, tipp, webdevelopment, windows

User	annonyme	Date	2015-08-27 19:11
Tags	bitnami, entwicklung, hannes pries, hhvm, php, php7, webdevelopment

Hannes Pries - Web/Shopware/JavaScript-Developer BlogWeil es immer eine simple Lösung gibt!

Hannes Pries - Web/Shopware/JavaScript-Developer Blog
Weil es immer eine simple Lösung gibt!