http://svnbook.red-bean.com/
englisches Handbuch

http://www.ch-becker.de/?Subversion
deutsche Dokumentation

http://www.polarion.org/index.php?page=overview&project=subtrain
Schulungsunterlagen SubTrain (en)

http://www.subversionbuch.de/
DAS deutsche Handbuch zu Subversion

http://www.woerter.at/dud/stuff/subversion.pdf
PDF vom Flörian Wörter

https://www.bsdwiki.de/Subversion
deutsches WIKI über Subversion

Aus mehreren Gründen sollte ein einziges Projekt in ein einzelnes Repository abgelegt bzw. importiert werden.

  1. Der Übersichtlichkeitshalber
  2. Aus Performancegründen
  3. Einzelnen Module lassen sich besser integrieren, sichern etc.

Es sollte aus sehr gut überlegt werden, was man als Projekt bezeichnet. Ist ein Projekt ein einzelnes Modul oder etwas welches ein einzelner Mitarbeiter bearbeitet.

Die Frage ist dabei auch was dann zu einem Projekt gehört. Nur die QuellCode-Dateien oder evtl. auch vorhandene Word-Dokumente. Und evtl. Datenbanken oder sind diese dann wieder ein einzelnes Projekt. Die Frage hierbei ist eben wie die Daten schlussendlich eingesetzt werden sollen.

In Subversion bekommt jedes Projekt ein eigenes SVN-Repository. Das muss zwar nicht sein, erleichtert aber eine spätere Administration um einiges, weil die Repositories kleiner und schneller etc.

Um nun mit dem SVN-Client Tortoise arbeiten zu können müssen nun die Projekt-Dateien importiert werden. Da es sich im SVN standardmässig 3 Verzeichnisse als Best-Practice herausgestellt haben, nutzen wir es auch so.

Rufen Sie mit der rechten Maustaste zb. auf dem Desktop, den SVN-Client auf /TortoiseSVN/Repo-browser/ und bei der Frage nach einer URL geben Sie bitte svn://localhost/ oder eben den Namen bzw. die IP des Servers auf dem der Subversion-Server installiert ist, ein: svn://192.168.100.100/ oder der Name wie: svn://subserver.MyDomainName.ch/

Es sollten hierbei keinerlei Fehlermeldungen kommen, andernfalls ist ihr Subversion nicht richtig getartet. Bei Fehlermeldungen schauen Sie daher bitte in Ihre Diensteübersicht nach ob dieser Dienst auch tatsächlich gestartet ist.

Geben Sie anschliessend bitte zusätzlich den Namen Ihres Repositories an: svn://localhost/myProjectName und erstellen dort dann bitte folgende 3 Ordner: trunk , branches und tags . BIm Dokument BestPractices findet ihr auch weitere Infos. Ebenso im Wikipedia von Subversion .

import
zuerst müssen einmal alle Dateien mit denen gearbeitet werden soll in das zuvor erstellte Repository also in die Datenbank von Subversion importiert werden

config
In der Regel wird eine WebAplication unter dem Root des WebServers und dann darunter mit dem Namen der WebApplication erstellt. Also zb. die Application myCoolWebApp also beim IIS komplett unter:  c:InetpubwwwrootmyCoolWebApp

1. Nun „gehen“ wir mit dem Windows Exlporer auf dieses Verzeichnis mit der rechten Maustaste „tortoiseSVN/Import..“ bei der URL geben Sie dann zb. ein: svn://localhost/myCoolWebApp
2. Sehen kann man das Repository dann durch klicken mit der rechten Maustaste und der Auswahl „TortoiseSVN/Repo Browser“ und dann die Eingabe: svn://localhost/

Da gibt es dann das DIR: myCoolWebApp welches dann genutzt werden kann wie zuvor im Tutorial beschrieben wurde.

Das Ergebnis sollte dann im Repo-Browser wie folgt aussehen: svn://localhost/myCoolWebApp/trunk oder svn://svn.myDomainName/mySampleApp/trunk/1.2.2 .

Um mit allen möglichen Dateien arbeiten zu können ist das geniale Client-Tool Tortoise notwendig, welches sich direkt in Windows integriert.

