Hi all,
very interesting discussion and I see that this issues raises more
possibilities and questions than I expected.
I agree that the final checkin state of a node (or a set of nodes) is
something that is application specific and therefore it should be
possible for a bundle developer to decide what the final state should
be. To be honest I started with a special flag as part of the content
definition (didn't know jcr:isCheckedOut before), but as said in my
first mail I was not satisfied with that solution because it was
something that was not part of the content but rather a piece of meta
information defining how to handle the content import.
But with jcr:isCheckedOut property this should be solvable in a way
that prevents such a mix. I also like the idea of a global flag as
part of the bundle, because this would allow to control the behaviour
at one point, which is useful for big content definition files.
I will try to extend my patch with a global flag and to respect
jcr:isCheckedOut. After that I will add an according JIRA issue so
that Sling experts can have a look at it.
Regards,
Alex
Am 04.04.2008 um 21:18 schrieb Felix Meschberger:
Hi,
Am Freitag, den 04.04.2008, 12:11 -0700 schrieb Tobias Bocanegra:
so, why don't you introduce some kind of flag that will specify
the
required behaviour: checkin or not?
Same time - same thinking ;-)
well, there is already such a flag: the "jcr:isCheckedOut'
property.
so if the content has a 'jcr:isCheckedOut == true', then it
should be
checked it, otherwise not of course.
This property is protected and managed by the repository. Thus it
can
probably not be set by the loader.
no, it can't. but if the property is present it reveals something
about the versioning state.
so the loader should do a 'checkin' if "jcr:isCheckedOut==false".
In addition, I think, the requirement to have nodes checked-in or
not by
default is a global decision and not a node-by-node decision.
Therefore
the "global" flag as proposed by me is probably better.
maybe. but maybe not for the entire content?
i would really respect the checked-out state of the content (as we
honor jcr:primaryType, jcr:mixinTypes. i would even try to fix the
jcr:uuid property, if it would be possible by normal means).
at least the jcr:isCheckedOut should be honored if the 'global
checkin
flag' is missing.
At first I was against this special case handling ... but thinking
again, it might be worth it and in fact having the global flag is just
another case of special casing.
At Alex: Could you file a JIRA for this and probably attach your
current
patch ? Thanks
Regards
Felix
--
regards,
toby
while working with Sing I noticed that nodes declaring mixin
node type
mix:versionable are not checked in when the initial content
is loaded.
This is somehow unexpected to me and can lead to some trouble
if you rely
on versioning. I propose to change this so that versionable
nodes will be
checked in when initial content is loaded. First I started
thinking about an
additional property in the content definition, but this is
maybe a bit ugly
as it results in content definitions that mix real content
with information
how to handle it.
Thus I changed the Loader implementation. it now checks in
all versionable
nodes at the end of the content loading process. For that you
need to add
mix:versionable explicitly in the content definition file. It
is not enough
to declare a primary node type that defines mix:versionable,
which in my
implementation leads to the same results as before.
If the team agrees with the proposed changes, I will add an
according JIRA
issue and patch.
i'm not sure if this is correct. is your requirement that the
initial
content already has a version or that the nodes are checked-in ?
i think it really depends on the application that needs the
content if
it should be checked in or not.
--
toby
