anpera.net

anpera.net

experimental server @home
Aktuelle Zeit: Mo 20 Nov, 2017 01:22

Alle Zeiten sind UTC + 1 Stunde




Ein neues Thema erstellen Auf das Thema antworten  [ 33 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: LotGD Revival: Daenerys
BeitragVerfasst: Fr 13 Mär, 2015 13:33 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Out of date. Das Projekt wurde mit Daenerys ersetzt, eine Kollaboration mit dragonprime.

Mehr Informationen: https://github.com/lotgd/core

NewLoGD
Lizenz: AGPL 3.0

Download des master-branches via github:
https://github.com/Vassyli/NewLoGD
oder direkt: https://github.com/Vassyli/NewLoGD/archive/master.zip

Mindest-Anforderungen:
  • PHP 5.5.0 oder höher (mit der PDO-Erweiterung und dem entsprechenden Treiber)
  • MySQL 5.0 oder höher, benötigt unbedingt die InnoDB-Engine

Installation:
  1. Create a new table
  2. Import the .sql file including the values
  3. Edit the file dbconfig.php with the connection informations
  4. Enjoy. Default login is Admin/CHANGEME (if it would work)

Features implementiert
  • MVC-Pattern
  • Seiten werden aus der Datenbank erzeugt
  • Seiten können Module zugewiesen werden zur Ergänzung der Ausgabe
  • Navigation entstehen ebenfalls aus der Datenbank
  • FormGenerator-Klasse mit integrierter Validation
  • Tabellenprefixe können gesetzt werden
  • QueryBuilder-Klassen - händisches Schreiben von Queries fällt weg
  • UTF-8 Unterstützung
  • Sichere Passwort-Verwaltung mit password_hash()
  • Simple Template-Klasse (Quick'n'Dirty - wird ev später aufpoliert)
  • Einfaches Parsen der Page-Ausgabe (Verwandelt Doppelabsätze in tatsächliche Absätze)
  • Lazy-Loading der Submodels (und der Daten innerhalb von Submodel)

Features to-do
  • Session-Verwaltung
  • Login/Logout-Routinen
  • Cheatschutz
  • Admin-Editoren
  • So ziemlich alles aus 0.9.7+jt

Originalbeitrag hat geschrieben:
Lang ist's her...

LoGD 0.9.7+jt ist schon etwas älter. Gemacht damals für PHP4, kann man sie kaum noch unter aktuellen PHP-Versionen zum laufen zu bringen - ausser, man investiert viel Zeit (oder hat Glück eine Version zu bekommen, in der das schon erledigt ist). Dabei bemerkt man vielleicht, dass die Code-Basis sehr unschön ist.

Die aktuelle Dragonprime-Version würde mit all den Problemen aufräumen und bietet ein flexibles Modulsystem - die Version hat sich allerdings nie wirklich durchgesetzt im deutschsprachigen Raum, vor allem weil kaum vollständige Übersetzungen zu finden sind. Aber auch die Dragonprime-Version ist älter und es gibt Diskussionen über einen Rewrite.

Seit ein paar Wochen spiele ich wieder mit PHP rum und habe LoGD "wiederentdeckt". Ich hab schon mehrere Versuche gestartet, die Code-Basis zu ändern, zu erneuern, was weiss ich - allerdings nie öffentlich. Deshalb möchte ich das mal so rum probieren, bei Interesse könnte ich ein Repository einrichten.

Das Ziel ist es, einen modernen LoGD-Rewrite zu schreiben, der mit 0.9.7+jt (nahezu) Feature-Parität hat.

Im Anhang befinden sich die Daten inklusive SQL-Export einer ersten, lauffähigen Version. Allerdings ist Zahl der Funktionen relativ klein - mehr als einen Account erstellen kann es nicht (also nichtmal einloggen). Dafür hat es ein lauffähiges Template-System (das nicht kompatibel ist mit 0.9.7 oder mit 1.1.0).

Die Datenbankverbindung kann in der common.php spezifiziert werden (nur MySQLi wird unterstützt).

[Download entfernt]


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Fr 13 Mär, 2015 20:30 
Offline
Meister
Meister
Benutzeravatar

Registriert: Mo 05 Feb, 2007 12:33
Beiträge: 375
Wohnort: Hattingen
Geschlecht: Männlich
LoGD: http://www.alvion-logd.de/logd/
Alvion läuft seit eh und je mit der 0.9.7+jt, angepasst an PHP 5.xx und mit diversen Verbesserungen von mir selbst und anderen aufgemöbelt. Da steckt so viel Liebe und jahrelange Arbeit drin, dass ich heute nicht weiß, ob ich mir das antun würde auf ein Rewrite umzurüsten. Ich sage aber niemals nie! Bild

Ich schau mir dein newlogd an, und werde eine eventuelle Weiterentwicklung verfolgen, wenn möglich unterstützen ... und sag schon mal Danke Eli! Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Sa 14 Mär, 2015 14:03 
Offline
Profi
Profi

Registriert: Mo 20 Apr, 2009 00:30
Beiträge: 123
Auch hier mal die Kritik-Keule :D

Deine prepare_query ist ein Alptraum, bitte benutz PDO!

E-Mail Validation über RegEx geht irgendwann immer schief, vorallem wenn PHP es von Haus aus kann:
Code:
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
    echo "This email address is considered valid.";
}