download
1. http://tortoisesvn.net/downloads zb. die 32bit-Installerversion TortoiseSVN-1.4.5.10425-win32-svn-1.4.5.msi
2. Darunter erscheint dort auch eine Liste der jeweiligen verfügbaren Sprachen (Languagefiles)

install
Die beiden *.Exe-Datein dann wie von Windows gewohnt aufrufen:
Wenn dann alles installiert ist wird warscheinlich ein Neustart von Windows notwenig sein, weil das Tortoise sich eben direkt in das Windows integriert.

Im letzten Schritt wurde der Subversion-Server in einem DOS-Fenster gestartet, damit aber nicht immer ein DOS-Fenster geöffenet bleiben muss, nur damit der Server läuft, sollte man den Server als Windows-Service installieren.

download
1. Hier bei mir unter https://landstrasse.ch/downloads/online/Subversion/SVNService.exe

install
1. Die Datei SVNService.exe in das Programmverzeichnis kopieren, also zb. nach: c:programmesubversionbin
2. Dort muss dann das Tools aufgerufen werden: SVNService -install -d -r D:Subversion
3. Danach kann man unter /SystemSteuerung/Dienste das Tool als Service sehen, dort sollte man dann einstellen das dieser Server automatisch gestartet wird
4. Deinstallieren kann man dann dieses Tool bzw. diesen Service im übrigen mit: SVNService -remove

Eine Alternative stellen die Bordmittel von Windows dar, das Service Control-Tool (SC.exe ) von Microsoft, um das Subversion als Systemdienst laufen zu lassen. Funktioniert aber unter Windows VISTA so nicht.

In jedem Fall muss eine Batch-Datei erstellt werden zb. SVNservice.bat die die oben genannte Zeile beinhaltet. Diese Batch-Datei muss dann noch „Als Administrator ausführen… “ (mit der rechten Maustaste auf der Batch-Datei) gestarten werden.

Unter VISTA bei /Start/Einstellungen/Systemsteuerung/Verwaltung/Dienste/ sollte der Dienst dann (installiert) bzw. in der Liste zu sehen sein. Durch Doppelklick auf diesen Dienst muss er zum einen gestartet werden und kann zum zweiten automatisch getartet werden (bei jedem Neustart von Windows).

WICHTIG : Der Dienst muss nur auf das Basis-Verzeichnis der/aller Repositories zeigen! Zu beachten ist dabei der der Service bei der Installation auf ein echtes bestendes Repository zugreifen muss und NICHT nur auf das Basis-Dir.

Im letzten habe ich gezeigt, wie eine neue bzw. weitere Seite über Mach-II aufgerufen wird. Nämlich per impliziten Aufruf, welche in der Config-Datei von Mach-II eingetragen und dann per erzeugtem Event im Formular als action ausgeführt wird.

Da es natürlich notwendig ist die, vom Anwender, eingegebenen Daten zu überprüfen, bevor sie in einer Datenbank oder sonst wo landen, ist daher eine Validierung der Daten angebracht. Also wie das Ganze nun mit Mach-II.

Um den bestehenden Code nun nach dem tatsächlichen Ablauf logisch und Schritt für Schritt zu ändern, tun wir das als erstem in der Formulardatei myHelloForm.cfm selbst, in dem wir den action-Parameter des form-Tags anpassen.

VORHER

name= "myHelloForm" method= "post" action= "index.cfm?event=myHelloFormResponse" >

NACHHER
name= "myHelloForm" method= "post" action= "index.cfm?event=myHelloFormSubmit" >


Als nächstes muss natürlich auch wieder ein EventHandler definiert werden, der eben den neuen Event handelt und der in unserem Beispiel einen Listner zur Validierung der Daten, mit dem Paramter der aufzurufenden Funktion bzw. Methode, aufruft. Lilstner
event= "myHelloFormSubmit" access= "public" >
 
listener= "myValidFormListener" method= "validateInput" />

 
Der Listner selbst muss dann natürlich auch erst noch definiert und dann programmiert werden. Die Definition erfolgt, wie immer, in der Configdatei von Mach-II innherhalb des akt. Projektes. Der Typ des Listners entspricht dem Pfad inkl. Name der CFC. Entweder von WebRoot aus oder per Mapping und der Listner c:inetpubwwwrootHelloFormcontrollerbomyValidFormListner.cfc als HelloForm.controller.bo.myValidFormListner angegeben ohne die Dateiendung CFC.

 
name= " myValidFormListener " type= "HelloForm.controller.bo.myValidFormListener" />

