Jag tänkte översätta en webbapplikation så att man vid inlogging kan välja språk. Det är en väldigt stor applikation som ska översättas så det blir extremt många ord och meningar.
Min tanke först var att inkludera en fil med asp variabler på språket. Liknande denna:
På sidorna sedan skriver man variablerna istället för ordet/meningen.
Men denna inkluderingsfil kan ju bli enorm och leda till att alla sidor blir extremt sega.
Min andra tanke var att bygga en XML-fil som man lägger språket i. Nu har jag väldigt dålig koll på XML men hur skulle det fungera? Skulle det vara en bättre lösning? Hur visar jag ett ord ur XML-filen på sidan?
Själv så skulle jag nog bygga det på en databas eller en XML-fil så att jag lite lättare kan bygga ett gränssnitt för att uppdatera, skapa och ta bort texter.
Kör en XML-fil eller databas som laddas in när i Application_Onload eller vad det heter, och som sedan ligger kvar i minnet och skräpar så att du kommer åt den från applicationobjektet. Visst blir det en liten minnesoverhead, men det borde inte vara så farligt om du inte hade tänkt ha textmassor i stil med samtliga band av Nationalencyklopedin. Fördelen är att servern slipper jobba särskilt mycket.
Spango: Lust och utveckla lite med nått exempel?
Framför allt hur jag laddar in texterna i minnet med application_onload och sedan skriver ut en text på webbplatsen.
Om jag laddar in det i applikation kan väl inte olika användare ha olika språk? Eller har jag fel?
Visst blir det en liten minnesoverhead, men det borde inte vara så farligt om du inte hade tänkt ha textmassor i stil med samtliga band av Nationalencyklopedin.
Addeladde skrev:
Det är en väldigt stor applikation som ska översättas så det blir extremt många ord och meningar.
Personligen tycker jag det verkar konstigt att proppa hela application full med text, när man kan lösa det genom att skapa språktabeller i databasen och identifiera sidorna var och en för sig med något slags ID, som man sedan refererar till i databasen när man skall hämta ut en sidas alla textsträngar. Låt varje sidan göra lite jobb istället, det dör ingen server av, speciellt inte i de små mängderna som pagescope handlar om.
Man kan skapa dictionarys så att man får vettiga namn på sina strängcontainrar också, så att koden blir någorlunda läsbar också.
lPageId = 123456
Set dic = GetPageText(session("LanguageId"), lPageId)
GetPageText
Function GetPageText(ByVal lLangId, ByVal lPageId)
'öppna connection & deklarera dic
Set rs = conn.execute("SELECT TextName, TextValue FROM tblText WHERE TextLanguageId = " & lLangId & " AND TextPageId = " & PageId)
while not rs.eof
dic(rs("TextName")) = rs("TextValue")
rs.movenext
wend
set rs = nothing
set GetPageText = dic
set dic = nothing
End Function
OveRRidE, Har du lust och ge något litet exempel på hur det skulle kunna se ut?
Om man kör på databas blir det ju krångligare att lägga till ett nytt språk. Kör man på en XML-fil skulle det ju i praktiken bara vara att kasta in en ny fil i en katalog för att det nya språket ska bli valbart.
Vilken av de två datalagrena du använder är i praktiken irrelevant, om du skriver koden rätt. Det går att hantera XML ungefär på samma sätt som en databas idag, även om det inte är att rekommendera som ersättare.
I detta fall kan det mycket väl lösa sig genom att ha XML-filer med språken i. Det är ju egentligen samma förfarande, även om mitt exempel utgick från en databas.
Du har ju exemplet ovan? Men iallafall, nåt sånt här kanske? (fullständigt otestat ur skallen)
<%
Dim lPageId, dic
lPageId = 143
Function GetPageText(ByVal lLangId, ByVal lPageId)
'öppna connection
Dim dic, rs
set dic = server.createobject("scripting.dictionary")
dic.comparemode = 1
Set rs = conn.execute("SELECT TextName, TextValue FROM tblText WHERE TextLanguageId = " & lLangId & " AND TextPageId = " & PageId)
while not rs.eof
dic(rs("TextName")) = rs("TextValue")
rs.movenext
wend
set rs = nothing
set GetPageText = dic
set dic = nothing
End Function
Set dic = GetPageText(session("LanguageId"), lPageId)
%>
<html>
<head><title><% =dic("htmltitle")</title>
</head>
<body>
<!-- massa html -->
Detta är ett översatt ord; <% =dic("word") %>.
<!-- mer html -->
</body>
</html>
<%
set dic = Nothing
%>
Japp såg inte ditt exempel först.
Vad tror ni om att separera språkdatabasen från den riktiga databasen som applikationen använder sig av?
Man kan t.ex köra applikationen på SQL-Server och access. Kör man på access kan det ju bli segt för användarna som tittar på webbsidan som aplikationen skapar (publiceringsverktyg).
Japp såg inte ditt exempel först.
Vad tror ni om att separera språkdatabasen från den riktiga databasen som applikationen använder sig av?
Man kan t.ex köra applikationen på SQL-Server och access. Kör man på access kan det ju bli segt för användarna som tittar på webbsidan som aplikationen skapar (publiceringsverktyg).
Eller vad säger ni?
Som sagts så många gånger innan, så tjänar du ingenting på att separera applikationen i flera databaser, nej.
Då måste du helt plöstligt ha två connections igång mot varsin databas och då fördubblar du antalet anslutningar, vilket inte är något man helst vill göra. Dessutom; du kan inte använda JOINs mellan tabellerna ifall de ligger i olika databaser heller.
Man skall helt enkelt göra som @nders hade sagt; Ge helsike i det. ;)
Fast tjännar man inte antal connections mot de båda databaserna? En Join kommer jag ju knappast att behöva göra. Tanken från början var ju t.o.m att använda mig av en språkfil och då skulle det ju heller gå att göra en join.
Fast tjännar man inte antal connections mot de båda databaserna?
Vad menar du?
Om du använder databaser finns det som sagt ingen bra anledning att separera på det sättet. Det går inte att motivera det med att 'man inte kommer göra några JOINs'. Du vet ju inte hur applikationen ser ut i framtiden. Dessutom, om du vill bygga något slags gränssnitt mot språktabellerna för att främja uppdatering, är det ju bra ifall den är i samma databas som applikationens andra delar.
Om du använder XML är det ju ett måste, precis som det är med en 'språkfil', eftersom det är separata filer.
Alltså om man använder access som databas så klarar ju det 10 samtidiga anslutningar.
Om man har mindre anslutningar mot applikationsdatabasen så minimerar man ju antal connections mot den vilket gör att själva webbplatsen som besökarna tittar på inte får lika många connections.
Översättningen ska endast vara på själva applikationen och inte det man skapar med applikationen.
Access har ingen gräns på 10 samtidiga anslutningar, du blandar ihop det med gränsen som finns i Windows 2000 Professional. Läs mer här.
Vad har 'applikationsdatabasen' för DBMS? Access, MSSQL? Det jag pratar om handlar inte om hur många connections det görs mot varje databas, utan hur många connections det görs totalt på servern. Om jag inte missförstår så hämtar de sidor som som vill språksätta data från både applikationsdatabasen och de tilltänkta språktabellerna (om vi nu ponerar det scenariot)? Isåfall kommer du få starta två separata connection-objekt för varje sida, istället för en. Det är alltså inte optimalt. Dessutom körs väl båda delarna i samma sajt under IIS:en, vilket resulterar i att allt körs i samma processutrymme ändå (beroende lite på vad du har för säkerhetsinställningar på din IIS). Vidare, om du nu vill separera varje del i en egen applikation (!?) så tror jag knappast att du tjänar in på connectionhantering i respektive pool jämtemot vad varje dllhost sliter i minne på servern ändå, då en 'isolated site' får en egen instans där alla exekveringar hanteras frånskilt från resterande delar av IIS:en.
Jag förstår inte varför du envisas med att vilja dela på dem överhuvudtaget? Du tjänar inte något på att dela upp det på det sättet, såvida du inte kör Access rakt igenom (då du kanske kan minska exekveringsköerna mot de enskilda datafilerna), vilket jag starkt betvivlar eftersom du nämner att applikationen är extremt stor.
Idag är det bara en databas för publiceringsverktyget (applikationen) och man kan vid installation välja om man vill köra på en MS SQL server eller en access databas.
Anledningen till att jag tycker att access klarar lite är att jag byggt en medlemsmatrikel till ett nätverk på ca 200 aktiva medlemmar. När ett nyhetsbrev går ut till medlemmarna och många användare går in samtidigt kan det ibland dyka upp ett felmeddelande om att databasen är överbelastad. Det brukar oftast bara vara uppdatera sidan så visas informationen. Men det är ju irriterande...
Access har väl en gräns på att om man i ett nätverk sitter och jobbar i samma accessfil så kan endast 10 st ha filen öppen samtidigt?
Idag är det bara en databas för publiceringsverktyget (applikationen) och man kan vid installation välja om man vill köra på en MS SQL server eller en access databas.
Anledningen till att jag tycker att access klarar lite är att jag byggt en medlemsmatrikel till ett nätverk på ca 200 aktiva medlemmar. När ett nyhetsbrev går ut till medlemmarna och många användare går in samtidigt kan det ibland dyka upp ett felmeddelande om att databasen är överbelastad. Det brukar oftast bara vara uppdatera sidan så visas informationen. Men det är ju irriterande...
Ok. Då kan vi iallafall utesluta att separeringen av databasen skall ske pga. att du vill minska köerna mot Access-databasen eftersom den ibland använder MSSQL. Då ser jag inte längre någon anledning att motivera delningen.
Addeladde skrev:
Access har väl en gräns på att om man i ett nätverk sitter och jobbar i samma accessfil så kan endast 10 st ha filen öppen samtidigt?
Va? Bara för att du är inloggad i din applikation så betyder ju inte det att varje användare har en öppen connection mot databasen hela tiden, såvida du inte byggt din applikation så. Och isåfall har du gjort ett väldigt stort grundläggande fel.
Om användarna ansluter ifrån ditt nätverk eller inte är fullständigt irrelevant, eftersom alla (utifrån som innifrån) ändå kör genom samma portar.
Det som kan ställa till problem i en Access-fil (som det uttryckligen stod i tråden som jag länkade till ovan) är när flera anslutningar begär data från databasen samtidigt, då de kommer köas, eftersom Access inte klarar att hantera mer än en förfrågning i taget. För att komma upp i denna kö's maxgräns får du ha en rent utsagt vansinnig trafik (ca 200-300 förfrågningar mot db per sekund, enligt de siffror PatrikB angav). En webbapplikation tillämpar ofta Pagescope-livslängd och Öppna-Göra-Stänga-mentalitet, vilket innebär att varje connection aldrig lever (eller iallafall inte befinner sig utanför serverns pool) längre än vad som är absolut nödvändigt.
Va? Bara för att du är inloggad i din applikation så betyder ju inte det att varje användare har en öppen connection mot databasen hela tiden, såvida du inte byggt din applikation så. Och isåfall har du gjort ett väldigt stort grundläggande fel.
Nä då! Du behöver inte vara orolig
OveRRidE skrev:
En webbapplikation tillämpar ofta Pagescope-livslängd och Öppna-Göra-Stänga-mentalitet, vilket innebär att varje connection aldrig lever (eller iallafall inte befinner sig utanför serverns pool) längre än vad som är absolut nödvändigt.
Skönt att nån kan babla teknik tjossan... Svenska tack!
En webbapplikation tillämpar ofta Pagescope-livslängd och Öppna-Göra-Stänga-mentalitet, vilket innebär att varje connection aldrig lever (eller iallafall inte befinner sig utanför serverns pool) längre än vad som är absolut nödvändigt.
Skönt att nån kan babla teknik tjossan... Svenska tack!
Okej, sorry.
HTTP-protokollet är ett sk. 'Stateless protocol', alltså ett statlöst protokoll. Det kan jämföras med att klienten inte vet vad servern pysslar med och vice versa, förutom den lilla tid de har kontakt. Efter att klienten har begärt, servern har processat och skickat och klienten har mottagit så stängs anslutningen och de båda har helt plötsligt glömt bort varandra. En webbapplikation fungerar under reglerna för HTTP, vilket innebär att klienten frågar servern efter en sida, servern svarar (förhoppningsvis) och gör redo den HTML och data som klienten vill ha och skickar tillbaks den, klienten tar emot HTMLen/datan och processar den. Detta är Pagescope, ungefär. Objekt, variabler och serverns temporärminne lever bara så länge som det krävs för att slutföra uppgiften. Det man strävar efter är att få tidsspannet mellan klientens förfrågan till serverns svar i data så liten som möjligt, därav uttrycket 'In-Processa-Ut' (eller vad du vill).
När servern är klar med kopplingen mot databasen så förstörs referensen (eller pekaren?) mellan klient och server, objektet avaktiveras (heter det så) och returneras till serverns Connection-pool, där det väntar på att få återaktiveras igen, om det i nästa fall blir mot samma datakälla. Ungefär så fungerar det, om jag inte minns fel.
RED. Det känns som vi hamnar lite offtopic här, som vanligt när jag deltar i trådar. :OO