Namespaces ohne use Statements.
Die Template-Engine ist ein Performance-Bottleneck.

Includes von Klassen ein no-go wenn man Namespaces verwendet.
So macht man das: (Natürlich muss man die Anforderungen erfüllen full path, no uppercase in file name usw.)
Code:
spl_autoload_extensions(".php");
spl_autoload_register();//Ja ohne Argumente Aufrufen das ist PHP-Performance-Magie :D


Database Connection in der Common.php, das sollte in die DB-Klasse, Lazy-Loading ist ein muss.

Alles ist fest codiert.
Pages sollten keine eigene Datei sein, sondern aus der DB geladen werden und dynamisch generiert werden.
Das gleiche gilt für Texte usw.

Noch viel Erfolg :)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Sa 14 Mär, 2015 16:36 
Offline
Freak
Freak

Registriert: So 29 Jan, 2006 09:41
Beiträge: 1927
Wohnort: Schweiz
Geschlecht: Männlich
Skype: louis.huppenbauer
Ich finds schön, will hier wieder mal jemand neuen Wind aufkommen lassen. :)

Was mir dabei aufgefallen ist, beziehungsweise meine Gedanken dazu:
  • Formulargenerierung / Formularvalidierung: Hier würde ich auf bereits existierende Libraries zugreifen. Ich finde, dass es generell nicht nötig ist, das Rad neu zu erfinden. Dabei spart man Zeit und kann von der Arbeit Anderer profitieren.
  • Magische Getter / Setter würden sich unter Umständen auch anbieten. Beispiel: get_loginform_data / set_loginform_data in Page\Page.
  • Template-Engine: Auch hier würde ich auf eine bestehende Library zugreifen. Ich persönlich habe immer sehr gute Erfahrungen mit Twig gemacht - Ist allerdings auch schon 'ne Weile her, und ich kann inzwischen keine qualifizierte Aussage zur Performance mehr sagen. Sie bitten i.d.R. aber sehr gute Caching-Möglichkeiten.
  • Mir persönlich gefällt der Ansatz, für einzelne Seiten auch einzelne Template-Dateien zu haben (Beispiel: password.form.text.template finde ich aber persönlich zu klein für eine eigene Datei). Ich bin da nicht vollkommen bathory's Meinung, dass alles dynamisch aus der Datenbank generiert werden soll. Aber gerade für Texte würde sich eine Datenbank natürlich anbieten - Internationalisierung lässt grüssen.
  • Sehr spannend wäre natürlich ein sauberer MVC-Ansatz. Oder in Richtung REST-API mit einem AJAX-HTML Frontend (Sicherheitstechnisch vermutlich ein Alptraum, spannend wärs aber trotzdem).
  • Autoloading über spl_autoload_extensions ist heutzutage tatsächlich schon fast ein Muss. Führt auch automatisch dazu, dass man Klassen systematischer einordnet und sich mehr Gedanken zu den jeweiligen Aufgabengebieten einer Klasse macht.
  • Schau dir am Besten vorher noch SOLID an. Besonders wichtig finde ich hier (auch für das Code-Verständnis das "Single responsability principle". Beispiel: Die Klasse [accounts] ist dafür verantwortlich, Accounts zu verwalten. Daten zu Entschlüsseln oder Verschlüsseln gehört allerdings nicht dazu. hash_password müsste also in eine andere / neue Klasse implementiert werden und an accounts übergeben werden. Ein Dependency-Injection Container dazu wäre spannend.

's soll übrigens nicht abschreckend sein. Ich finds toll.
Falls du an Hilfe interessiert bist, kannst du dich gerne mal kurzschliessen - Für die eine oder andere Komponente sollte ich durchaus Zeit finden.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Sa 14 Mär, 2015 18:19 
Offline
Profi
Profi

Registriert: Mo 20 Apr, 2009 00:30
Beiträge: 123
Harthas hat geschrieben:
Ich bin da nicht vollkommen bathory's Meinung, dass alles dynamisch aus der Datenbank generiert werden soll.


Was für ein Nachteil sollte das haben? (Weil die Vorteile sind ja offensichtlich und enorm.)

Ich habe bereits eine Lotgd-Version geschrieben, die komplett aus der DB generiert wird und durch Editoren nach Gusto eingestellt und erweitert werden kann.
Dank gutem caching (APCu), ist es auch sehr performant. :D (und auch wenn man auf File-Caching setzt ist die Performance ab PHP 5.5 (wegen dem OpcodeCache) fabelhaft :))


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: So 15 Mär, 2015 07:14 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Jetzt kommen se alle aus den Löchern gekrochen :D