Wo dieses CFC im übrigen dann abgelegt wird ist prinzipiell völlig egel, solange der Pfad dorthin stimmt. Da es eine CFC ist, in dem Fall ein Listner, die eine BusinessLogik (BO) enthält und auch eine Controllerfunktion ist, habe ich meine CFC entsprechend im Verzeichnis ..controllerbo.. abgelegt.

So, und nun wird es etwas komplizierter bzw, schneller ;-)
Als nächstes nun der Code der ValidatorRountine myValidFormLlistner.cfc, die prinzipiell zwar ganz normalen ColdFusion-Code enthält, aber zum einen das MachII-Framework zur Vererbung (extends="MachII.framework.Listner") bemüht und zum anderen nach den eigentlichen Prüfungen, weitere Event aufruft, bzw. über announceEvent weiterführende Events announced.

displayname= "myValidFormListener" extends= "MachII.framework.Listener" >

name= "configure" access= "public" returntype= "void" >

name= "validateInput" access= "public" returntype= "void" output= "false" >
 
name= "event" type= "MachII.framework.Event" required= "true" />

  var inputValid = true />
  var myErrors = arrayNew ( 1 ) />
     

 
  NOT isNumeric (arguments.event.getArg( ‚plz‘ )) >
    inputValid = false />
    arrayAppend (myErrors, ‚Bitte geben Sie eine numerische Postleitzahl ein‘ ) />
 
 
len (arguments.event.getArg( ‚vorname‘ )) IS 0 >
    inputValid = false />
    arrayAppend (myErrors, ‚Bitte geben Sie einen Vornamen ein‘ ) />
 
           

  inputValid >
    announceEvent( "myHelloFormResponse" , arguments.event.getArgs()) />
 

    arguments.event.setArg( "errorMessages" , myErrors) />
    announceEvent( "invalidInput" , arguments.event.getArgs()) />
 

Die wesentlichen Punkte sind in der if-Abfrage nach dem Wert von invalidInput , welcher Eingangs auf true gesetzt und per var -Befehl als locale Variable innerhalb dieser Funktion deklariert wurde. Um in diesem Tutorial etwas Quellcode zu sparen, habe ich nur die PLZ und den Vornamen überprüft, welcher die inputValid Variable auf false setzt, sollte ein Fehler aufgetreten sein.

Damit aus dem Ganzen auch noch ein Schuh wird, ist es notwendig das der jeweilige Event aufgerufen wird, bei entsprechendem Fehler oder eben nicht. Wurde also ein Fehler gefunden, wird der Event invalidInput aufrgerufen, bei dem zuvor noch die/alle Fehlermeldungen "eingesammelt" werden. Und bei einer erfolgreichen Prüfung die ganz normale, zuvor von uns definierte, Antwortseite des Formulars aufgerufen bzw. natürlich dessen Event .

Um den entsprechenden Event auch aufrufen zu können, sollte denn ein Fehleraufgetreten sein, muss hierzu natürlich auch ein entsprechender EventHandler definiert werden. Und wo? Jebbs, natürlich auch wieder in der Configdatei von Mach-II, bzw. dessen Projektes und in diesem Fall im Verzeichnis /HelloForm/config/mach-ii.xml .
event= "invalidInput" access= "private" >
 
event= "myHelloForm" copyEventArgs= "true" />

So, nun funktioniert der eigentliche Ablauf und wir sollten uns im nächsten Kapitel noch um das sichern der Daten kümmern.

 

Um mich zuerst um den Ablauf der Formulare innerhalb von Mach-II zu kümmern, möchte ich dies als erstes zeigen und im zweiten Schritt die Validierungen etc. besprechen.

Mach-II ist eventbasiert, dass heisst das immer zuerst ein Event erzeugt werden muss. Das kann, zb. über einen Mausklick auf einen Link, vom Anwender aus kommen oder wie in diesem Fall aus einem abgeschickten Formular. Technisch gesehen aus den Methoden POST und GET, welche dann in den ColdFusion-Scopes FORM und URL verfügbar sind.

