Die Datengr�sse der  Includeseiten liegt bei ca. 5- 8 k max.
Das ist in der Performance der Seite beim Aufbau nicht zu merken.

Der Vorteil dieser Variante ist der gewesen, dass ich �nderungen an der en.inc sofort 
im System habe, ohnen die App jedesmal neu zu schreiben.

Sicherlich ist die App schneller, wenn erstmal gecached, aber wie gesagt es gibt auch 
andere M�glichkleiten die man machen kann.

Vom Handling her ist die FSO Geschichte recht nett.

MfG
J. Schwalenberg
______________________
www.udex.de
www.ultradevextensions.de
[EMAIL PROTECTED]
______________________
Think big - UDEX Software !
Software & Extensions for Dreamweaver Ultradev & MX
----- Original Message ----- 
From: "Claudius Ceteras" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 21, 2003 2:38 PM
Subject: RE: [Coffeehouse] Mehrsprachige Webseite


> 
> 
> > Also ich habe das nicht verfolgt, aber es gibt auch noch 
> > andere Ans�tze.
> > Ich weis auch nicht, ob das mit der Applicationsvar. so das 
> > tolle ist, zumal die Performance mit Sicherheit den Bach runter geht.
> > 
> > Ich habe das vor kurzem mal so gel�st:
> > 
> [...]
> 
> Wie jetzt? Du meinst jedes mal Dateien von der Platte per FSO lesen ist
> performanter als aus dem Speicher? N� du... ;-)
> Zus�tzlich ist die Application-Collection als Hashtable implementiert,
> d.h. die Eintr�ge m�ssen nicht langwierig gesucht werden, sondern k�nnen
> sehr schnell zugegriffen werden.
> Hashtables werden prinzipbedingt theoretisch nicht langsamer bei
> steigender Datenanzahl
> Und bei ein paar hundert oder tausend Eintr�gen sowieso nicht...
> Also... Wenn man den Speicher hat, dann verhilft Dir dieses Caching zu
> einer schnelleren Web-App...
> 
> Dieses Schema kann man aber nat�rlich noch ver�ndern...
> Z.B. nur ein Application-Variablen-Eintrag pro Text und zwar ein Array,
> das die einzelnen Texte der verschiedenen Sprachen enth�lt...
> 
> Hat man wenig Speicher, m�chte aber trotzdem cachen, kann man sich
> kompliziertere Systeme ausdenken, z.B. ein System, dass 1000 Texte
> speichert und beim 1001sten einen anderen rauswirft... Z.B. den am
> wenigsten benutzten oder den �ltesten(am l�ngsten nicht benutzten)
> Solche Systeme brauchen aber komplexere Algorithmen und die w�rde ich
> wenn �berhaupt am liebsten als COM-Komponente implementieren oder in
> ASP.NET, aber ASP sollte im Notfall auch gehen...
> Falls Du sowas vorhast, schreib auf jeden Fall nochmal in die Liste dein
> Design, denn da kann man viel Performance verlieren, wenn man es nicht
> richtig macht...
> 
> 
> Gruss,
> 
> Claudius
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~sponsored by United Planet~~~~~~~~~~~~~~~~~
> Kaffeepause im United Planet Communityserver ...
> http://www.intrexx.com/communityserver                         
> _______________________________________________
> Coffeehouse mailing list
> [EMAIL PROTECTED]
> http://www.glengamoi.com/mailman/listinfo/coffeehouse
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~sponsored by United Planet~~~~~~~~~~~~~~~~~
Kaffeepause im United Planet Communityserver ...
http://www.intrexx.com/communityserver                         
_______________________________________________
Coffeehouse mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/coffeehouse

Antwort per Email an