Bin unterwegs, Kritik angekommen und verstanden. Grösstenteils.

@Email: Die PHP-Funktion filter_var validiert nicht nach RFC5321. Das wollte ich unbedingt vermeiden.

@Hash: Ich finde schon, dass das hashen des Accountpassworts zu den Aufgaben der Accountverwaltung gehört. Sie implementiert ja keine Kryptofunktionen, sie ruft sie nur auf.

@Dynamisch aus Datenbank generieren: Wie hast du die Logik in der Datenbank untergebracht? Metasprache, die Daten verändern/prüfen darf, direktes PHP und dann eval?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: So 15 Mär, 2015 15:25 
Offline
Profi
Profi

Registriert: Mo 20 Apr, 2009 00:30
Beiträge: 123
Eliwood hat geschrieben:
Jetzt kommen se alle aus den Löchern gekrochen :D


Ich bin einer der wenigen die hier tatsächlich täglich reinschauen :) und in meiner Facebook Gruppe habe ich sogar seit paar Wochen ein Beta-Test für 0.97er Module am laufen :D

Eliwood hat geschrieben:
@Email: Die PHP-Funktion filter_var validiert nicht nach RFC5321. Das wollte ich unbedingt vermeiden.


Du benutzt den Regex von Michael Rushton, der auch E-Mail wie z.B. "name@local" akzeptiert. Und das ist gegen RFC5321.

Die PHP Version (ab PHP 5.3.?) ist besser:

https://github.com/php/php-src/blob/mas ... _filters.c

Code:
void php_filter_validate_email(PHP_INPUT_FILTER_PARAM_DECL) /* {{{ */
{
/*
* The regex below is based on a regex by Michael Rushton.
* However, it is not identical. I changed it to only consider routeable
* addresses as valid. Michael's regex considers a@b a valid address
* which conflicts with section 2.3.5 of RFC 5321 which states that:
*
* Only resolvable, fully-qualified domain names (FQDNs) are permitted
* when domain names are used in SMTP. In other words, names that can
* be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
* in Section 5) are permitted, as are CNAME RRs whose targets can be
* resolved, in turn, to MX or address RRs. Local nicknames or
* unqualified names MUST NOT be used.
*/


Wie du siehst ist die PHP Version nicht nur besser, sondern auch schneller.
Und sie wird mit Updates angepasst, so dass man auch in Zukunft dabei ist und nicht dauernd den RegEx anpassen muss :)

Eliwood hat geschrieben:
@Dynamisch aus Datenbank generieren: Wie hast du die Logik in der Datenbank untergebracht? Metasprache, die Daten verändern/prüfen darf, direktes PHP und dann eval?


Eval würde ich nie im Leben verwenden, auch kein Code in der DB oder Metasprache.
Man hat einfach Tabellen, Pages, Navs, Modules, Modules_Pages usw.

Ablauf:

1) Page mit ID aus Pages laden, und daraus ein Objekt generieren, der Klasse Pages
2) Funktion des Objekts aufrufen, ob der User Zugriff auf diese Seite hat.
3) Nein: Badnav Ja: gehe zu Navs generieren.

Navs generieren:
1) Lade Navs aus Pages_Navs where from = ID, and Module = active aus der Modules Table
2) Check die Rechte und Anforderungen, erfüllt => dann addnav
3) gehe zu generiere die Seite

Seite generieren:

1) Lade alle Module aus Module_Pages mit der PageID = ID, dessen ModulID in der Tabelle Moduls active = 1 hat, ORDERED BY sort ASC.
2) Lade für jedes Modul die angegeben Modul-Klasse und initialisere ein Object mit Config eine json encoded array in der Tabelle Module_Pages. Diese Config ist für jede Page einzelnd configurierbar in der Grotte.
3) Frage dem Objekt ob die Anforderungen des Moduls erfüllt sind (User Rechte, gewisse Bedingungen wie Zeit, Wetter, Dragonkills usw)
4) Jedes Modul bietet über hooks die Möglichkeit weitere Module über Module_Hooks zu laden
5) Anforderungen erfüllt generiere output und packe es ins content