Die Antwortseite selbst belasse ich der Übersicht halber sehr schlank, welche wie folgt aufgebaut ist:


  </span><span style="color: black" mce_style="color: black">myHelloFormResponse</span><span style="color: navy" mce_style="color: navy">


 

Die Scopes


 
var= "#form#" />
 
var= "#url#" />
 
var= "#event#" />

Um ein bzw. das Formular nun korrekt abschicken zu können wurde im Action-Parameter des Formulars bereits im vorherigen Kapitel der Event myHelloFormResponse eingetragen:

"index.cfm?event=myHelloFormResponse" >

Danach muss natürlich ein entsprechender EventHandler und die entsprechende Seite unter PageViews , in der Config-Datei von Mach-II eingetragen werden.
event= "myHelloFormResponse" access= "public" >
 
name= "myHelloFormResponse" />

und den View der schlussendlich aufgerufen werden soll:
name= "myHelloFormResponse" page= "/views/myHelloFormResponse.cfm" />

Somit sollte beim Klick auf den Submit-(Absende-)Button des ursprunglichen Formular eben die Antwortseite aufgerufen werden, welche lediglich die bestehenden Scopes (form,url,event) anzeigt.
Im nachfolgenden Kapitel zeige ich dann wie eine einfach Validierung der Formulardaten in Mach-II erfolgt.

Hier nun der erste von zwei Teilen des Formulars welche nacheinander zwischen den beiden -Tags gesetzt werden. Prinzipiell ganz normales ColdFusion eben.

Dieser erste Teil ist lediglich für das ErrorHandling zuständig und sorgt dafür evtl. generierte Fehler eine entsprechende einfache Meldung ausgeben.
event.isArgDefined( ‚errorMessages‘ ) >
 
errorMessages = event.getArg( ‚errorMessages‘ ) />
 

style= "clear:both; border:1px solid red; color:red;" >
 

   
from= "1" to= "#arrayLen(errorMessages)#" index= "myMessage" >
     
– #errorMessages[myMessage]#

/>
   

 

 


Dieser zweite Teil des Formulars ist, wie man unschwer erkennen kann, das eigentliche Formular.

name= "myHelloForm" method= "post" action= "index.cfm?event=myHelloFormResponse" >
  Vorname
type= "text" name= "Vorname" value= "#event.getArg(‚Vorname‘)#" />
/>
  PLZ
type= "text" name= "plz" value= "#event.getArg(‚plz‘)#" />
/>
  Ort
type= "text" name= "ort" value= "#event.getArg(‚ort‘)#" />
/>
 
Land
/>
/>
 
type= "submit" name= "submitHelloForm" value= "Speichern" >

