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]

Reply via email to