-> Gebe Seite aus

Neben den Page_Modules gibt es natürlich auch globale Module und Plugins, welche bei jedem Aufruf geladen werden.
Das ist wichtig um die Configuration so schlank wie möglich zu halten.

Und schwupps, hats du ein Dynamische Lotgd, welches nur aus einer PageFactory und lauter einzel Module und Plugins (welche in Module hooken) besteht.
Der Rest läuft über Editoren in der Grotte.

Noch schöner und wahre PHP Magie ist mein Form Generator, Validator und insert/update automatismus direkt aus der Datenbank raus.

Einfach new DBRow('accounts',ID)->show_editor() oder DBRows('accounts')->show_table(edit=true) und andere schöne Sachen :)
(Auch wenn ich das in Code geschrieben habe ist es ebenfalls dynamisch, einfach als Modul zu laden. Nichts ist im Code fest codiert.)
Aber dafür braucht man zwei weitere Tabellen (tables, tables_fields) und die sind etwas komplexer, enthalten aber zu jeder tabelle und zu jeder Spalte wichtige Informationen (zB welches Modul sie angehören, welchen Typ sie haben usw) die verwendet werden um die Editoren zu generieren, aber auch um Tabellen und Output zu generieren, und diese können per Editor erweiterte werden.

Sprich wenn man über den Editor ein neus Feld in der Tabelle account einfügt und zB sagt, dass nur admin dieses Feld editieren können.
Ruft ein User den Editor auf sieht er kein Formular-Feld um das Feld zu editieren.
Ein Mod auch nicht.
Ein Admin schon.

Erstellt man ein Feld das Min. Mod braucht sehen Mod und Admin das Feld sobad sie den Editor sehen der User nicht.
Natürlich kann man das noch viel viel Feiner über ein Rechtesystem einstellen, oder eben grob wie es einem gefällt.
Man kann sogar die Sichtbarkeit von machen Felder von dem Inhalt anderer Felder abhängig machen ohne eine Zeile JS zu schreiben, wird alles dynamisch generiert.

Das ganze System ist darauf hinaus, dass man so viel wie Möglich ohne Progger machen kann und das jederzeit Module und Plugins installiert werden können ohne was am Code zu ändern.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Di 17 Mär, 2015 13:07 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Bathory hat geschrieben:
Eliwood hat geschrieben:
@Email: Die PHP-Funktion filter_var validiert nicht nach RFC5321. Das wollte ich unbedingt vermeiden.

Du benutzt den Regex von Michael Rushton, der auch E-Mail wie z.B. "name@local" akzeptiert. Und das ist gegen RFC5321.
[...]
Wie du siehst ist die PHP Version nicht nur besser, sondern auch schneller.
Und sie wird mit Updates angepasst, so dass man auch in Zukunft dabei ist und nicht dauernd den RegEx anpassen muss :)


Okay, okay, ich geb auf. Ich sollte nicht allen Kommentaren auf der phpdoc-Seite glauben schenken, sondern eigene Tests laufen lassen :)

Bathory hat geschrieben:
Eliwood hat geschrieben:
@Dynamisch aus Datenbank generieren: Wie hast du die Logik in der Datenbank untergebracht? Metasprache, die Daten verändern/prüfen darf, direktes PHP und dann eval?


Eval würde ich nie im Leben verwenden, auch kein Code in der DB oder Metasprache.
Man hat einfach Tabellen, Pages, Navs, Modules, Modules_Pages usw.

Ablauf:

1) Page mit ID aus Pages laden, und daraus ein Objekt generieren, der Klasse Pages
2) Funktion des Objekts aufrufen, ob der User Zugriff auf diese Seite hat.
3) Nein: Badnav Ja: gehe zu Navs generieren.

Navs generieren:
1) Lade Navs aus Pages_Navs where from = ID, and Module = active aus der Modules Table
2) Check die Rechte und Anforderungen, erfüllt => dann addnav
3) gehe zu generiere die Seite

Seite generieren:

1) Lade alle Module aus Module_Pages mit der PageID = ID, dessen ModulID in der Tabelle Moduls active = 1 hat, ORDERED BY sort ASC.
2) Lade für jedes Modul die angegeben Modul-Klasse und initialisere ein Object mit Config eine json encoded array in der Tabelle Module_Pages. Diese Config ist für jede Page einzelnd configurierbar in der Grotte.
3) Frage dem Objekt ob die Anforderungen des Moduls erfüllt sind (User Rechte, gewisse Bedingungen wie Zeit, Wetter, Dragonkills usw)
4) Jedes Modul bietet über hooks die Möglichkeit weitere Module über Module_Hooks zu laden
5) Anforderungen erfüllt generiere output und packe es ins content