Sollte über die Mach-II Funktion getArg() und als Parameter der Name des gewünschten Arguments zb. PLZ bzw. Postleitzahl (#event.isArgDefined(‚plz‘)# ) nicht vorhanden sein, so gibt Machh-II zwar keinen Fehler aus. Trotzdem empfiehlt es sich die von Mach-II zur Verfügung gestellte Funktion event.isArgDefined() zu nutzen.

Also statt lediglich #event.isArgDefined(‚plz‘)# den input-Value wie folgt zeigen:
event.isArgDefined( ‚plz‘ ) > #event.isArgDefined(‚plz‘)# .

Damit es nun keine Fehlermeldung beim Abschicken des Formulars gibt, wird im Kapitel 3 dieses Tutorials eine Antwortseite festgelegt und erstellt.

Nachdem ich erst kurz einleitend geschrieben habe worum es geht, nun das Tutorial um ein Formular bzw. dessen Inhalt zu speichern. Das Tutorial zeigt wie die Daten von der Formularseite in die Antwortseite übertragen werden bzw. wie Mach-II spezifisch auf die Daten zugegriffen werden kann. Inkl. ErrorHandling über einen Mach-II-Listner.

Über ein Mach-II Bean und einem DAO in die Datenbank geschrieben werden. Der Einfachkeit halber schreibe ich die Daten lediglich in eine CSV-Datei.

Nachdem also das MachII Framework als lauffähig getestet wurde, ändere ich den defaultEvent in der {AppRoot}configmach-ii.xml von:
name= "defaultEvent" value= "home" /> in
name= "defaultEvent" value= "myHelloForm" /> ab.

Als nächstes muss ich natürlich auch einen EventHandler definieren, der diesen Event handelt. Logisch. Sonst würde der Event myHelloForm ja ins leere laufen. In diesem Fall muss der Eventhandler lediglich eine bestimmte Seite aufrufen, daher:
event= "myHelloForm" access= "public" >
 
name= "myHelloForm" />

also komplett im Code dann:

 
event= "home" access= "public" >
   
name= "home" />
 

 
event= "myHelloForm" access= "public" >
   
name= "myHelloForm" />
 

 
event= "exception" access= "private" >
   
name= "exception" />
 

Damit es nun keine Fehlermeldung gibt das die Seite nicht vorhanden ist, lege ich diese schon mal in meiner Config-Datei unter page-views fest:
name= "myHelloForm" page= "/views/myHelloForm.cfm" />


 
name= "myHelloForm" page= "/views/myHelloForm.cfm" />
 
name= "home" page= "/views/home.cfm" />
 
name= "exception" page= "/views/exception.cfm" />


und erstelle diese natürlich dann auch direkt danach. Zur Kontrolle erst nur die abgespeckte Version, die dann im Kapitel 2 dieses Tutorials , zu einem richtigen Formular ausgebaut wird:

xmlns= "http://www.w3.org/1999/xhtml" >

 
http-equiv= "Content-Type" content= "text/html; charset=utf-8" />
 
</span><span style="font-size: 9pt; font-family: ‚Courier New‘; color: black" mce_style="font-size: 9pt; font-family: ‚Courier New‘; color: black">myHelloForm – [Mach-II]</span><span style="font-size: 9pt; font-family: ‚Courier New‘; color: navy" mce_style="font-size: 9pt; font-family: ‚Courier New‘; color: navy">

Hier kommt das Gerüst (Teil 1) für meine Formularseite…


So ein verregneter Sonntag nachmittag hat schon etwas für sich. Man kann endlich etwas richtig sinnvolles tun, nachdem man den Vormittag am Zürisee entspannt in der Sonne gelegen hat und einem richtig guten schwedischen Magier zugeschaut hat.

Mein Lieblinkssender Radio Zürisee begleitet einem übrigens auch vor dem Rechner noch den ganzen Nachmittag…anyway ;-)

Mehr aus eigenem Interesse, zu Dokumentationszwecken und Weiterbildung habe ich, mit Hilfe von Google und Kollegen ein einfaches Formular in Verbindung mit Mach-II erstellt. So das es nun relativ einfach sein sollte sich in die Strukturen dieses Frameworks einzudenken und somit schnell und effizient nutzen zu können. Naja, zumind. ist es das Ziel…*g*

Warum gerade Mach-II (wird in diesem WIKI-Artikel recht gut erklärt)?
Weil ich von einem Framework erwarte, das es mir in erster Linie repetive und strukturelle Arbeit abnimmt (geistig wie körperlich), meine kreative Genialität aber trotzdem unterstützt. Mach-II hat im übrigen nichts mit der Geschwindigkeitsmasseinheit zu tun, sondern leitet sich von impliziten Aufrufen (I mplicit I nvocations ) ab.

Also los geht’s
Schritt 1: Auf die Seite von Mach-II gehen
Schritt 2: den Quellcode des Frameworks runterladen
Schritt 3: Auf dem eigenen Web-Servers entpacken

Danach sind nur noch ein paar kleine individuelle Anpassungen notwendig um das Framework up&running zu bekommen. Eine komplette Installationsanleitung gibt es bereits unter Installation der Version 1.5 hier auf der Landstrasse.

Das man über ColdFusion auch direkt an JAVA-Funktionen heran kommt ist ja bekannt. Hier mal ein weiteres Beispiel für SystemInformationen um unter anderem den Hardware-Namen der Maschine heraus zu bekommen.

name= "getSystemInfo" access= "public" returntype= "Any" output= "false" hint= "returns the computers systemname and/or IP [:##getSystemInfo(‚?‘)##

]" >
  name= "type" required= "false" default= "" hint= "getSystemInfo(‚?‘)" >
 
var mySystem = createObject ( ‚java‘ , ‚java.net.InetAddress‘ ).getLocalHost() >
 
var mySystemInfo = "" >

  expression= "#lCase(arguments.type)#" >
 
value= "?" >
   
