Hi,
Am 07.04.2008 um 10:43 schrieb Felix Meschberger:
Hi,
Am Samstag, den 05.04.2008, 18:49 +0200 schrieb Alexander Saar:
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.
Well not completely because it requires special casing for the
property
no matter the name because jcr:isCheckedOut is protected.
Of course it is not possible to set jcr:isCheckedOut. The current
implementation attached to SLING-365 does not set protected properties
directly on the node, they are just ignored. But if you specify
jcr:isCheckedout=false the node will be checked in and this results in
a content tree that matches the definition of the initial content,
because the repository implementation sets the property after the
checkin.
Nevertheless,
the property has the advantage, that it may already be set in the
repository when you extract it to package it in the bundle.
Not sure what you mean with extract it for packaging. Do you mean
system export? What I do ATM is writing initial content definitions
by hand. Not sure if the property is present directly after the node
is created (and not saved). Anyway I think checking the value of the
property in the repository does not help, because this does not allow
the developer to define if it should be checked in or not.
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.
Cool. Thanks.
Done in SLING-365
BR Alex
