3. Interface Design eines CGI Library

Interface Design eines CGI Library

  • S

    Hallo Leute!

    Ich schliesse mich kingruedi gleich an und frage euch ob meine Library so passt.
    Ich designe sie naemlich gerade um 😉

    Folgende Klasse gibt es:

    CPPGI

    • Singleton
    • parst alle Variablen (GET, POST, COOKIE) im Ctor
    • die direkte Verwaltung der Variablen uebernimmt managaVar

    manageVar

    • abstrakte Basisklasse
    • abgeleitete Klassen sollen variablen handhaben (zB als map, vector,...)
    • wird den Ctor von CPPGI uebergeben

    Environment

    • singleton
    • hat eine menge get-Methoden fuer alle CGI Environment Variablen

    HTTPHeader

    • Basisklasse fuer die HTTP Header informationen
    • Im Ctor kann der User alle Header informationen selber angeben

    HTTPContentHeader

    • public von HTTPHeader abgeleitet
    • ist fuer Content typen da, zB HTML,...
    • der User kann nur den type angeben, andere Angaben sind unzulaessig

    HTTPHTMLHeader

    • public von HTTPContentHeader abgeleitet
    • im Ctor kann nichts angegeben werden
    • beinhaltet alles fuer den Content Type HTML

    HTTPRedirectHeader

    • public von HTTPHeader abgeleitet
    • im Ctor kann der User die URL angeben zu der redirected werden soll.

    Cookie

    • beinhaltet alle informationen die ein cookie braucht
    • kann an HTTPHeader per SetCookie() uebergeben werden

    htmlTag

    • basisklasse fuer alle HTML Tags

    htmlAtomTag

    • klasse fuer alle atom-Tags zB <img>, <br>,...
    • liest HTML::isXHTML() aus um zu wissen, ob sich der Tag selber zu schliessen hat-> <img> in XHTML sieht so aus <img />

    htmlBoolTag

    • Klasse fuer alle boolean-Tags zB <b>, <p>,...

    htmlAttribute

    • Klasse fuer alle HTML Attribute, zB class="foo", border="0",...
    • wird per set() an htmlTag-Objekte uebergeben

    HTML

    • singleton
    • stellt wichtige informationen ueber die aktuelle HTML Version bereit
    • im Ctor wird die HTML Version vom User angegeben
    • sollte HTML nicht instanziiert werden, dann schliessen sich htmlAtomTag Objekte nicht

    und jetzt noch ein kleiner Beispielcode:

    int main()
{
  CPPGI& cgi=CPPGI::Instanciate();
  cout<<HTTPHTMLHeader(); //gibt den header aus: Content-Type: text/html
  cout<<HTML::Header(html_401); //gibt den doctype fuer HTML 4.01 aus
  cout<<html().set(HTMLAttribute("lang","de")); //html() returned htmlBoolTag("html")
  //HTMLAttribute("lang","de") erzeugt das Attribute lang="de"
  cout<<"hello world";
  cout<<html().close();
}

    das Design ist leicht an das design von cgicc angelehnt.

    Was haltet ihr davon?
    mich stoert es etwas, dass ich 3 singletons habe...

    und noch eine Frage:
    sollte Environment die ganzen Umgebungsvariablen schon im Ctor auslesen (sind ca. 20) oder lieber erst wenn der User eine Variable anfordert?

    danke das ihr euch soviel Text antut 🙂

    0
  • M

    Dass ich die HTML Hilfsklassen für überflüssig halte, ist dir glaub ich schon bekannt...
    Dann frag ich mich: Lohnt sich die Environment Klasse?
    Und dann würde mich der Code zum Cookie Zeugs interessieren...

    0
  • S

    Original erstellt von Mr. N:
    Dann frag ich mich: Lohnt sich die Environment Klasse?
    Und dann würde mich der Code zum Cookie Zeugs interessieren...

    Environment insofern, als dass du zB adminMail noch haendisch hinzufuegen koenntest, oder aehnliches.
    dann machst du so:
    env.addVar("adminMail","admin@mail.de")
    und kannst ueberall im script darauf zugreifen:
    env.getVar("adminMail");

    insofern denke ich, dass die klasse nicht schadet. und wie bei allen features meiner lib: du zahlt nicht dafuer, wenn du es nicht brauchst. einfach kein #include<cppgi/environment.h> und du sparst dir die klasse 🙂

    den cookie code, habe ich dir schon im IRC gegeben, ansonsten http://sourceforge.net/projects/cppgi
    das ist aber die alte version, die ich ja gerade redesignen will 🙂

    0
Anmelden zum Antworten