Kolla så endast en person jobbar med samma post

Ligger 'dokumenten' som data i databasen eller som filer på hårddisken? Vilken typ av dokument är det?

Det ligger som data i databasen

Jag står inför ett liknande problem...

Jag tänkte lösa det genom att lagra doc_id och user_id
tillsammans med now() i applicationvariabel.

Låset gäller exempelvis i 20 min från senaste uppdatering och
man kan få en alert-box som säger "Dokumentet redigeras just
nu av Sven Svensson, återkom senare" genom user_id:t

Åsikter ?

mvh Macce

Det beror väl på hur dokumentet redigeras?

Om du nu streamar ut ett worddokument till klienten, så ser jag inte riktigt hur man sparar tillbaks alltihopa utan att aktivera en filuppladdning från klienten?

Hur fungerar egentligen visningen av dokumentet idag, Adde?

Sant...

I databasen så är det htmlkod sparat för ett html dokument. I posten finns också information om mall, publicering, datum m.m.
När man sparar sedan så skapas en statiskt fil med innehållet i databasen.

Men den statiska filen har inget med spärren att göra. Spärren ska endast ligga på posten i databsen så att inte fler kan jobba med den.

Att ha en pinne i databasen som säger att den är utcheckad är nog den bästa lösningen. Sedan så kan du kanske göra en merge funktion som känner av skillnaden mellan dokumenten. Men då är det du ju helt plötsligt beroende på att du skal kunna läsa olika fil format vilket gör att allt helt plötsligt blir mer komplicerat.

Du menar att du har en HTML-fil (i fysiskt format) någonstans på servern, som sedan fylls med HTML-data (eller liknande) från databasen? Eller gestaltas filen helt och hållet ur databasen?

Filen gestaltas helt o hållet ur databasen. Eller innehållet i posten sätts samman med en mall som ligger i en annan tabell o post när man sparar och blir en fil.

Det är endast html filer inga andra filformat. Men det är endast sidposten jag vill låsa redigering på inte på mall eller statisk fil.

Då är det precis samma sak som jag ska lösa, gillas inte ideen med applicationvariabeln ?

(Gillar inte att prata med databasen i onödan)

/Macce

Ja, det är ju det som är nackdelen med 'stateless applications', du kan aldrig riktigt ha koll på vad klienten sysslar med eller att denna ens gör de åtaganden som den har tagit åt sig.

Du får väl på något sätt se till att skapa två lägen, 1) Öppna för läsning och 2) Öppna för redigering. Redigering låser filen (flagga ett bitvärde till 1) och när den sparas sätter du tillbaks den. Problemet är ju då, som sagt, ifall besökaren bestämmer sig för att stänga fönstret eller kanske bara trycka på tillbaka-knappen, att flaggan blir i limbo, så att säga. Ingen annan kan redigera.

Möjligt att man kan trolla lite med onUnload eller liknande metoder i JavaScript för att kontrollera ifall något visst formulärvärde, som motsvarar dokumentets nuvarande låsning, är satt, men det låter lite riskabelt. Det är väl en utbildningsfråga också.

Macce skrev:

Då är det precis samma sak som jag ska lösa, gillas inte ideen med applicationvariabeln ?

(Gillar inte att prata med databasen i onödan)

Men det löser fortfarande inte huruvida man måste tvinga användaren att släppa låset. Att ta reda på vem som gör vad är en baggis, däremot se till att alla verkligen gör som de ska, det är en annan sak. ;)

Tiden går ut, i värsta fall så låses sidan i högst 20 min...

Då när någon bara stänger sin webbläsare i redigeringsläge...

Och om det tar längre tid än 20 minuter för användaren att redigera dokumentet? Det inträffar väl visserligen inte så ofta, men det är värt att ta med i beräkningen ändå.

Förläng tiden, sessionen brukar ju ändå som default ta slut vid 20 min...

Det kanske inte gäller för din applikation i o f s.

Använder detta lilla script på sidan man redigerar för att man inte ska räka gå bakåt och mista sina ändringar.

   var bekrafta = true;
   var sparaSida = false;

	function lamnaSidan() {
	  if (sparaSida != true){
		if (bekrafta) {
		 window.event.returnValue= "Om du lämnar sidan utan att spara kommer alla ändringar att gå förlorade." 
         window.event.cancelBubble=true;

		}
		else {
			return false;
		}
	  }
	}

Det löser problemen med bakåt, gå till annan sida, stänga webbläsaren. Men det löser inte problemet med om webbläsaren hänger sig eller om datorn plötsligt stängs av. Då får man väl ha en timer på 20 min. Eller vad tror ni?

Macce » Jag förstår din tanke, men det statuerar något slags uppvägningsproblem istället.

Man vill inte ha låstider som varar för länge för man vill inte sitta och vänta i timmar på att lås skall släppa bara för att en user är ett klantarsle och inte frigör det.

Man vill inte heller ha för korta låstider, eftersom users med sirap i tangentbordet antagligen blir lidande då.

Man vill ha exakt kontroll när användaren öppnar respektive stänger filen, vilket som sagt är ganska svårt över HTTP. Jag satt och spånade på någon slags i-frame-lösning som ligger och kontrollerar ett antal sessioner med 30 sekunders intervall, som i samverkan med lite javascript borde kunna förhindra kvarglömda lås.

Adde » Typ så ja. Fast en redirect i javascriptet till nån aspsida som släpper låset också. :)

Det skriptet "lånar" jag gärna...

/Macce

OveRRidE, med remote-scripting så man slipper blåa stapeln blinka hela tiden...

Sub Session_OnEnd, annars ?