You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by "J. Wolfgang Kaltz" <jw...@apache.org> on 2005/05/24 10:35:35 UTC
[trunk] saving in bxe
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] saving in bxe
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> J. Wolfgang Kaltz wrote:
> (...)
> AFAIK BXE doesn't allow to change the BX_xmlfile parameter after each
> "save" action, which would be necessary to pass the continuation ID
> from request to request.
>
> A workaround could be to add the continuation ID to the session.
+1,
I don't think that would be a workaround, but a feature (see below)
>
> Another option is to write the XML to a temporary source and copy this
> temp source to the original source when the user exits BXE.
If we would do it like that, would that mean that a editing in Lenya is
a 3-step process instead of a 2-step process ? I guess that would be ok
and generalizable to all editors
>
>> 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).
>
>
> I started some docs, feel free to add your questions / comments:
>
> http://wiki.apache.org/lenya/OverviewRepository
Yes, thx a lot, it is an important theme to document.
> (...)
>> - (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,
>
>
> It is possible without a unit of work ... what do you mean?
OK, maybe I simply misunderstood ... I need to delve into document
access again (that was the starting point in the internals of my long
round trip to resource type to metadata to creator).
Regarding editor & continuations,
I am +1 to store the continuation IDs in the session instead of in
request parameters. This is IMO the only way we will able to provide a
generic edit interface.
I see in cocoon.xconf there is a <continuations-manager> entry, with a
parameter session-bound-continuations="false"
Reading the Cocoon docs
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/flow/ContinuationsManagerImpl.html
this should be set to "true" for Web apps in any case (for security
reasons).
IIUC the only pb with setting this to true is that all accesses to Lenya
continuations would then require to live inside a session. I guess for
current needs this is in fact what we want (i.e. a feature, not a bug).
WDYT ?
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] saving in bxe
Posted by Christian Stocker <ch...@bitflux.ch>.
On 24.5.2005 22:40 Uhr, Andreas Hartmann wrote:
> Gregor J. Rothfuss wrote:
>
>> Andreas Hartmann wrote:
>>
>>>> from what i understand, that is a global setting. might be good to
>>>> change that to sessions in general. what i don't like about
>>>> continuation id's in the request is that people bookmark a page and
>>>> then always get invalid continuation ids..
>>>
>>>
>>>
>>> Sounds reasonable. Do you have experiences with adding the continuation
>>> ID to the session?
>>
>>
>>
>> i don't. it would be best to ask on the cocoon lists if anyone is
>> doing this.
>
>
> Google revealed this:
>
> "There are two options for sending the continuation id to the user's
> browser: It can be embedded as a hidden field in the form that is sent
> back, or it can be embedded in the URL to which the form will be posted.
> Needless to say, encapsulating continuation ids within cookies is a bad
> idea, because a specific cookie is common to all cloned instances of a
> browser window on a machine whereas a continuation is specific to a
> particular instance of the browser window only."
>
> http://www-106.ibm.com/developerworks/library/j-contin.html
>
> It looks like the request is the way to go when it comes to continuations.
> Maybe BXE can be extended accordingly?
How do you give the new continuation id back to BXE? (or any other
editor, for that matter). I think, it would possible without too much
hassle to be implemented in BXE, but lenya would need its own
TransportDriver, AFAICS (which is not a big task per se, just additional
maintenance work). Kupu will have the same problem. An unified approach
there (how such things as "we now have a new Save URL" should be
handled, resp. communicated) would maybe help all of us ;)
chregu
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] saving in bxe
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>>> from what i understand, that is a global setting. might be good to
>>> change that to sessions in general. what i don't like about
>>> continuation id's in the request is that people bookmark a page and
>>> then always get invalid continuation ids..
>>
>>
>> Sounds reasonable. Do you have experiences with adding the continuation
>> ID to the session?
>
>
> i don't. it would be best to ask on the cocoon lists if anyone is doing
> this.
Google revealed this:
"There are two options for sending the continuation id to the user's browser: It
can be embedded as a hidden field in the form that is sent back, or it can be
embedded in the URL to which the form will be posted. Needless to say,
encapsulating continuation ids within cookies is a bad idea, because a specific
cookie is common to all cloned instances of a browser window on a machine
whereas a continuation is specific to a particular instance of the browser
window only."
http://www-106.ibm.com/developerworks/library/j-contin.html
It looks like the request is the way to go when it comes to continuations.
Maybe BXE can be extended accordingly?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] saving in bxe
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
>> from what i understand, that is a global setting. might be good to
>> change that to sessions in general. what i don't like about
>> continuation id's in the request is that people bookmark a page and
>> then always get invalid continuation ids..
>
> Sounds reasonable. Do you have experiences with adding the continuation
> ID to the session?
i don't. it would be best to ask on the cocoon lists if anyone is doing
this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] saving in bxe
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>> The problem is quite complex, and I didn't yet find a solution.
>
>
>> AFAIK BXE doesn't allow to change the BX_xmlfile parameter after each
>> "save" action, which would be necessary to pass the continuation ID
>> from request to request.
>>
>> A workaround could be to add the continuation ID to the session.
>
>
> from what i understand, that is a global setting. might be good to
> change that to sessions in general. what i don't like about continuation
> id's in the request is that people bookmark a page and then always get
> invalid continuation ids..
Sounds reasonable. Do you have experiences with adding the continuation
ID to the session?
>
>> Another option is to write the XML to a temporary source and copy this
>> temp source to the original source when the user exits BXE.
>
>
> we had that with the other editors, and it adds more complexity.. im not
> a big fan.
I just checked it in like this, at least it works. It allowed to use
the usecase FW for BXE (no custom flowscript is used), so generally
it is quite simple. I didn't yet remove the old files, maybe we find
a better solution.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] saving in bxe
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> The problem is quite complex, and I didn't yet find a solution.
> AFAIK BXE doesn't allow to change the BX_xmlfile parameter after each
> "save" action, which would be necessary to pass the continuation ID
> from request to request.
>
> A workaround could be to add the continuation ID to the session.
from what i understand, that is a global setting. might be good to
change that to sessions in general. what i don't like about continuation
id's in the request is that people bookmark a page and then always get
invalid continuation ids..
> Another option is to write the XML to a temporary source and copy this
> temp source to the original source when the user exits BXE.
we had that with the other editors, and it adds more complexity.. im not
a big fan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] saving in bxe
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> 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 ?
The problem is quite complex, and I didn't yet find a solution.
In 1.4, you can write to a source only inside a transaction, which requires
a UnitOfWork object. The usecase framework manages this by attaching the
UnitOfWork to the request, so that it is available to the LenyaSourceFactory.
Basically, passing the transaction from request to request is done through the
continuation ID.
AFAIK BXE doesn't allow to change the BX_xmlfile parameter after each
"save" action, which would be necessary to pass the continuation ID
from request to request.
A workaround could be to add the continuation ID to the session.
Another option is to write the XML to a temporary source and copy this
temp source to the original source when the user exits BXE.
> 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).
I started some docs, feel free to add your questions / comments:
http://wiki.apache.org/lenya/OverviewRepository
> IIUC
> - object lock is there to prevent 2 users working at the same time
> changing the same object
Yes, and to prevent an object from changing its state between several read
operations in a transaction.
> - 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 ?
Lock is used to notice changes, checkout is used to avoid changes.
> - (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,
It is possible without a unit of work ... what do you mean?
> 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?
I don't really understand this, could you give an example?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org