On 12.4.12 13:13, Angela Schreiber wrote:
well, i still don't see how/where you plan to implement
the notion of transient modification.
in other words to make it clear (in case it isn't):
how do i change protected items in oak-jcr such that the items
are marked modified and the session has pending transient changes?
and such that i don't have to use the JCR API methods, which in
this case from my understanding are 'invalid'?
so, how do we make sure that
Session#hasPendingChanges
Item#isNew
Item#isModified
never return true in case the workspace operation fails on the oak
api for constraint or access violation and on the other hand
assert that all kind of transient modifications really trigger
the flags to be set?
i couldn't follow you here since those methods are not implemented.
That's because this is not read yet. There is no specific plan. We need
to come up with a way to implement this. That's all.
let's first define how to distinguish transient modifications.
i think that is the special case here from a oak-api perspective.
Ack.
I think the next steps should be:
1. Validate my claim from above re. workspace operations
what was your claim? can't follow you here.
That workspace ops can be implemented using my changes from rev.
1325159. This is done by now. See OAK-63.
2. Come up with a way to do "special modifications" following the
general direction sketched by NodeStateEditor et. all. This might
require adding higher level abstractions to the oak API and/or oak-jcr
and might also require changes/tweaks to the current state of affairs.
well, your approach of having a separate editor for workspace
operations already goes into the direction of separating
different change-sets. that was one thing i was wondering about.
Currently I use one editor for the session which represents all
transient changes done through JCR. For modifications which need to be
dispatched immediately one can obtain a separate editor from the
connection. Much like I do for Workspace.copy and Workspace.move.
IMO we we can basically use the same behavior for registering a
node type and an namespace or a privilege under /jcr:system/something...
(the latter was actually what brought up my
questions). oak-core was in any case in charge of validating the
changes individually and detecting the distinction between
a change to the node type registry or just a workspace. so,
maybe we can use the same mechanism.
Yes I think that should work.
AFAICT the remaining questions are all about handling of "special items"
taking into account modification state of items and session, visibility
and editability of such items, dispatching (i.e. on session save or
immediate) of such items, ...
Michael
what do you think?
angela
3. In the process come up with better names.
Michael
kind regards
angela
Michael
kind regards
angela