-> Gebe Seite aus

Neben den Page_Modules gibt es natürlich auch globale Module und Plugins, welche bei jedem Aufruf geladen werden.
Das ist wichtig um die Configuration so schlank wie möglich zu halten.

Und schwupps, hats du ein Dynamische Lotgd, welches nur aus einer PageFactory und lauter einzel Module und Plugins (welche in Module hooken) besteht.
Der Rest läuft über Editoren in der Grotte.


Wenn ich das also richtig verstehe, sind zwar die Pages dann frei erstell- und konfigurierbar, die Module, die in PHP als Datei geschrieben sind, sind dann aber abhängig von der PagesID. Das heisst, ich könnte zwar beliebige Pages erstellen, müsste dann aber immer n'passendes Modul schreiben für die Page. Oder missverstehe ich hier etwas?

Bathory hat geschrieben:
Noch schöner und wahre PHP Magie ist mein Form Generator, Validator und insert/update automatismus direkt aus der Datenbank raus.

Einfach new DBRow('accounts',ID)->show_editor() oder DBRows('accounts')->show_table(edit=true) und andere schöne Sachen :)
(Auch wenn ich das in Code geschrieben habe ist es ebenfalls dynamisch, einfach als Modul zu laden. Nichts ist im Code fest codiert.)
Aber dafür braucht man zwei weitere Tabellen (tables, tables_fields) und die sind etwas komplexer, enthalten aber zu jeder tabelle und zu jeder Spalte wichtige Informationen (zB welches Modul sie angehören, welchen Typ sie haben usw) die verwendet werden um die Editoren zu generieren, aber auch um Tabellen und Output zu generieren, und diese können per Editor erweiterte werden.

Sprich wenn man über den Editor ein neus Feld in der Tabelle account einfügt und zB sagt, dass nur admin dieses Feld editieren können.
Ruft ein User den Editor auf sieht er kein Formular-Feld um das Feld zu editieren.
Ein Mod auch nicht.
Ein Admin schon.

Erstellt man ein Feld das Min. Mod braucht sehen Mod und Admin das Feld sobad sie den Editor sehen der User nicht.
Natürlich kann man das noch viel viel Feiner über ein Rechtesystem einstellen, oder eben grob wie es einem gefällt.
Man kann sogar die Sichtbarkeit von machen Felder von dem Inhalt anderer Felder abhängig machen ohne eine Zeile JS zu schreiben, wird alles dynamisch generiert.

Das ganze System ist darauf hinaus, dass man so viel wie Möglich ohne Progger machen kann und das jederzeit Module und Plugins installiert werden können ohne was am Code zu ändern.
[/quote]

Eins nach dem anderen... :D


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Mi 18 Mär, 2015 01:36 
Offline
Profi
Profi

Registriert: Mo 20 Apr, 2009 00:30
Beiträge: 123
Das hast du missverstanden :)

Es gibt Moduls diese sind entweder global oder local und haben keine Abhängigkeit zu einer bestimmten PageID.

Wenn man eine Page erstellt und kein local Modul auf der Page konfiguriert, gibt diese halt nur Text und Navs aus, will man auch noch ein RP-Chat, dann fügt man das Modul Chat hinzu und konfiguriert dieses gemäß die Vorgaben im Modul -> daraus wird ein Form generiert.

Das Ganze wird dann in der DB gespeichert.