variable= "mySystemInfo" >
     

     


     


       


       


       


     


     


       


       


       


     


     


       


       


       


     


     


       


       


     


     

getSystemInfo(‚Name‘) #getSystemInfo(‚Name‘)# returns the ComputerName of the Maschine
getSystemInfo(‚IP‘) #getSystemInfo(‚IP‘)# returns the IP-Address from the Server
getSystemInfo(‚!‘) #getSystemInfo(‚!‘)# cfDump from all Methods
getSystemInfo(‚?‘) this Message


     

   

 

 
value= "!" >
   
variable= "mySystemInfo" > var= "#mySystem#" label= "mySystem" expand= "false" >
 

 
value= "name" >
   
mySystemInfo = listFirst (mySystem.getHostName(), ‚/‘ ) >
 

 
value= "ip" >
   
mySystemInfo = listLast (mySystem.getHostAddress(), ‚/‘ ) >
 

 

   
mySystemInfo = mySystem.getLocalHost() >
 

 

 
 
mySystemInfo >

#getSystemInfo(‚!‘)# liefert dann zb. eine Liste aller zur Verfügung stehenden Funktionen:

mySystemInfo

Um serverunabhägig entwickeln zu können ist logischer Weise eine komplette Unabhängigkeit in der Programmierung notwendig.

Soweit für den einen oder anderen ja auch kein Problem, auch wenn die meisten Entwickler in der Regel von Dingen ausgehen die nicht immer so sind. Freelancer haben da Murphy schon oft getroffen und daher in der Regel wesentlich mehr Erfahrung.

Oft wird aber auch eine bedingte Abhängigkeit gefordert. Das heisst bestimmte Funktionen sollen nur dann ausgeführt werden, wenn sie sich auf einem bestimmten Server befinden, nur auf einem bestimmten Port laufen dürften oder einfach keine Funktionen im Netz aufrufen dürfen, weil sie gar nicht online sind. Beispiel: Auf einem Notebokk ohne Internetzugang bzw. aus Kostengründen und/oder Performancegründen nicht immer online gehen sollen.

Am besten legt man das dann in einer Config-Datei „server.xml“ fest, die einmalig bei jedem Start einer Application aufgerufen wird.

Datei: server.xml



      

      
            mySampleApp,c:WebSpacemySampleAppcfMapping>
            mySampleAppodbc>
            falseonline>
      server>

      
            mySampleApp,o:onlinemySampleAppcfMapping>
            mySampleAppodbc>
            trueonline>

      server>

 

Es wird daraufhin neue folgende Struktur im ServerScope erstellt, wobei der Elementbaum ab Server natürlich beliebig erweitert werden kann und dann auch automatisch im Server-Scope erweitert wird:
getMyConfig

Die notwendige Funktion „getMyConfig“ wird dann wie folgt aufgerufen:
component=“controller.system.functions“ method=“getMyConfig“ returnvariable=“myAppName“ configPath=“c:WebSpacemySampleAppconfigserver.xml“ serverScope=“apps“ serverName=“#myServerName#“>

und kann anschliessen wie folgt genutzt werden:
xxxx name=“#myAppName#“>

Natürlich macht diese Funktion nur Sinn wenn der Servername der Maschine auch automatisch ermittelt wird. Am einfachsten und am besten nimmt man meine SystemInfo()-Funktion, oder man aerbeitet mit IP-Addresse als Servername. Kann aber unter Umständen Probleme geben wenn die IP-Addressen die gleichen sind; auf verschienenen Notebooks, welche in der Regel andere Namen haben (sollten). Im gleichen Netzwerk warscheinlich nicht das Problem. Und „#cgi.SERVER_NAME#“ löst auch nicht immer das Problem.

Da die Daten ja im Server-Scope abgelegt werden, kann man darüber auch ermittlen welche Applikationen seit wann online sind.

Hier mal eine kleine Funktion die mir meine Objekte generiert. Um neue Objekte zu generieren, setze ich diese einfach komasepariert hintereinander ohne jedesmal eine Zeile per Copy&Paste hinzufügen zu müssen.

‚mySampleApp‘,’M‘,’gateway‘,’address‘ )>
‚mySampleApp‘,’M‘,’dao‘,’address‘ )>
‚mySampleApp‘,’M‘,’bean‘,’address‘ )>
‚mySampleApp‘,’C‘,’bo‘,’address‘ )>
‚mySampleApp‘,’C‘,’system‘,’function‘ )>


