Die checkLicence()-Methode prüft, ob ein Plugin eine gültige Lizenz hat oder nicht. Dafür wird wiederum das Licence-Manager Plugin verwendet. Shopware selbst rät eher davon ab dieses zu verwenden. Sie meinen, dass ein Kunde schon keine Raubkopie verwenden möchte und ungern von Updates abgeschnitten wird.
Bei einigen Plugins sind die Updates nun wirklich minimal umgesetzt. Mal ein paar kleine Schönheitsfixes.
Warum gehe ich lieber das Risiko ein, dass man eine Test-Version länger als gedacht verwendet als zu viel Sicherheit einzubauen?
- Weil ich selbst weiß, dass Test-Zeiträume oft zu gering sind.
- Weil ich die Sicherheitsmaßnahmen von Shopware für ausreichend halten
- Weil meine Plugins im Namespace abzuändern. von der Arbeitszeit oft teurer wäre als es zu kaufen
- Weil ich nicht nur Fixes in Updates habe, sondern Updates bei mir oft auch Features nachliefern oder verbessern (erste Versionen waren oft nicht ansatzweise so umfangreich wie die momentanen Versionen)
Es ist wie mit dem Wasserzeichen auf mp4togif.com. Es nervt und man kann es relativ einfach und ohne viel Einschränkungen entfernen. Meine Plugins sind relativ günstig. Bekommen oft neue Features und ich versuche möglichst guten Support zu leisten.
Sollte sich nichts mehr verkaufen, würde ich auch nicht mehr weiter entwickeln.
Da das Preis/Leistung Verhältnis bei meinen Plugins, glaube ich, stimmt, bin ich auch relativ sicher, dass die Shopbetreiber bereit sind das Geld zu zahlen und weiterhin von der Weiterentwicklung partizipieren zu können. Besonders auch weil ich für jeden Verbesserungsvorschlag dankbar bin und diese auch gerne für Kunden umsetze.
PS: bald veröffentliche ich mal wieder eine aoop-Version, da dort in den letzten Tagen nach langer Zeit wieder mal was passiert ist und ein neues Projekt damit ansteht.. und nicht mit WordPress.. weil das zu unflexibel ist für den Zweck :-)
Zeitmessungen bei Rennen müssen nicht immer mit RFID gemacht werden. Man kann auch ganz einfach einen PC, ein Tablet oder ein Smartphone pro Messstation nehmen und eine Person muss nur auf die Teilnehmer-Nummer klicken/drücken, um eine Messung zu speichern.
Für die meisten Rennen im Amateurbereich ist die Genauigkeit mehr als ausreichend. Also ein vollständiger Ersatz für Stoppuhren oder andere Smartphone-Apps, die man sonst für Kontrollmessungen verwenden würde.
Und alles natürlich dann in Echtzeit auf dem Server.
Die nächsten Wochen und Monate werden sehr stressig. Meine Pläne sind:
- Umziehen und Renovieren (vielleicht mit Blog-Post über Netzwerk, Server und Überwachungskameras)
- Ein einfaches Shopware Plugin in den Community Store zu bekommen (Das Plugin ist so gut wie fertig.. jetzt kommt die Upload-Theorie* .. schlimmer als der App-Store für Firefox OS kann es sicher nicht sein)
- Einen kleinen aber etwas speziellen Shop online bringen (ich werde berichtigen wie es läuft und ob es am Ende erfolgreich war)
- Zwei Termine mit dem Switch GmbH Time-System stehen an, wo ich auch Blog-Post und so liefern werde.. mehr als letztes Jahr
- Ein Video über die manuelle Zeitmessung mit dem Time-System
- Und nach dem Umbau der letzten 3 Monate am aoop PHP-Framework mit MVC, neuer Verzeichnisstruktur, PHP 7, Namespaces, Composer-Autoloader, etc müsste ich wirklich mal eine neue Version releasen.. ich bin doch relativ stolz auf die neue Version ,weil sie doch etwas ist was man als modern bezeichnen kann
Gehen wir mal davon aus wir erstellen eine Homepage für eine Restaurant-Kette mit 3 Restaurants. Die Seite soll so gebaut sein, dass Mitarbeiter der Restaurants einfache Datenänderungen vornehmen können, ohne dafür um Hilfe fragen zu müssen. Auch sollen Änderungen im Layout einfach und schnell möglich sein, dass aber nicht durch die Mitarbeiter, da diese wohl kein HTML beherrschen.
Jedes Restaurant hat eine eigene Unterseite, die vom Aufbau aber immer gleich sind.
Das Problem ist, dass wenn es Änderungen im Layout dieser 3 Seiten geben soll, müssen die Änderungen auch in allen 3 Seiten getätigt werden. Ein einfaches Kopieren geht natürlich nicht, da man sonst ja die individuellen Texte und Bilder überschreiben würde. Die speziellen Öffnungszeiten für Feiertage einzutragen ist nicht ganz so kompliziert, wenn man einen WYSIWYG-Editor hat. Aber einfacher wäre es natürlich, wenn diese Angaben atomar eingegeben werden können und so auch nicht die Gefahr besteht, durch Fehler die gesamte Seite durcheinander zu bringen.
Ich habe für mein Framework/CMS diese Lösung entwickelt. In dem Code der Seite sind Platzhalter eingebaut, die heraus geparst werden und mit individuellen Werten gefüllt werden können. Daher kann man einfach eine vorhandene Seite kopieren und muss nur die im Formular ausgewiesenen Platzhalter neu füllen. Das Layout zu Ändern geht auch einfach weil man den Code wirklich mit Copy und Paste in alle Seiten übernehmen kann, ohne Werte zu überschreiben.
Man hätte natürlich auch Entitäten und Controller mit Templates bauen können. Aber für solche Zwecke ist das oft vom Aufwand her nicht gerechtfertigt, weil die verwendete Zeit nicht entsprechend bezahlt werden würde und mit dieser Lösung es wohl auch schneller geht.
Und für die einfachen Benutzer ist es so auch viel übersichtlicher und sie können dann bestimmt mehr alleine Ändern, weil sie nicht der Content der gesamten Seite erschlägt.
Während ich in den letzten 3 Jahren bei aoop immer mehr Framework-Charakter im Vordergrund gesehen habe und den CMS-Teil davon mehr oder weniger komplett vernachlässigt habe (bis auf die Integration von TinyMCE und Code-Mirror), habe ich jetzt mal wieder angefangen in die Richtung etwas zu tun und die ersten Änderungen sind schon aus dem Feature-Branch in den Master gewandert.
Seiten sind nun Grids mit Content-Modulen als Inhalt. Der Vorteil von so einem Grid ist, dass es responsive ist und so die Anpassung für Mobile-Devices sehr vereinfacht wird. Während in der Desktop-Ansicht man das Grid sieht wird bei der Unterschreitung einer gewissen Breite einfach alles untereinander angeordnet. Momentan verwende ich das Grid von Bootstrap, weil man dieses auch allein super in vorhandene Templates integrieren kann ohne Angst haben zu müssen, dass das Design oder Layout Schaden nimmt.
Der Editor nutzt auch das Grid um eine brauchbare Vorschau zu liefern.
Dieses neue Seiten-Model und der dazu gehörige Editor werden nie den Umfang und die Qualität der Shopping Worlds in Shopware. Ich überlege ein Modul zu schreiben, das ähnlich wie das Digital Publishing in Shopware repsonsive Banners ermöglicht, aber auch hier natürlich nicht in dem Umfang, sondern in einer einfachen und grundlegenden Version.
Wenn ich eine Lib oder ein Framework sehe, kommt bei mir immer die Frage auf: "Wie macht man so etwas?" Das gipfelte heute darin, dass ich ein kleines Logging-Framework geschrieben habe. Etwas an
Log4j erinnernd aber erst einmal nur mit Output in eine Datei. Andere Outputs könnte man noch integrieren durch Appender-Types.
Die LoggerFactory
class XWLoggerFactory{
private static $config=[];
private static $appenderCache=[];
/**
* @return XWLogger
* @param string $clazz
*/
public static function getLogger($clazz){
if(count(self::$config)==0 && file_exists("system/config/log.json")){
self::$config=json_decode(file_get_contents("system/config/log.json"),true);
foreach(self::$config["appenders"] as $appender){
self::$appenderCache[$appender["name"]]=$appender;
}
}
$appenders=[];
$levels=[];
foreach(self::$config["classes"] as $cla){
if(preg_match("/^".$cla["name"]."/i", $clazz)){
foreach($cla["appenders"] as $app){
$appenders[]=self::$appenderCache[$app["name"]];
$levels[]=$app["level"];
}
}
}
return new XWLogger($clazz, $appenders, $levels);
}
}
Nach 9 Jahren geht es mit aoop doch mal los. Ein weiters Projekt mit meinem Framework startet morgen. Es basiert auf der neusten Version mit dem Blog-Modul.
Ich bin auch technischer Admin und betreue alles auf technischer Ebene. Logos und Design stammen von meiner Frau und sind wirklich toll. Wer es sich mal ansehen möchte findet es unter http://www.tentacle-news.net.
heute habe ich meinen ersten Test mit PHP 7 durch geführt. 1&1 ist so nett und bietet für jeden schon an PHP 7.0RC3 einzustellen. Ich hab mir eine Subdomain angelegt und diese auf PHP 7 konfiguriert. Ich wollte mal sehen, ob mein System mit PHP 7 läuft oder ich noch etwas ändern muss. Bis jetzt lief meine Homepage produktiv mit PHP 5.5 und wurde mit 5.6 entwickelt. Bei PHP7 fallen ein paar Altlasten weg, die man eigentlich schon vor Jahren hätte mal anpassen sollen. Das hatte ich vor paar Wochen gemacht:
Die alten Konstruktoren durch __construct() ersetzen. Ich weiß nicht warum die alten nicht mehr untersützt werden sollen in Java funktioniert die Art und Weise super und auch mit PHP hatte ich keine Probleme.. ist aber eben jetzt anders
Die alten msyql-Function sind nun nicht mehr dabei. Aber dafür gibt es noch die mysqli-Funktionen (auch in Form von Klassen für OOP). Da alles in einer Klasse gekapselt war, bedeutete das nur die Klasse zu kopieren und an jedes "mysql" ein "i" ran zuhängen. Also in 2 Minuten erledigt. Selbst ein automatisches Replace über alle Dateien hätte funktioniert.
Mehr hatte ich nicht geändert und es lief unter 5.6 alles sehr schnell und stabil. Dann folgte der Test auf PHP 7.. und es lauft. Gefühlt ist es immer noch stabil und schnell. Performance-Messungen habe ich noch nicht gemacht, aber werde in den nächsten 1-2 Wochen wohl mal welche nachreichen.
Fazit Ich glaube es wird kaum bis wenige Probleme beim Wechsel geben, wenn der Code strukturiert ist und nicht seit 10 Jahren nicht mehr angefasst wurde. Das "Problem" mit den mysql-Funktionen klingt schlimmer als es ist bei alten Legacy-Code wo die DB-Queries wild im Sourcecode verteilt sind. Ein Replace und es ist erledigt, das Schlimmste was passieren kann ist das man ein paar Kommentare mit umbenennt. Also keine Angst haben und einfach mal ausprobieren.
Ich hab nach einiger Zeit jetzt doch mal das Blog-Module überarbeitet. Neben einer besseren Performance und der Möglichkeit im Framework, jetzt auch gezielt aus einer Page heraus den Title der HTML-Seite zu setzen, gibt es jetzt auch eine Kommentarfunktion, jetzt von jedem Bensucher benutzt werden kann. Es gibt nun auch die Möglichkeit Beiträge zu schreiben, die auf der Übersichtsseite nur mit einem kurzen Text angezeigt werden und der gesamte Text erst, wenn man dem Link auf den Beitrag folgt. Ich mag eigentlich wenn man nicht extra klicken muss, um einen Beitrag ganz zu lesen, aber wenn sehr viel Quellcode darin ist, kann es doch wohl sehr hilfreich sein.
Als nächstes folgt eine bessere Integration von Bildern und Videos.
Das Theme der ganzen Seite hatte ich ja schon vor kurzen angepasst und es sieht nun auch etwas moderner alles aus. Das alte dunkle Theme gefiel mir auch eher nicht mehr. Das neue wirk auch irgendwie einladener.
Ich hoffe dass damit jetzt alles noch ein Stückchen professioneller wird (obwohl es nur meine private Homepage ist) und auch die Google-Suche nun etwas besser mit allem hier zurecht kommt. SEO ist ja doch schon eine Wissenschaft für sich.
PS: eine neue Version von aoop, auch mit dem neuen Blog-Module werde ich in den nächsten Tagen zum Download bereit stellen.
REST-Services sind ja nicht mehr neu und haben gerade die klassischen WebServices (SOAP) an vielen Stellen ersetzt. Wer mal mit SOAP, auch auf einen niedrigeren Level, gearbeitet hat, wird dies nicht als Verlust sehen. Es gibt viele Frameworks für REST-Services und auch lassen sich die meisten anderen Frameworks ohne Probleme so anpassen, dass sie keine HTML-Seite zurück liefern sondern das Ergebnis als JSON. XML wäre auch möglich als Ausgabeformat, aber ist sehr sehr wenig verbreitet. XML ist meistens sehr viel größer, da "name":"value" viel kürzer ist als <name>value</name> oder <attribute name="name" value="value"/>.
Meine Erfahrungen mit dem Parsen von XML und JSON in PHP ist aber, dass beide eigentlich gleich schnell sind. Ein Wechsel bei Config-Files von XML auf JSON hat keine Verbesserung der Ladezeiten ergeben. Auch die Serialisierung von Objekten bei Java war mit JSON nur minimal schneller als mit XML, wobei es dort auch sehr vom Verwendeten Framework abhängig war. Also kann es sein, das es in neueren PHP-Versionen doch Unterschiede geben wird, wenn dort noch mehr optimiert wird.
Mit das größte Problem auf dass ich bei REST-Services in PHP gestoßen bin ist das Parsen der URLs. Hier besteht einfach das Problem, dass es immer viele Methoden pro Service gibt und das einlesen der Mapping-Patterns somit doch relativ aufwendig sein kann. Während man in einem Java-Servlet nur einmal am Anfang alles parsen muss, muss man in PHP bei jeden Request von vorne beginnen. Eine Lösung wäre das Speichern der Ergebnisse in der Session, wobei hier dann aber das Problem bleibt, dass man bei Änderungen diese erkennen und den Inhalt der Session erneuern muss. Man kann das XML als String lesen und einen MD5-Hash bilden. Damit könnte man verschiedene Versionen des Services in der Session identifizieren. Am schönsten wäre natürlich den Zugriff auf das Dateisystem komplett einsparen zu können, aber dass scheint erstmal so nicht machbar zu sein.
Das Gleiche gilt auch für das Objekt, dass die Methoden enthält auf die die URLs gemappt werden. Man muss sich auch deutlich machen, dass ein REST-Service im Grunde kein Konstrukt der objekt-orientierten Programmierung ist, sondern die Facade im Grund klassischen prozedualen Prinzipen folgt. Gerade wenn man Sicherheits-Token und so verwendet und nicht die Session für die Speicherung des eingelogten Benutzer verwendet, merkt man dass man auch ohne Klasse mit einfachen functions hier genau so gut arbeiten könnte. Aber wir verwenden eine Klasse, die den Service beschreibt, um auch keinen Stilbruch zu haben. Ein Objekt zu erzeugen ist teuer und theoretisch könnte man sich dieses hier ersparen.
Mein AFP2-Framework benutzt die selben Klassen wie mein älteres aoop-Framework. Es implementiert momentan noch kein wirkliches Routing sondern nutzt einfach Regex-Ausdrücke um die gesamte URL mit einem Match auf die richtige Methode zu mappen. Hier wird also einfach von oben nach unten die Liste durch laufen und immer ein preg_match durchgeführt. Routing mit beliebig tiefer Verschachtelung und Sub-Routen, würde hier viel Zeit ersparen, da damit die Anfangs-Liste relativ klein wäre und schnell abzuprüfen wäre und erst dann in der nächsten Liste weiter geprüft wird. Das kommt dann später nochmal um etwas schneller zu werden.
Wie man erkennt wird im service-Tag die Klasse angeben, auf die die URLs gemappt werden sollen. Das Mapping der einzelnen Methoden wird dann innerhalb genauer definiert. Jede Method einen grundlegenden Pattern, der für ein Match auf die URL verwendet wird. Wenn dieser passt wird versucht die Argument (die Reihenfolge in der XML muss der Reihenfolge in PHP entsprechen!) aus der URL oder dem Request zu rekonstruieren. Jedes Argument kann ein eigenes Pattern haben. Wenn es ein Request-Value ist, entspricht das Pattern dem Namen im Request. Sollte kein Pattern angeben sein, wird dass Pattern der Method verwendet. Das erspart viel Text, weil man so nur ein allgemein gültiges Pattern schreiben muss. Mit group wird die Gruppe beim preg_replace angeben. Also die die den benötigten Wert enthält, der als Argument übergeben werden soll. Im Pattern der Method können also schon alle Werte in Gruppen markiert werden und bei den Arguments muss immer nur noch angegeben werden, welche Gruppe verwendet werden soll.
URLs zu REST-Services folgen in aoop und APF2 folgender Regel:
http://..../rest/{modulename}/.....
Über den Modul-Namen wird gesteuert welche rest.xml geladen wird. /rest/ ist die Markierung, dass hier ein REST-Service angesprochen werden soll. Der Rest der URL kann nach Belieben definiert werden.
Für unser Beispiel wäre z.B. folgende URL lauffähig:
Das Ergebnis der Methode wird dann in JSON umgewandelt und auch der Header entsprechend auf "text/json" gesetzt.
Damit lässen sich nun pro Modul REST-Services definieren und deployen. Bei PHP hat man zum Glück nicht das Problem, dass sich ändernde Klasse von anderen REST-Services anderer Module zu Laufzeitfehlern führen können. Wenn man ein Modul ändert, wird die Klasse ja beim nächsten Request erneut geladen und nicht wie bei Java in der VM gehalten. Probleme kann es nur geben, wenn man die Session verwendet und versucht dort gespeicherte serialisierte Daten einer alten Version in ein Objekt der neuen Version der Klasse zu deserialisieren.
Das macht diese Umgebung in PHP für Microservices interessant. Da man hier wirklich einzelne Module zur Laufzeit austauschen kann, ohne dabei die anderen Module zu beeinflussen (wenn man natürlich vorher drauf geachtet hat, dass Klassen, die auch von anderen Modulen verwendet werden, nicht zu Fehlern bei diesen führen). Zu überlegen wäre auch diese Klassen zwischen den Services als JSON und nur über eine URL dem anderen Service verfügbar zu machen. Also die URL auch zu Intra-Service Kommunikation zu verwenden.
Und den JSON-String dann auf eine eigene Klasse zu mappen. So etwas werde ich für die nächste Version dann einbauen.
Das war jetzt ein grober Überblick wie meine Frameworks REST-Services implementieren und versuchen dabei möglichst flexibel zu sein, aber auch nicht dabei zu sehr auf Kosten der Performance zu arbeiten. Die Arbeiten an APF2 sind noch in Gange und deswegen kann sich da auch noch einiges Ändern und vielleicht lerne ich von anderer Seite noch einiges, wie sich auch die letzten Probleme lösen lassen, um so REST-Services noch besser implementieren zu können.
Das Geheimnis beim Class-Loading in PHP ist die Funktion __autoload, diese Funktion wird immer aufgerufen bevor eine Instanz einer Klasse erzeugt wird.
function __autoload($classname){
}
Hier kann man also anhand des Klassennamens den Code der Klasse nachladen. Man kann natürlich auch per Hand in jeder Datei über include() die Klassen laden, die man braucht. Meistens läuft es dann darauf hinaus, dass man zu viel lädt und Zugriffe auf das Dateisystem ist eben sehr teuer. Mit der autoload-Funktion ist sicher gestellt nur das zu laden, was auch wirklich benötigt wird und sort dafür, dass möglichst wenige Dateizugriffe durch geführt werden. Wenn also eine Klasse in einem Code-Block verwendet wird der nie ausgeführt wird, wird der Code der Klasse nicht aus dem Dateisystem nachgeladen.
Ein sehr simpler Class-Loader kann also so aussehen:
function __autoload($classname){
if(!class_exists($classname)){
include_once("classes/".$classname.".php");
}
}
Alle Klassen-Dateien müssen an einem bestimmten Ort legen, hier im Order "classes/". Wenn man nun mit Modulen arbeitet, wo ein Modul die Klassen eines übergeordneten Modules nutzen kann, hat man das Problem, dass man nicht immer genau weiß wo eine Klasse liegt und man muss diese Suchen. Bekannt ist das Problem beim Class-Loading in Java, wo ein Package über mehrere JAR-Files verteilt sein kann und man also in allen JAR-Files nach einer Klasse muss, weil man durch Package und Klassennamen nicht auf die JAR schliessen kann in welcher die Klassen-Datei liegt.
Suchen ist natürlich auch sehr teuer, gerade wenn man rekursiv durch Verzeichnisstrukturen laufen will. Wenn man nun bei jeder Klasse alle Verzeichnisse durchläuft bis man eine Klasse gefunden hat, würde alles sehr lange dauern.
Eine Lösung ist, bekannte Pfade sich zu merken, damit man nicht immer wieder das selbe Suchen muss. Wenn man in einem Modul unterwegs ist, hat man es mit maximal zwei Händen voll von Klassen zu tun, die immer und immer wieder verwendet werden. Wenn ich aber durch eine Liste von Dateien laufe und bei jeden Item in der Liste prüfe, ob es das passende ist (ok.. man könnte auch file_exists() innerhalb des Verzeichnisses verwenden...) kann man sich die gefunden Klassen und deren Pfade bis zum Pfund der gesuchten Klasse merken.
function __autoload($classname){
if(!class_exists($classname)){
if(!isset($_SESSION["XWCLASSCACHE"])){
$_SESSION["XWCLASSCACHE"]=array();
}
Hier wird alles in einen Cache geladen. XWRecursiveClassSeeker durchläuft alle Verzeichnisse rekursiv und vermerkt jeden Pfad zu jeder Klasse auf die er trifft. Wenn die gesuchte Klasse gefunden wurde bricht er ab. Dann wird der Code der Klasse nachgeladen. Alles wird auch in de Session gespeichert so dass man pro Request kaum noch Dateisystemzugriffe zum Suchen hat und nur noch für die includes der Klassen-Datein.
Das Problem ist, wenn man Klassen-Dateien umkopiert, weil dann die Pfade im Cache nicht mehr stimmen. Hier werden diese in dem Fall aus dem Cache entfernt, so dass beim nächsten Versuch die Klasse zuladen wieder neu gesucht wird und es dann auch klappen sollte.
Über dieses Vorgehen, kann man auch in PHP einen relativ peformanten und flexiblen Class-Loader schreiben und muss sich nie wieder selbst um includes von Klassen kümmern!
Den Großteil meiner Zeit habe und verbringe ich momentan noch mit Java. Tomcat, JavaFX, REST-Services und Clients. Neben JavaFX sehr verstärkt auch AngularJS. Nun wird es gegen Sommer dahin gehen, dass ich Java soweit hinter mir lassen werde (als Option halte ich mir Daten-Importer mit Multithreading frei.. weil da Java gegenüber einem PHP-Script doch weit vorne liegt).
Jetzt stellt sich mir die Frage wie man sich am besten in PHP einarbeitet.. wobei es eher weniger um PHP geht als um das Zend Framework 2. PHP kann ich... und ich bin der Meinung, dass wenn ich mir mein eigenes PHP Framework schreiben kann (das schon relativ viel kann und seit der Erweiterung um eine native REST-Unterstützung und das bald neue foglende Page-Format wirklich gut super für meine eigenen Apps auf Angular-Basis funktioniert), ich mich wohl auch ohne größere Probleme darin einarbeiten können sollte.
Viele Konzepte sind mir auch nicht neu und vieles er kennt man auch wieder, wenn man mal ein eigenes Framework geschrieben hat (ich bei JavaScript-Frameworks das selbe, wobei ich da beschlossen habe cJS zu Gunsten von AngularJS nicht mehr weiter zu entwickeln und cJS nur noch
für die kleinen gepackten Firefox OS Apps zu verwenden).
Erstmal muss ich heraus finden welche Umgebung zum Entwickeln unter Windows ideal wäre und man wenig per Hand nach installieren müßte. PHPStorm habe ich schon gestestet und das Generieren von Gettern und Settern ist schon mal super. Aber Eclispe ist schon mehr fertig eingerichtet.
XAMPP oder WAMP? WAMP scheint eine Zend Framework Installation mit Beispiel Modul mitzubringen.
Aber dann mal gucken ob als VM oder Installation. Eine VM mit Linux und Spiegeln des Verzeichnisses über WinSCP hätte natürlich schon seine Vorteile.
Aber meien Feststellungen bis jetzt ist, dass das Zend Framework 2 mit seinen Namespaces sehr viel dichter an Java dran ist, als die 1.x Version oder auch mein eigenes aoop-Framework.. das bald mal umbenannt wird.
Aslo werde ich erstmal in den nächsten Tagen, analysieren welche Umgebung für mich die beste ist und sich am einfachsten Installieren läßt.
zum Jahres Ende kommt mal ein Update von aoop auf 0.6, was sich jetzt immer mehr zur Middleware für JS-Webapps entwickelt. Die Neuerungen sind:
* mehr Singletons für bessere Performance
* seperates Theme für das Admin-Panel einstellbar
* REST-Services Unterstützung im Kernsystem (definierbar über module/desploy/rest.xml)
* Login Sicherheit (Sperrung für 5min nach 3 gescheiterten Loginversuchen)
* Begonnen requireJS für JS-Module zu integrieren
* schon mal der Begin einer Entwickler-Dokumentation um selbst aoop als Middleware zu verwenden.
Neben bei entsteht ein eigenes kleines JS-Framework, das Controller-Objekte für Views und passendes Databindung ermöglicht. Kein Templating.. dafür aber sehr klein und Übersichtlich. Erste Test-App gibt es schon damit: