CGI-Baukasten (gelöst) (Projekte)

[thread]16967[/thread]

CGI-Baukasten [gelöst]

Leser: 82

Articles: hide open all | hide show old branches

+24 replies
rosti

2011-12-04 11:29

User since
2011-03-19
3194 Artikel
BenutzerIn

Schlechtes Wetter? Zeit zum Tüfteln!!!

Also: Mein neuer CGI-Baukasten ist fertig ;)

Basis ist mode_rewrite, das schießt alle Requests auf ein Perl/CGI-Script um, hier liegt die main() und da wird nur noch festgestellt, ob es Parameter gibt oder keine. Es gibt eine Konfiguration, die als ini-Datei editierbar ist, hierin stehen alle [/URLs], die requestet werden dürfen. Diese URLs haben ini-Parameter wie title und descr und den Namen der Methode, die im Fall von POST/GET-Parametern aufgerufen werden. Außerdem kann es zum [/URL] eine Methode geben, die ohne POST/GET-Parameter greift, beispielsweise um das aktuelle Datum ins Template zu setzen.

Zu jedem URL gibt es ein Template, z.B. ein Formular. In der main() wird über meine Reponse-Klasse das Response-Objekt erstellt, was im Attribut auch den HTTP_STATUS 200 oder 404 hat.

Am Schluss wird mit einer einzigen Print-Anweisung alles zusammen ausgegeben: header, start_html, menu, body, end_html;

Vorteil:
Neue Anwendungen sind im Handumdrehen integriert, es ist die ini-Konfiguration zu editieren und ein Template zu erstellen, fertig. Sollen POST/GET-Parameter verarbeitet werden, ist nur noch eine Methode zu schreiben, welche den {STASH} mit Daten bestückt oder bei fatalen Fehlern ein [ERR]-Array schreibt (die Err-Seite wird dann automatisch ausgegeben).

Optional kann es auch eine Methode geben, welche den {STASH} beim Aufruf der Seite ohne POST/GET-Parameter bestückt.

Das Ganze ist sehr kompakt geworden, das eigentliche Ziel der Entwicklung war es, Parameter-Kontrollstrukturen zu verkleineren, das erfolgt dadurch, dass die Control-Method dem jeweiligen URL zugeordnet wird und dank mod_rewrite mehrere URLs über die gleiche main() laufen. Unterschiedliche URLs können so konfliktlos gleiche Parameternamen haben. Alle Methoden sind innerhalb der Response-Class definiert, wobei ich auch von der Möglichkeit Gebrauch mache, eine package in mehrere Dateien.pm aufzuteilen.

Nachteil:
Als Content-Type einer Reponse ist nur text/html möglich und die Response wird immer als: header, start_html, menu, body, end_html; ausgegeben. Aber das war ja auch das Ziel ;)

Schönen Sonntag,
Rolf

modedit Editiert von pq: am ende 6 zeilen mit je einem leerzeichen gelöscht - bitte nicht wiederholen.

Splitted from Thread zum Freuen 2.0 msg #125588
Last edited: 2011-12-05 13:17:52 +0100 (CET)
- +4 replies
- scriptor
  
  2011-12-04 23:51
  
  User since
  2008-05-07
  69 Artikel
  BenutzerIn
  
  2011-12-04T10:29:55 rosti
  Nachteil:
  Als Content-Type einer Reponse ist nur text/html möglich und die Response wird immer als: header, start_html, menu, body, end_html; ausgegeben. Aber das war ja auch das Ziel ;)
  modedit Editiert von pq: am ende 6 zeilen mit je einem leerzeichen gelöscht - bitte nicht wiederholen.
  Ich hoffe, das Menue kommt bei Dir IN den Body... ;-)
  
  Ich bestimme aufgrund der URL etc. eine Datei z.B. "pegel.sc.html". Dabei bestimmt die "erste" Extension den Parser und die "zweite" den Content-Type.
  Ob ich auf Dauer damit glücklich bin, wird die Praxis zeigen. Implementiert habe ich Parser für meine alten Seiten, Perl only, statischen Text und das mein neues Templateformat.
  - +2 replies
  - rosti
    
    2011-12-05 06:23
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Quote
    Ich hoffe, das Menue kommt bei Dir IN den Body... ;-)
    
    Bringt das Vorteile? Bei mir ist das Menu ein extra Abschnitt in der Konfig und wird von Hand da eingetregen. Dargestellt wird es als Liste, die mit CSS formatiert wird, das macht eine etxtra Methode.
    
    Das Menu ist also extra, Vorteil: Wenn der Body aufgrund [ERR] erzeugt wird, bspw. bei einem Status 404, wird das Menu trotzdem gezeigt.
    
    Quote
    Ich bestimme aufgrund der URL etc. eine Datei z.B. "pegel.sc.html". Dabei bestimmt die "erste" Extension den Parser und die "zweite" den Content-Type.
    
    Die Idee ist gar nicht mal so schlecht, ich lasse mir das mal durch den Kopf gegen, danke ;)
    
    @pq:
    
    Code (perl): (dl )
    
    $mesg_body = unpack "A*", $mesg_body;
    
    entfernt automatisch alle Leerzeilen und Zeilenumbrüche am Ende. Ich habe Dir das schonmal nahegelegt, ist es zu schwer, sowas einzubauen?
    - pq
      
      2011-12-05 13:17
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      2011-12-05T05:23:44 rosti
      @pq:
      
      Code (perl): (dl )
      
      $mesg_body = unpack "A*", $mesg_body;
      
      entfernt automatisch alle Leerzeilen und Zeilenumbrüche am Ende. Ich habe Dir das schonmal nahegelegt, ist es zu schwer, sowas einzubauen?
      
      rosti, warum sollte ich das tun?
      verwende du doch stattdessen einfache leerzeilen. die werden dann nicht angezeigt (*).
      klar, aber es ist ja einfacher, mir vorzuschreiben, was ich tun soll.
      glaubst du, ich hab lust und zeit, für jeden, der sich irgendwelche komischen sachen bei seinem posting ausdenkt, einen workaround zu schreiben?
      
      es gibt keinen grund für zeilen mit nur leerzeichen am ende, man kann wie gesagt auch ganz einfache leerzeilen verwenden. daher halte dich bitte daran!
      
      edit: werden sie doch, nur beim thread-erstellen entferne ich sie.
      Last edited: 2011-12-05 13:40:18 +0100 (CET)
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - GwenDragon
    
    2011-12-05 09:49
    
    User since
    2005-01-17
    14533 Artikel
    Admin1
    
    Ähm, würdet ihr bitte das Projekt CGI-Bauskasten unter Projekte weiter ausdiskutieren?
    die Drachin, Gwendolyn
    
    Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- +13 replies
- pq
  
  2011-12-05 13:47
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  in anbetracht der tatsache, dass das ursprünglich im thread zum freuen gepostet wurde - ist das eine mitteilung über deinen lernerfolg oder möchtest du hier ein projekt öffentlich vorstellen?
  in letzterem fall wäre ein link zum code sinnvoll; desweiteren eine beschreibung, was der vorteil gegenüber schon vorhandenen frameworks ist. danke.
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +12 replies
  - rosti
    
    2011-12-06 19:40
    
    User since
    2011-03-19
    3194 Artikel
    BenutzerIn
    
    Dieses Mini-Projekt steht weder im Schatten großer Frameworks, noch ist es deren Konkurrenz.
    
    Es ist einfach die Freude am Selbst-Was-Bauen und die Freude daran, meine eigenen Ideen, die bis ins Jahr 2002 (mindestens) zurückreichen, zu verwirklichen. Ich habe damals schon solche "Baukästen" entworfen und mit Perl umgesetzt, da gabs das Wort "Framework" noch gar nicht und auch Design Patterns wie "MVC" oder "Singleton" war für viele die ich aus diversen Internet-Forums kenne, ein Fremdwort ;)
    
    Mein "neuer CGI-Baukasten" ist nur insofern neu, als dass er eine abgespeckte Version meines seit Jahren eigens entwickelten CMS-Frameworks (oh welch Buzzwort) ist. Diese, meine Entwicklung läuft unter mod_perl, als FastCGI oder als konventionelles CGI und erfordert keine wochenlange Einarbeitung.
    
    Bei Interesse schreibe ich gerne mehr darüber.
    - +11 replies
    - pq
      
      2011-12-06 21:02
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      CGI::Application gibt es z.b. seit 2000, und MVC hab ich, wenn ich mich richtig erinnere, '98 an der uni gehört =)
      
      ich denke nur, dass du das rad neu erfindest und es dir damit zu schwer machst.
      nichts generell gegen das erfinden neuer räder, das hab ich auch schon mehrmals gemacht und oft aus gutem grund (und manchmal hab ich mich hinterher geärgert (*)).
      aber die funktionalität, die du beschreibst, klingt halt nicht sonderlich umfrangreich oder besonders, und eventuell würde es sich für dich lohnen, doch mal in Mojolicious oder Catalyst reinzuschauen.
      
      ich hab neulich in Mojolicious::Lite in wenigen Minuten eine Websocket-App gebastelt, obwohl ich Mojolicious::Lite vorher nie verwendet hatte und auch Websockets noch nie ausprobiert.
      
      edit
      (*) ein beispiel: ich hatte ein eigenes sehr simples templatesystem für eine applikation geschrieben, und als ich neue funktionalität brauchte, war das nicht wirklich integrierbar, und ich hätte erstmal alles umschreiben müssen. das schreiben von HTML::Template::Compiled später war dagegen schon durchdachter und konnte vor allem auf eine existierende, bewährte syntax aufbauen und trotzdem neues bieten.
      Last edited: 2011-12-06 21:06:44 +0100 (CET)
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - +10 replies
      - rosti
        
        2011-12-07 18:59
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Mein CGI-Baukasen beschreibt ein Verfahren. Welches Template-System dabei zum Einsatz kommt, ist völlig Wurscht.
        
        +9 replies
        
        sitescriptor
        
        2011-12-08 00:34
        
        User since
        2009-08-09
        105 Artikel
        BenutzerIn
        
        Wenn es für alles schon Module gibt, dann braucht man über Konzepte eben nicht mehr reden, vielleicht sollte man das in die "Verhaltensrichtlinien" übernehmen.
        Ich will nicht weiter ausholen, jedenfalls gibt es sehr wohl gute Gründe sich selbst mit einem WebFramework/CMS zu beschäftigen.
        
        rosti
        
        2011-12-08 06:14
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Quote
        ..jedenfalls gibt es sehr wohl gute Gründe sich selbst mit einem WebFramework/CMS zu beschäftigen.
        
        Genau! Mögliche Gründe: Plattform-Unabhängigkeit, Perl-Version-Unabhängigkeit, Provider-Unabhängigkeit... und das Ganze umgekehrt ;)
        
        +4 replies
        
        pq
        
        2011-12-08 09:39
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        so ein unsinn, was willst du jetzt mit den verhaltensrichtlinien?
        
        ich sagte lediglich, dass es nicht schaden kann, sich mal bestehende frameworks anzuschauen. ein response-objekt zu haben ist wirklich nichts neues und aussergewöhnliches, und da rosti darüber berichtete, als sei es das und da er ausserdem perl 5.6.1 verwendet, meinte ich, ihm vorschlagen zu können, sich mal umzuschauen.
        
        wer gerne räder erfindet, ohne sich bestehendes anzuschauen, kann das gerne tun und hier auch drüber reden. ich wollte nur helfen.
        
        mein posting wurde anscheinend auch nicht verstanden, worin ich erwähnte, dass ich selbst auch schon räder neu erfunden habe.
        vielleicht fühlt man sich hier aus irgendeinem grund auf den schlips getreten und versucht sich gegen etwas zu wehren, was ich so gar nicht gesagt habe? wer weiss...
        Last edited: 2011-12-08 09:41:42 +0100 (CET)
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +3 replies
        
        rosti
        
        2011-12-09 18:14
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Quote
        ich sagte lediglich, dass es nicht schaden kann, sich mal bestehende frameworks anzuschauen. ein response-objekt zu haben ist wirklich nichts neues und aussergewöhnliches, und da rosti darüber berichtete, als sei es das und da er ausserdem perl 5.6.1 verwendet, meinte ich, ihm vorschlagen zu können, sich mal umzuschauen.
        
        Genau! Schau Dich bei den Providern um. Ein totschickes Framework auf der eigenen Kiste zum Laufen zu bringen, ist keine Kunst und die Frage des Providers endet beim Preis ;)
        
        Hier setzen meine Ideen an, das war schon immer so: Plattformunabhängigkeit, Providerunabhängigkeit, Perl-Version-Unabhängigkeit. Perl 5.8, oder 5.10, ja schön und gut, bietet halt mehr Komfort, was die Unicode-Unterstützung betrifft aber die beginnt nunmal mit v5.6.1. und OOP auch.
        
        Ein Response-Objekt zu erstellen ist auch keine Rad-Neu-Erfindung von mir, beim Content-Management gehts mehr um praktische Fragen, wie z.B. den Aufbau der Layer zur Datenhaltung und wie die Inhalte zum Provider auf die produktive Kiste kommen. Dabei gibt es ungezählte kleinere Problemchen, die löst Du nicht einfach so, indem Du ein Framework von der Stange (entschudligung: CPAN) nimmst.
        
        Schönes Wochenende ;)
        --Rosti
        
        +2 replies
        
        pq
        
        2011-12-09 18:39
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        du willst es vermutlich einfach nicht verstehen.
        oder wozu brauchst du, nur um dir ein framework anzuschauen, perl 5.10 auf einem server?
        
        im übrigen geht es nicht um "todschick" oder cool.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        rosti
        
        2011-12-09 19:05
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Quote
        oder wozu brauchst du, nur um dir ein framework anzuschauen, perl 5.10 auf einem server?
        
        Wieso anschauen? Ich _arbeite_ mit Frameworks ;)
        
        +3 replies
        
        rosti
        
        2012-01-20 20:40
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2011-12-07T23:34:12 sitescriptor
        Wenn es für alles schon Module gibt, dann braucht man über Konzepte eben nicht mehr reden, vielleicht sollte man das in die "Verhaltensrichtlinien" übernehmen.
        Ich will nicht weiter ausholen, jedenfalls gibt es sehr wohl gute Gründe sich selbst mit einem WebFramework/CMS zu beschäftigen.
        
        Genau! http://rolfrost.de/map/article/perlstory.html
        
        viel Spaß beim Lesen, hab ich alles heute abend mal aufgeschrieben ;)
        Schönes Wochenende,
        Rosti
        
        +2 replies
        
        mdickie
        
        2012-06-09 18:59
        
        User since
        2012-04-24
        6 Artikel
        BenutzerIn
        
        Ich finde der CGI Baukasten ist verlorene Zeit. Kein einziger halbwegs professioneller Programmierer oder Unternehmen wird dieses Framework jemals verwenden. Dieser Framework ist ganz einfach zum wegwerfen (Ganz derb ausgedrückt). Mal ehrlich jetzt, ich meine wenn du so eine Framework veröffentlichst, solltest du es wenigstens versuchen es professionell zu machen. Die ordentliche Template Integration fehlt natürlich und die MVC Pattern gefallen mir garnicht. Überhaupt nur weil es auf einer älteren Version von Perl läuft ist heißt es nicht, dass sie besser ist.
        
        Meine Empfehlung an dir:
        * Verwende moderne Techniken, nicht die vom letzten Jahrhundert. Verschwende deine Zeit nicht mit alten Techniken.
        * Übersetze alles auf Englisch (Dokumentation)
        * Entferne PHP, weil Perl ist wirklich ein tolle Sprache. Wenn schon mach eine Abstrahierung. Trenne PHP von Perl. Also z.b. die Framework ist in Perl geschrieben hingegen der Benutzer in PHP schreiben kann.
        * Veröffentlich es auf GitHub hinzu und später vielleicht auf CPAN.
        Ist dir diese Mühe es nicht Wert wechsle zu einer anderen Framework. Ich persönlich würde meinen, dass du das Projekt verwerfen solltest und zu einer Framework wechseln solltest. Ich empfehle dir wärmstens Dancer, Mojolicious und Catalyst.
        
        rosti
        
        2012-06-09 21:15
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Reden wir davon: http://rolfrost.de/map/pf3
        
        Und ja: Welches Templatesystem verwendet wird, steht dem Bauherren völlig frei.
        
        Ich habe dieses Framework unter mod_perl mit Template::Toolkit getestet und das funktioniert einwandfrei. Auch im reinen CGI-Betrieb läuft mein Framework sehr performant, das bewirkt die Code-Verteilung infolge der Bindung der Response an eine eigene Sub-Klasse (per Konfiguration).
        
        MVC: Die Methode control() entspricht dem Controller, diese Methode hat in jeder Responseklasse denselben Namen (Overload).
        
        Die Code-Verteilung ermöglicht klar definierte Schnittstellen, Teamarbeit und einen extrem überschaubaren Code. Anwendungen können innerhalb kürzester Zeit entwickelt werden, weil nur 2 Methoden zu schreiben sind sowie das Template (agile Softwareentwicklung).
        
        Mein Framework ist multidomain und multiuserfähig. Und ich habe es ganz allein entwickelt im Gegensatz zu anderen Frameworks, an denen Tausende beteiligt sind. Mein Framework ist so einfach aufgebaut, dass es beliebig erweiterbar ist ohne diese Einfachheit zu verlieren.
        
        Der Code liegt offen und wie der funktioniert, kann jeder testen. Module können zur Laufzeit im Browser betrachtet werden, original wie sie im Lib-Verzeichnis liegen.
        
        Unit-Tests können mit meinem Framework ebenfalls automatisiert werden. Content-Management kann auf vielfältige Art und Weise erfolgen, FTP, HTTP, ich verwende Beides. Beispielsweise erfolgt das Publizieren/Update einer Seite für meine http://rolfrost.de/map/perlbase per Tastendruck gleich aus dem Editor heraus.
        
        Quote
        Kein einziger halbwegs professioneller Programmierer oder Unternehmen wird dieses Framework jemals verwenden
        
        Da hast Du wohl recht, von halbwegiger Professionalität halte ich auch nicht viel ;)
        
        Programmieren ist keine Kunst sondern Handwerk, schrieb Nicolas Wirth und ich sehe das genauso.
        
        Viele Grüße,
        Rosti
        
        Edit: Was PHP betrifft, guck http://rolfrost.de/map/nicklogin/aktuell
        Hier ist das Template unterhalb __DATA__ in der Responseklasse selbst notiert.
        Die Ähnlichkeit mit PHP ist kein Zufall ;)
        
        Natürlich kann Perl jetzt ein bischen mehr, die Responseklasse in meinem Framework kann das Template auch aus einer DB holen oder aus einer anderen Datei und: Dazu ist in der Responseklasse lediglich die Methode data() zu überschreiben.
        
        Und selbstverständlich kann eine Responseklasse auch so programmiert sein, dass sie zum Ausgeben verschiedener Seiten verwendet werden kann. Und last but not least werden weitere Module, eingebunden in einer Responseklasse, nur dann kompiliert, wenn ein Request genau auf diese Klasse erfolgt (URL-Map: Klasse <=> URL).
        
        Ja, und nochwas: In den Methoden control() und browse() können eigene Exceptions geworfen werden, was Einiges an Kontrollstrukturen vereinfacht.
        Last edited: 2012-06-10 17:59:11 +0200 (CEST)
- rosti
  
  2013-03-25 11:24
  
  User since
  2011-03-19
  3194 Artikel
  BenutzerIn
  
  Die Story begann viel früher: http://rolfrost.de/proglog.html?d=20110501
- +5 replies
- rosti
  
  2013-06-10 18:02
  
  User since
  2011-03-19
  3194 Artikel
  BenutzerIn
  
  Weiter gehts mit der Konsolidierung Perl <=> PHP, d.h., mit dem Baukasten können Anwendungen in Perl oder PHP zusammen verbaut werden.
  
  Ein wichtiger Schritt dazu ist eine gemeinsame Datei für Login-Daten (Benutzername, Zeitstempel, Gruppe), dazu habe ich ein Dateiformat entworfen, was diese PHP-Array's/Perl-Hashes gleichermaßen speichern kann.
  
  Bei dieser Gelegenheit habe ich ein Benschmark gemacht und die Performanze beim Lesen/Schreiben einer textlich strukturierten Dateie mit einer Binärdatei verglichen: http://rolfrost.de/proglog.html?d=20130609
  
  Meine Entscheidung fällt somit auf die Binärdatei und die entsprechenden Moduls habe ich in Perl und PHP fertig:
  http://rolfrost.de/proglog.html?d=20130610
  
  Btw., neben gewissen handwerklichen Fertigkeiten, die ich mir im Lauf meines Lebens angeeignet habe, bin ich ein Bauer geblieben: Pferde zäume ich nicht von hinten auf. Es gibt Leute die sowas machen, z.B. PHP-Session-Dateien mit Perl bearbeiten. Oder maschinell erhobene Daten in XML-Dateien speichern (danke für die bösen Blicke, aber bei jedem HTTP-Request jedesmal eine XML-Datei parsen, das geht auf keine Kuhhaut).
  
  Interessanterweise ist PHP so gebaut, dass der UserAgent die Session-ID vorlegen kann. Genauso handhabe ich das auch in meinem CGI-Baukasten. Somit kann eine mit Perl etablierte Session von PHP übernommen werden und umgekehrt, vorausgesetzt natürlich, dass der UA den Cookie sendet. Genau das macht die Sache mit einer gemeinsam genutzten Login-Datei so einfach.
  
  Vielleicht interessierts ja wayne...
  
  Viele Grüße,
  Rosti
  - +4 replies
  - Raubtier
    
    2013-06-10 19:54
    
    User since
    2012-05-04
    1054 Artikel
    BenutzerIn
    
    Warum schreibst du einen HoH als CSV-Datei raus?! Für mich wäre da der "natürliche" Schritt für Text-Dateien JSON::XS gewesen. Mir scheint immer, du versuchst Räder neu zu erfinden.
    - +3 replies
    - rosti
      
      2013-06-10 22:08
      
      User since
      2011-03-19
      3194 Artikel
      BenutzerIn
      
      2013-06-10T17:54:41 Raubtier
      Warum schreibst du einen HoH als CSV-Datei raus?! Für mich wäre da der "natürliche" Schritt für Text-Dateien JSON::XS gewesen. Mir scheint immer, du versuchst Räder neu zu erfinden.
      
      Du hast meine Artikel gelesen? Danke!
      Leider hast Du nicht richtig gelesen, denn ich schreibe da, dass ich den HoH in einer Binärdatei speichere.
      
      Außer der Login-Tabelle ist für das Framework die komplette Konfiguration und die Routingtabelle in einer solchen Datei gespeichert. Je nach Request greift entweder Perl oder PHP auf diese Datei zu, das hat sich seit Jahren bewährt.
      
      Das Rad neu erfinden? Nein. Das ist alles nüscht Neues. Ich habe nur eine Rakete gebaut, was ein äußerst performantes Laden der Konfiguration ermöglicht. Editiert werden Text-Dateien, das sind bei mir ini-Dateien, die kaskadiert werden und dann:
      
      Kommandozeile:> map
      
      Das linkt die lokalen ini-Dateien zu einer BIN, die zum Remote-Server geht. Das ist mein Deployment.
      
      JSON-Was? Ach komm, hör doch auf. Das brauche ich vielleicht irgendwann einmal an einer anderen Stelle. Alles zu seiner Zeit ;)
      
      Guck Dir den Serialize-Algorithums an, den ich entwickelt habe. Über solche Binary-Sequences kann ich ganze Datenbanken per HTTP(S) zum Remote-Server schaffen.
      
      Viele Grüße,
      Rosti
      
      PS: Die CSV-Datei ist nur dem Verständnis dienlich. Für den erstverlinkten Artikel habe ich weder Zeit noch Mühe gescheut, einen Benchmark zu machen, einen Vergleich des Serialize-Algorithmus auf CSV/BIN angewandt. Die binären Tupel sind anschaulich vergleichbar mit Zeilen einer CSV-Datei.
      Last edited: 2013-06-10 22:12:45 +0200 (CEST)
      - +2 replies
      - Raubtier
        
        2013-06-11 00:50
        
        User since
        2012-05-04
        1054 Artikel
        BenutzerIn
        
        2013-06-10T20:08:30 rosti
        Du hast meine Artikel gelesen? Danke!
        Leider hast Du nicht richtig gelesen, denn ich schreibe da, dass ich den HoH in einer Binärdatei speichere.
        
        Das war nicht mein Punkt, auch wenn ich es vielleicht nicht so deutlich geschrieben habe. Du schreibst einen irgendwie gearteten CSV-Algorithmus und benchmarkst ihn dann mit deinem Binärformat. Ich habe mich gefragt, warum du da nicht einfach einen Einzeiler mit JSON genommen hast. Insbesondere da du so Dinge wie "Nachteile einer CSV-Datei [...]
        in den Schlüsseln und in den Werten darf der Delimiter (Trennzeichen ';') nicht vorkommen." geschrieben hast (und die Lösung als "Workaround" bezeichnest).
        
        Und gerade da du doch gemeinsam mit unterschiedlichen Sprachen zugreifen willst und in beiden JSON extrem einfach ist, würde ich das doch immer einem eigenen Format vorziehen, sofern nicht gute Gründe dagegen sprechen. Außerdem kann man textbasierte Dateien einfach mal im Editor aufmachen und schnell verändern.
        
        rosti
        
        2013-06-11 08:05
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Die Anwendung meiner Module ist einfach, die Migration war in wenigen Minuten erledigt. Logindaten werden maschinell ergoben, diesbezügliche Dateien müssen nicht editierbar sein.
        
        Wenn es um Dateien geht, die editierbar sein müssen, z.B. Konfigurationsdateien, empfehle ich weder JSON noch XML noch CSV.
        
        Viele Grüße,
        Rolf
        Last edited: 2013-06-11 08:38:34 +0200 (CEST)

View all threads created 2011-12-05 13:17.