"createMyObjects" returntype= "void" access= "private" output= "false" displayname= "erstellt alle Objekte" hint= "die zu erstellenden Gateways können als CSV-List übergeben werden" >
    "datasource" type= "string" required= "true" >
    "objectMVC"   type= "string" required= "true" >
    "objectType" type= "string" required= "true" >
    "objectList"   type= "string" required= "true" >

    "model,view,controller" >
   

    "M" >
       
   

    "#arguments.objectList#" index= "myObject" >
        "#application.applicationname#. #listGetAt(MVC,listContainsNoCase(MVC,arguments.objectMVC))#. #arguments.objectType#. #myObject#" method= "init" argumentcollection="#initParams#" returnvariable= "application.#application.applicationname#. #arguments.objectType#. #myObject#" />
    p>

Um die geniale Quelltextformatierung im blogCFC zu nutzen, ist es notwendig in der Datei „/admin/entry.cfm“ folgendes zu suchen bzw. zu ersetzen.
nach [code] [code/] und und [more] [more/]

Damit die TAGS nicht immer wieder verschluckt werden, sollte man den Befehl "htmlEditFormat(" an folgenden Stellen entfernen, damit er anschliessend wie folgt ausschaut.

Neugierig auf Systeminfos?

system = createObject(„java“,„java.lang.System“);
var=„#system.properties#“>

oder

var=„#createObject(‚java‘,’java.lang.System‘).properties#“>

Um CSV-Daten nach ColdFusion zu bearbeiten geht am besten per Query-Objekt. Eine schöne Konvertierungslibrary DataTypeConvert.zip ist die vom Arthur.

Zuerst ist mal eine CSV-Datei, und die einzelnen Zellen sicherheitshalber mit einem Semikolon („;“) getrennt.

myAddress.csv
1,“r Herr“,“Reinhard“,“Jung“,72805,“Lichtenstein“,“Finkenweg 3″
2,“r Herr“,“Thorsten“,“Tatendrang“,61034,“Muenchen“,“Im Erdbeeracker 35″
3,“r Herr“,“Horst“,“Hahn“,33419,“Frankfurt“,“Am Teich 4″
4,“Frau“,“Forelle“,“Bach“,23443,“Frankfurt“,“Maushaus“

Danach einfach mit folgenden ColdFusion-Code die Datei aufrufen und man erhält eine ganz normale Query über die man dann wie gewohnt loopen kann etc.

getCSV.cfm
            columns=“ID,Anrede,Vorname,Nachname,PLZ,Ort,Strasse“
            delimiter=“;“ method=“get“>

Eine immer wiederkehrende Frage ist das scoping in CFCs. Hier eine kurz Erklärung für den Scope: „variables“ am Beispiel zur Nutzung des Datasource einer DAO.

myAddressCFC.cfc
name=„init“ returntype=„address“ output=„false“ access=„public“ displayname=„Initialisierung des Objectes“ hint=„stellt alle Parameter als instance-Variablen im ‚this.scope‘ zur Verfügung“>
 
name=„datasource“ type=„string“ required=„true“ default=„“>

 
variables.instance.datasource = arguments.datasource>

  this />

Diese Variable ist dann in der gesamten aktuellen CFC gültig und kann somit von jeder Funktion bzw. Methode aus genutzt werden.
Um diese Variablen als Eigenschaften oder Attribute einer CFC hervorzuheben nutze ich die gängige Praxis, dem Variablennamen eine weitere Ebene „instance“ hinzuzufügen.

Der Zugriff sollte allerdings prinzipiell über eine getter/setter-Methode erfolgen und nie direkt (eben nicht so wie in Beipiel 1. und 2.).
Bis auf die Ausnahme das sie evtl. in der ini()-Methode gesetzt werden, denn ich bin schreibfaul und möchte in diesem Fall einfach keine „setDatasource()“-Methode, sondern übergebe den Namen der Datasource einfach gleich der init()-Methode als Parameter mit:

Hinzu kommt das ALLE Variablen im variables-Scope als Parameter per cfArgument übergeben werden sollten, um die Unabhängigkeit einer CFC zu gewährleisten.