Hi all,
I'm trying to understand why saving in bxe does not work. IIUC it has to
do with the locking of the nodes which isn't working, but I don't
understand why:
1. when the editor is started, the nodes aren't locked as far as I can tell
2. when save is called in the editor :
2.1 edit-document.js::editDocument() is called (see usecase-bxe.xmap)
2.2 this calls AbstractUsecase's lockInvolvedObjects()
2.3 this tries to lock the nodes of the document, the URI seems
correct to me. But the nodes are already checked out, so this is an
error. The error is added to the usecase's error message; this currently
has no effect as error handling in edit-document still needs to be
implemented
2.4 the usecase's execute() is called, it fails with an exception
saying the node to be written to is not locked. The URI is the same as above
I understand that the editor handling in currently a mixture of old
usecase framework and new usecase framework, because of problems getting
it to work in the new framework. What I don't understand is:
- why, when reaching 2.3, the nodes are already checked out, and who
checked them out
- why 2.4 fails. The nodes are not locked, but if they have been checked
out before 2.3, should they not also have been locked ?
To be honest, I don't really understand the new locking / checking out
mechanisms on the objects (talking about objects as in instances of
classes, not talking about the rc checkout here).
IIUC
- object lock is there to prevent 2 users working at the same time
changing the same object
- object lock is implemented via the UnitOfWork; the UnitOfWork is used
both for accessing documents and for changing them, so some custom
mechanism is required to avoid 2 people changing an object at the same
time.
What I don't understand is
- What is the difference between lock and checkout ? And why does it
cause a problem in the edit usecase ?
- (design question): would it not be easier to explicitly separate read
and potential write accesses ? i.e. reading could be possible without a
unit of work, but to write one needs to retrieve a unit of work. If this
were so, it should be sufficient to mark all the unit of work's methods
as synchronized, as thus avoid the custom implementation of object locking?
Thx for any clarification
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]