Artikel - Detailansicht

Icon Aktuelles Fusebox-Methodologie

Die Fusebox Organisation wurde 1997 von Steve Nelson und Gabe Roffman gegründet. Fusebox ist eine Programmierkonvention, die davon lebt, das weltweit Entwickler diese Methoden anwenden, anpassen und weiterentwickeln. Die ständige Weiterentwicklung wird über ein breites Spektrum an Diskussionsforen, Kongressen und Verteilerlisten gewährleistet. Konzepte die sich dabei in der Praxis bewährt haben, werden in die offizielle Fusebox-Methodologie [siehe http://www.fusebox.org] übernommen.

Programmierkonventionen
Eine Programmierkonvention wird wie folgt definiert [Dum01; S. 66]:

"Programmierkonventionen sind Richtlinien bzw. Vorgaben für die Form, die Struktur und den Inhalt des zu erarbeitenden Quelltextes zur Gewährleistung spezieller qualitativer Aspekte."

Es werden folgende Programmierkonventionen unterschieden:
  • Namenskonventionen: Bei diesen Vorgaben geht es einerseits darum, eine einheitliche, gut lesbare Form zu finden und zum anderen mnemonische Aspekte zu verwirklichen.
  • Strukturkonventionen: Diese Richtlinien können beispielsweise die strikte Einhaltung der strukturierten Programmierung fordern oder aber bestimmte Strukturformen, wie die Schleifengestaltung, für eine bessere Änderbarkeit vorschreiben.
  • Kommentierungskonventionen: Diese Art der Vorgaben kann sich auf den Anteil oder die Art bzw. Form der Kommentierung in einem Quellprogramm beziehen.
  • Identifikationskonventionen: Hierbei geht es beispielsweise darum, die Identifikation eines Programms hinsichtlich entwicklerspezifischer Angaben, wie z.B. Programmierername, Erstellungs- und Änderungsdatum, einheitlich zu gestalten.

Die Fusebox-Methodologie vereinigt alle vorher genannten Programmierkonventionen. Die Methode ist nicht an eine bestimmte Programmiersprache gebunden und kann universell eingesetzt werden. Der Einsatz hat sich aber vor allem bei Skriptsprachen, wie ColdFusion und PHP bewährt.

Beschreibung der Fusebox-Methodologie

Ausgangssituation
70 % aller Software-Projekte scheitern oder werden als Fehlschlag eingeschätzt [NeG00; S. 9]. Der Grund hierfür ist oft eine fehlende Methodologie oder eine unstrukturierte Herangehensweisen. Dies gilt ganz besonders für komplexe Software-Projekte. Hinzu kommt, dass vor allem filebasierte Skriptsprachen, wie ColdFusion, eine Tendenz haben unübersichtlich zu werden. Bei diesen Programmiersprachen fehlen meist Konzepte moderner Programmiersprachen, wie z.B. Objektorientierheit und Modularisierung.
Bei der Entwicklung komplexer Webapplikationen sehen Nelson und Girard [NeG00; S. 11] weitere Probleme:
  • Zusammenführung des Codes aller am Projekt beteiligten Programmierer
  • Übergabe einer fertiggestellten Webapplikation an ein anderes Team von Entwicklern
  • Pflege und Wartung von erstelltem Code

Die Fusebox-Methodologie versucht bei diesen Problemen einen Lösungsansatz zu geben.

Konzept der Fusebox Programmierkonvention
Der Name Fusebox (engl. Sicherungskasten) kommt durch die Vergleichbarkeit mit einem Sicherungskasten in einem Haushalt. Das Prinzip ist Module so voneinander abzuschotten, dass falls ein Circuit (Sicherung) ausfällt, die anderen Circuits dadurch nicht beeinträchtigt werden. Das bedeutet: falls ein Modul ausfällt läuft die gesamte Anwendung, abgesehen von diesem Modul, weiter.
Eine Fusebox-Applikation ist in hierarchische Verzeichnisse aufgesplittet. Jedes Verzeichnis baut auf den darunter liegenden Verzeichnissen auf, und hat seine eigene Auswahl an Aktionen (Fuseactions), die ausgeführt werden können. Jede Aktion in einem Verzeichnis wird dabei von einem übergreifenden File (index.cfm) gesteuert und angesprochen.

Die weiteren Hauptbegriffe der Fusebox-Methodologie werden in den nachfolgenden Abschnitten vorgestellt, die Definitionen entsprechen im wesentlichen [NeG00; S. 19ff].

Home Application
Unter der Home Application wird die gesamte Anwendung verstanden. Sie ist das Hauptverzeichnis der Anwendung und beinhaltet die Circuit Applications.

Circuit Application
Die Circuit Applications sind Unteranwendungen bzw. Unterverzeichnisse der Home Application und erweitern deren Funktionalität. Jede Unteranwendung hat ihre eigenen Funktionen und Verantwortlichkeiten, und sollte mit möglichst geringer Abhängigkeiten von der Home Application entwickelt werden (Sicherungsgedanke).

Fuseaction
Da das Internet eine statuslose Umgebung ist, benötigt jede Useranfrage eine Aktion, um dem Server mitzuteilen, was er tun soll. Normalerweise werden diese Aktionen über die aufgerufene Seite definiert. Eine Seite beinhaltet also z.B. einen Hypertextlink oder eine Form-Action um auf eine andere Seite in der Applikation hinzuweisen.
In der Fusebox Methodologie werden alle "Actions" einer Applikation standardisiert behandelt. Diese standardisierte Aufrufe von Actions werden Fuseactions genannt.
Es gibt drei wesentliche Arten um Aktionen an einen Server zu übergeben:
  • als Teil einer URL, z.B.
    http://www.uni-karlsruhe.de/index.cfm?fuseaction=showUser
  • als Formfield-Variable:
  • oder als Browser-Cookievariable

Fuse
Bei einem Fuse handelt es sich um eine einzelne Datei, welche von der index.cfm angesteuert wird um eine bestimmte Funktion auszuführen. Als Beispiel sei eine Fuseaction mit 3 Fuses gegeben: eine Datei stellt das Formular zur Usereingabe bereit, ein weiteres File schreibt die Informationen in eine Datenbank und wiederum eine andere Datei sendet eine Benachrichtigung per Email.
Auch für diese unterschiedlichen Arten von Fuses gibt die Fusebox Organisation Namenskonventionen vor. Sie definiert dabei sechs verschiedene Arten von Fuses:

Application Files ("app_filename.cfm") sind Dateien, die zu einem kompletten Circuit gehören. Die zwei am häufigsten benutzten Typen sind:
  • App_globals.cfm: diese Datei beinhaltet Informationen, die in der gesamten Anwendung bekannt sein müssen (globale Variablen). Ein Beispiel ist der Name einer Datenquelle, die von der Home Application, als auch von den einzelnen Circuit Applications, benutzt wird.
  • App_locals.cfm: beinhaltet Informationen, die nur innerhalb einer bestimmten Circuit Application verwendet werden (lokale Variablen).

Display Files ("dsp_filename.cfm"): Diese Dateien liefern eine Ausgabe. Sie beinhalten HTML und CFML, sowie andere clientseitige Prozesse wie JavaSkript oder XML. Sie werden für die Darstellung von Datenbankabfragen oder Formularen verwendet. Display Files sollen keinen CFML Code beinhalten, der nicht zur Darstellung der Seite benötigt wird. Längere CFML Befehlssequenzen werden in einer externen Action Files Datei abgelegt.

Action Files ("act_filename.cfm"): Diese Dateien liefern keine Ausgabe. Sie werden eingesetzt um Informationen auf dem Server zu verändern. Action Files beinhalten CFML und SQL, aber kein HTML. Die SQL-Anweisungen können allgemeine SQL Kommandos, wie UPDATE, INSERT, usw., beinhalten, aber auch Stored Procedures einer Datenbank aufrufen.

Query Files ("qry_filename.cfm"): Diese Dateien beinhalten nur SELECT SQL Abfragen, und Aufrufe von Stored Procedures. Normalerweise werden sie nur dann verwendet, wenn eine Abfrage von mehreren Fuses benutzt wird. Diese Dateien sollten von anderen Templates unabhängig sein, und nur die SQL Abfrage beinhalten. Anderer Code sollte im Sinne einer Wiederverwendung möglichst vermieden werden.

Redirection Files ("url_filename.cfm"): Diese Dateien werden verwendet um Benutzer auf eine Seite zurückzuführen. Dies ist nützlich um den User beim Aktualisieren abzuhalten wiederholt Informationen an ein Formular zu übergeben. Diese Datei beinhaltet nur das <CFLOCATION> Tag.

ColdFusion Custom Tags (CF/CFX Tags): Diese Dateien sind ColdFusion Erweiterungen. Der Fusebox Standard verbietet diese Erweiterungen nicht, bezieht sie aber auch nicht explizit in die Methodologie ein.

Index.cfm: Diese Datei ist das Herz jedes Circuits. Sie fasst einzelne Fuses zu Fuseactions zusammen. Jeder Aufruf muss durch eine index.cfm erfolgen (Kapselung).
Das wichtigste Konstrukt einer index.cfm ist das <CFSWITCH>-Tag. Nachfolgend ein Beispiel:

<!--- Includen der globalen Variablen --->
<cfinclude template="../../../app_globals.cfm">
<!--- Nachfolgend die einzelnen Fuseactions --->
<cfswitch expression="#attributes.fuseaction#">
  <!--- Fuseaction Login --->
  <cfcase value="userLogin">
    <cfinclude template="dsp_loginform.cfm">
    <cfinclude template="qry_getUser.cfm">
    <cfinclude template="act_login.cfm">
  </cfcase>
  <!--- Fuseaction Error --->
<cfcase value="userLogin">
    <cfinclude template="dsp_error.cfm">
  </cfcase>
</cfswitch>


Wie man dem obigen Beispiel entnehmen kann, erfolgen alle Aufrufe der index.cfm in der Form: #attributes.fuseaction#. Erfolgt ein Aufruf durch eine URL-Variable, z.B. http://www.domainname.de?fuseaction=userLogin, so muss deren Scope "url" zuerst in "attributes" umgewandelt werden (gleiches gilt für Form-Variablen mit dem Scope "form"). Dies geschieht mit dem unter http://www.fusebox.org erhältlichen Custom Tag <cf_formurl2attributes>, das in die app_globals.cfm eingebunden werden muss.

In der folgenden Abbildung wird das Zusammenspiel der einzelnen Fusebox-Komponenten veranschaulicht:


Abbildung: Fusebox-Schema



Fazit
Die Einhaltung der Fusebox-Methodologie bietet folgende Vorteile [NeG00; S. 12]:
  • Der Code ist strukturiert und kann von Anderen schnell gelesen werden.
  • Fusebox-Module können einfach erweitert und gepflegt werden.
  • Durch die Trennung in Action-, Display- und Query-Files müssen bei Änderungen nur die entsprechenden Dateien geändert werden.
  • Fusebox-Module können einfach in andere Anwendungen integriert werden.
  • Fällt ein Modul aus, kann der Rest der Anwendung unabhängig davon weiterarbeiten.

Fusedocs
Die Kommentierungskonventionen der Fusebox-Methodologie werden in Fusedocs umgesetzt. In einem Fusedoc wird alles dokumentiert, was ein Programmierer wissen muss, um einen Fuse zu programmieren.
Im Folgenden wird ein Beispiel eines Fusedocs gegeben, anschließend werden die einzelnen Komponenten erläutert.
<!---
|| BEGIN FUSEDOC ||
|| RESPONSIBILITIES ||
File überprüft ob User der Datenbank bekannt ist.
Falls ja, Rückgabe login= 1, ansonsten login = 0.
|| HISTORY ||
Author: Florian Eisele
|| ATTRIBUTES ||
--> form.username: a STRING
--> form.password: a STRING
<-- attributes.login: a NUMBER (0|1)
|| END FUSEDOC ||
--->


Das Fusedoc wird als ColdFusion-Kommentar implementiert. Jedes Fusedoc beinhaltet Sektionen, die durch "||" begrenzt werden, die verwendeten Sektionen sind dabei nicht festgelegt. Dadurch wird die Anpassungsfähigkeit an spezifische Anforderungen gewährleistet.
[NeG00: S. 108] beschreibt die einzelnen Sektionen folgendermaßen:
Responsibilities: beschreibt die Aufgabe des jeweiligen Fuses.
History: beinhaltet die Namen des Programmierers. Je nach Bedarf können hier auch Versionsnummern, Datum und andere Autoren als Information angegeben werden.
Attributes: Gibt die, für den Fuse benötigten und vom Fuse zurückgegebenen, Parameter an.

Ein Eintrag in der Sektion Attributes gestaltet sich folgendermaßen [NeG00; S. 109]:
[Herkunft] [Name] [Datentyp] [Erlaubte Werte]
Beispiel: --> form.geschlecht: a STRING (male|female)

Die Ausprägungen der einzelnen Angaben werden nachfolgend erläutert:
Information über die Herkunft der Variable. Mögliche Werte sind:
  • -->: Variable wird an Fuse übergeben
  • <--: Variable wird von Fuse zurückgegeben
  • <->: Eine durchgereichte Variable. Die Variable wird an den Fuse übergeben und ohne Veränderung an der Variable weitergegeben
  • ++>: globale Variablen, die dem Fuse zur Verfügung stehen (z.B. Session- oder Application-Variablen)
  • <++: globale Variablen, die durch den Fuse gesetzt werden
  • +++: Eine Datei, die der Fuse benötigt um zu funktionieren
Name der Variable (inklusive dem Variablenscope). Gültige Beispiele sind:
  • request.dsn
  • session.myName
  • application.supportEmail
  • [badLogin]

Sind [..] um eine Variable gesetzt, so wird die Variable weitergegeben, aber nicht oder nur unter bestimmten Umständen benötigt.

Datentyp der Variable. Obwohl ColdFusion keine expliziten Datentypen verwendet, kann es hilfreich sein Angaben zum Datentyp zu machen. Beispiele dafür sind:
  • a STRUCTURE
  • a LIST
  • a STRING

Erlaubte Werte. Gibt Restriktionen oder Default-Werte an. Siehe folgende Beispiele:
  • myQuery: a QUERY RESULTSET (userID, firstName, lastName) gibt an, das der Ergebnis-Query aus den Spalten userID, fristName und lastName besteht.
  • accessLevel: a STRING (A | B) gibt an, das die Variable accessLevel entweder "A" oder "B" ist, aber nicht Beides.
    Zusätzlich können weitere Operatoren verwendet werden, Beispiele hierfür sind:
    • ? Optional
    • + Ein oder mehr
    • * keins oder mehr

    Diese Operatoren entsprechen den XML DTDs (Document Type Definition).

    Florian Eisele florianeisele@yahoo.de - 12.12.2001

  • Zurück


    Das deutsche ColdFusion-Forum cfml.de ist das Portal für Einsteiger und Experten zum Thema ColdFusion und der ColdFusion Markup Language (CFML).

    © 2017 Webdesign & Hosting: CHC ONLINE Kassel | SOLVA Content-Management-System CMS
    Urlaub-Angebote.de - Urlaub mit Bestpreis-Garantie buchen