Once we have that Article object, we check to see whether it??™s already
locked. If it isn??™t, or if it??™s locked by the user currently requesting the lock, it can be locked.
To do so, we set the lockedBy field to the name of the user making the request, using
HttpServletRequest??™s getUserPrincipal().getName() method (the request object is again a
method parameter autopopulated by DWR). Then it??™s just a call to updateArticle(), this time
with the inWriteHistory flag set to false, for the reasons described previously.
Now, let??™s follow the case of the article already being locked. Two things can happen here.
First, what if the lock hasn??™t yet expired? That??™s the easy case (it??™s the else branch of the if): all
we need to do is return a string in the form lockedBy=xxx=yyy, where xxx is the name of the
user who has the article locked and yyy is the amount of time remaining on the lock. The UI
will recognize this string and pop an alert() message to the user telling that user he or she
can??™t have the edit lock.
If the lock has expired though, that means the new user can have the lock on the article
(and as we??™ve seen previously, it means the user that currently has the lock won??™t be able to
save his or her changes .
Pages:
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461