Aber vllt wäre es einfacher wenn ich mal ein kleines demo Framework zur Verfügung stelle. :)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Mi 18 Mär, 2015 09:13 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Nicht nötig, ich glaub ich hab inzwischen genug Informationen. Mal sehen, was ich daraus machen kann :)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Mi 25 Mär, 2015 11:52 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Okay, mal sehen. Der neue Beispiel-Code ist definitiv weniger weit, was Inhalte angeht, dafür implementiert er andere Kritikpunkte.

  • MVC-Pattern, zumindest soweit ich das verstanden habe. Ich verwende die strikte Variante, also der Controller darf View nicht anfassen (http://www.sitepoint.com/the-mvc-pattern-and-php-1/).
  • Automatisches Laden der Klassen wie spl
  • Verwendet nun PDO + ein rudimentärer Query-Builder
  • Lazy-Loading für die beiden Tabellen implementiert (via einem trait)
  • Generiert die pages aus einer Datenbank

Ich möchte nicht auf externe Libraries zurückgreifen, zumindest nicht, was den serverseitigen Teil angeht.

[Download entfernt]


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival?
BeitragVerfasst: Mi 01 Apr, 2015 08:55 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Zumindest was das Anzeigen von Seiten angeht, ist das Framework nun inklusive lokalen Modulen beinahe fertig. Die Entwicklung kann auf Github verfolgt werden.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival - NewLoGD
BeitragVerfasst: Mo 29 Feb, 2016 14:41 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Sorry, ich war ziemlich beschäftigt in letzter Zeit mit meiner Master-Thesis, deshalb hier nun n'kleines Status-Update:

Ich bin vom Plan, alles selbst zu machen, inzwischen abgekommen und verwende nun Doctrine als Datenbankmanager.

Zusätzlich probiere ich grad mit dem REST-Konzept rum und möchte nur noch, dass PHP eine API bereitstellt - die dann entweder mit JavaScript oder mit Smartphones verwendet werden kann, um das eigentliche Spiel dann anzuzeigen. Ich halt euch auf dem laufenden.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival - NewLoGD
BeitragVerfasst: Mo 29 Feb, 2016 18:44 
Offline
Profi
Profi

Registriert: Mo 20 Apr, 2009 00:30
Beiträge: 123
Eliwood hat geschrieben:
Ich bin vom Plan, alles selbst zu machen, inzwischen abgekommen und verwende nun Doctrine als Datenbankmanager.


So verlockend ein ORM auch auf den ersten Blick sein mag, ist es eine wahre Performance-Bremse, da das Object mapping auch keinen wirklichen Gewinn bringt.
Außerdem sollte man beachten, dass Lotgd-Server Update faul sind und eine Library wie Doctrine natürlich auch im Mittelpunkt der bösen Jungs steht und gerne mal gravierende Sicherheitslücken automatisiert durch Bots ausgenutzt werden.

Eliwood hat geschrieben:
Zusätzlich probiere ich grad mit dem REST-Konzept rum und möchte nur noch, dass PHP eine API bereitstellt - die dann entweder mit JavaScript oder mit Smartphones verwendet werden kann, um das eigentliche Spiel dann anzuzeigen. Ich halt euch auf dem laufenden.


Eine Headless Implementation, das macht schon einer bei Dragonprime und ich frage mich immer noch warum man das tun sollte im Falle eines Lotgds?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival - NewLoGD
BeitragVerfasst: Mo 29 Feb, 2016 20:30 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Bathory hat geschrieben:
Eliwood hat geschrieben:
Ich bin vom Plan, alles selbst zu machen, inzwischen abgekommen und verwende nun Doctrine als Datenbankmanager.


So verlockend ein ORM auch auf den ersten Blick sein mag, ist es eine wahre Performance-Bremse, da das Object mapping auch keinen wirklichen Gewinn bringt.
Außerdem sollte man beachten, dass Lotgd-Server Update faul sind und eine Library wie Doctrine natürlich auch im Mittelpunkt der bösen Jungs steht und gerne mal gravierende Sicherheitslücken automatisiert durch Bots ausgenutzt werden.


Der Gewinn liegt unter anderem in der Datenbankmigration - das spart für Update-Zyklen ein eigener Datenbank-Diff-Algorithmus. Falls später tatsächlich Optimierungen notwendig sind, kann mal immer noch den ORM einsparen und auf DBAL umsteigen in den Modellen, die das nötig haben.

Sicherheitslücken gibts natürlich überall - aber wer Doctrine und Konsorten nicht updated, der wird auch kaum auf eine aktuelle LoGD-Version umsteigen falls in einer gravierende Lücken vorhanden sind... ;)

Bathory hat geschrieben:
Eliwood hat geschrieben:
Zusätzlich probiere ich grad mit dem REST-Konzept rum und möchte nur noch, dass PHP eine API bereitstellt - die dann entweder mit JavaScript oder mit Smartphones verwendet werden kann, um das eigentliche Spiel dann anzuzeigen. Ich halt euch auf dem laufenden.


Eine Headless Implementation, das macht schon einer bei Dragonprime und ich frage mich immer noch warum man das tun sollte im Falle eines Lotgds?


Because of Reasons. Und weil es hip ist.

Ja, es macht nicht besonders viel Sinn, da man kaum Datenmengen verarbeitet, was der Vorteil solcher APIs ist. Den Vorteil sehe ich vor allem darin, dass man so ohne viel Krücken Echtzeit-Kommentare einbinden kann, ein Inventar managen kann, Items verwenden könnte. Ja, kann man auch ohne.

Edit: Hab mir Daenerys mal angesehen. Leider basiert es auf Hack und nicht auf PHP und geht mir in gewissen Punkten dann zu weit.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival - NewLoGD
BeitragVerfasst: Do 03 Mär, 2016 12:15 
Offline
Profi
Profi

Registriert: Mo 20 Apr, 2009 00:30
Beiträge: 123
Eliwood hat geschrieben:
Sicherheitslücken gibts natürlich überall - aber wer Doctrine und Konsorten nicht updated, der wird auch kaum auf eine aktuelle LoGD-Version umsteigen falls in einer gravierende Lücken vorhanden sind... ;)


Nur interessieren sich zur Zeit keine bösen Jungs für LotgD.
Fast alle Server sind voll mit Sicherheislücken und man hört nun nicht gerade oft, dass ein Server gehackt wurde oder? Doctrine wiederum ist eine beliebte Angriffsfläche. Und die Performance ist nicht gerade berauschend :). Aber wenn du es so machen willst ist es ja deine Entdcheidung :D.

Eliwood hat geschrieben:
Because of Reasons. Und weil es hip ist.

Ja, es macht nicht besonders viel Sinn, da man kaum Datenmengen verarbeitet, was der Vorteil solcher APIs ist. Den Vorteil sehe ich vor allem darin, dass man so ohne viel Krücken Echtzeit-Kommentare einbinden kann, ein Inventar managen kann, Items verwenden könnte.


Echtzeit gibt es bei REST nicht, dass ist eine uraltes Paradigma, mit haufenweise Overhead und die meisten Webhoster werden bei einer solchen Belastung den Server sperren.

Websockets bieten realtime ohne overhead.
Sind aber auf Webspaces regelmäßig nicht verfügbar. :)

Eigentlich sollte das Hauptaugemerk auf eine moderne und performante Version liegen, die auch auf Webspaces läuft, einfach zu erweitern ist.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival - NewLoGD
BeitragVerfasst: Mi 09 Mär, 2016 15:35 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Bathory hat geschrieben:
Echtzeit gibt es bei REST nicht, dass ist eine uraltes Paradigma, mit haufenweise Overhead und die meisten Webhoster werden bei einer solchen Belastung den Server sperren.

Websockets bieten realtime ohne overhead.
Sind aber auf Webspaces regelmäßig nicht verfügbar. :)

Eigentlich sollte das Hauptaugemerk auf eine moderne und performante Version liegen, die auch auf Webspaces läuft, einfach zu erweitern ist.


Ja, ich habe mich falsch ausgedrückt. :)

Der Overhead ist nur grösser wenn der Client falsch mit den Daten umgeht - und ist auch nicht viel grösser als wenn einer ständig F5 drückt. Für den normalen Spielgebrauch reicht es, wenn die "Szene" vom Client regelmässig aufgefrischt wird (also: bei jeder ausgeführten Aktion). Die restlichen Informationen werden nur unregelmässig gebraucht.

Um mich selbst ein wenig zu motivieren möchte ich hier wöchentliche Statusupdates geben wie weit die Entwicklung fortgeschritten ist.

Wöchentliches Update - KW10
Die ersten Commits sind auf GitHub. Aktueller Commit: #51

NewLoGD unterstützt die Authentifizierung via Google- oder Facebook-Account. Beim ersten Einloggen wird automatisch ein Benutzerkonto angelegt, das den OAuth-Account symbolisiert. Dabei wird die E-Mailadresse, der Name und die Benutzer-ID in der Datenbank hinterlegt. Ein simples System verhindert dass Controller für nicht-authentifizierte Benutzer mit einem Error 403 quittieren.

Zudem können Benutzer nun Charaktere erstellen - zur Zeit ohne Limit. Ein Formular-Klasse erzeugt eine JSON-Beschreibung des Formulars, das dann vom Clienten dargestellt wird und kontrolliert die Eingaben auf ihre Gültigkeit - Charaktere werden erstellt wenn der Name zwischen 2 und 50 Zeichen lang ist.

Der HTML5/JavaScript-Client unterstützt bis jetzt alle Funktionen ausser der Vorvalidierung des Formulars und der Fehlerantwort des Servers, wenn Fehler bei der Datenvalidierung gefunden wurden.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Wöchentliches Update - KW11
BeitragVerfasst: Mi 16 Mär, 2016 10:31 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Wöchentliches Update - KW11
Die ersten Commits sind auf GitHub. Aktueller Commit: #58. Changes.

Die Woche war ein wenig langsam - meine Master-Prüfung hat die meiste Zeit in Anspruch genommen. Nichts desto trotz - ein Update.

Server

Die Dokumentation-Tags wurden ergänzt wo sie bisher gefehlt haben.

Die serverseitige Unterstützung von "Szenen" wurde ergänzt. Szenen sind einfache Seiten mit Titel und Beschreibung die mit Aktionen verknüpft werden. Im Prinzip ist der Titel der ersetzt für page_header($titel), die Beschreibung Ersatz für output($text) und die Aktionen werden dann der Ersatz für die Navigation. Neue Charaktere werden mit einer Standard-Szene konfrontiert (die zur Zeit die Primär-ID 1 haben muss - später wird das konfigurierbar sein). Wird eine Szene von einem Charakter aufgerufen, wird diese in eine andere Tabelle kopiert, wo sie nur geändert werden, wenn der User eine valide Aktion auslöst. So wird verhindert, dass die selbe Szene mehrmals aufgerufen wird.

ToDo: Implementation der Aktionen und der entsprechenden Ausgabe an der API.

Client

Der Client unterstützt nun Form-Validierung sowohl Client-Seitig als auch Server-Seitig und verwendet dafür zwei verschiedene CSS-Klassen - die Clientseitige validierung deaktiviert das Absenden des Formulars, die Server-Seitige Korrektur nicht.

Der HTML-Client verwendet nun w3css für die flexiblere Darstellung der einzelnen Elemente, was vor allem die Darstellung auf Smartphones verbessert.

ToDo: Implementation der Szenen-Anzeige.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival - NewLoGD
BeitragVerfasst: Mi 16 Mär, 2016 19:24 
Offline
Lehrling
Lehrling
Benutzeravatar

Registriert: Fr 17 Nov, 2006 20:20
Beiträge: 44
Wohnort: Gera
Geschlecht: Männlich
LoGD: --in-arbeit--
Wenigstens einer von uns macht weiter :D
Mich trifft gerade einen ähnliches Problem wie dich Eli - Zu viel Stress im Studium und zu viele Klausuren/Vorträge. Das 6.Semester kann echt antregend sein ^^

Wenn du willst, helf ich auch gerne aus, da meine Version eh durch den Stress zurzeit auf Eis liegt xD


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: LoGD-0.9.7+jt-Revival - NewLoGD
BeitragVerfasst: Mi 23 Mär, 2016 18:44 
Offline
Marquis Pherae
Marquis Pherae

Registriert: Mi 09 Feb, 2005 16:01
Beiträge: 3890
Wohnort: Basel
Geschlecht: Männlich
Wöchentliches Update - KW12
Master-Branch ist auf GitHub verfügbar. Aktueller Commit: #82. Changes.

Server

Szenenwechsel ist nun mittels sogenannter "Szenen-Aktionen" möglich. Solche Aktionen sind zur Zeit ausschliesslich über die Datenbank definierbar und haben entweder eine zugehörige Szene als Elternteil oder eine andere Aktion (Nur einfache Verschachtelung möglich). Das target (ebenfalls eine Szene) ist entweder NULL (Zum Beispiel für Titel) oder die gewünschte Zielszene. Die möglichen Aktionen werden für eine aufgerufene Szene werden als JSON string in CharacterScene gespeichert (und ermöglichen so theoretisch auch Aktionen die nicht in der Datenbank stehen).
ToDo: Beispieldatensatz via Kommandozeile; Mitgabe von zusätzlichen Daten; Aktionen ohne Tabellen.

Vorbereitungen für die Unterstützung von Extensions wurden getroffen. Extensions erweitern den Funktionsumfang von Szenen, zum Beispiel um eine Kommentar-Funktion (Chat fürs Rollenspiel o.ä.), um einen Laden, um Kämpfe, etc. Die grundlegende Struktur ist in der (funktionslosen) Beispiel-Extension ersichtlich.
ToDo: Implementierung solcher Extensions.

Passend dazu wurde eine Tabelle für Character-Eigenschaften (also beliebige, zusätzliche Attribute) erstellt. Die API ist sehr einfach ($character->get($fieldname), $character->set($fieldname, $value) und unterstützt 3 Datentypen (string, integer, decimal).

Client

Der Client unterstützt den Szenenwechsel und die Anzeige der Szenen.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 33 Beiträge ]  Gehe zu Seite 1, 2  Nächste

Alle Zeiten sind UTC + 1 Stunde


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast


Du darfst keine neuen Themen in diesem Forum erstellen
Du darfst keine Antworten zu Themen in diesem Forum erstellen
Du darfst deine Beiträge in diesem Forum nicht ändern
Du darfst deine Beiträge in diesem Forum nicht löschen
Du darfst keine Dateianhänge in diesem Forum erstellen

Suche nach:
Gehe zu:  
cron
POWERED_BY
Deutsche Übersetzung durch phpBB.de
anpera.net - Impressum