Hi,
Tobias Bocanegra schrieb:
> hi,
> the spec of JSR283 defines a new mixin node type:
>
> [mix:lastModified] mixin
> - jcr:lastModified (DATE) protected? OPV?
> - jcr:lastModifiedBy (STRING) protected? OPV?
>
> "This mixin node type can be used to provide standardized modification
> information properties to a node. Since the properties are protected,
> their values
> are controlled by the repository, which should set them appropriately upon a
> significant modification of the subgraph of a node with this mixin. What
> constitutes a significant modification will depend on the semantics of
> the various
> parts of a node's subgraph and is implementation-dependent."
>
> Since the "protected" attributes are variant, we can implement them as we
> wish.
> i would like to have a "good" jcr:lastModified behavior that is
> directly provided by the repository.
> OTOH when dealing with files (nt:file) uploaded from a filesystem, it
> probably makes sense to transport the last-modified of the original
> file.
>
> we need to define:
> 1) does jackrabbit support automatic jcr:lastModified computation ?
> 2) if yes, do we make it protected ?
> 3) what operations on which scope affect which jcr:lastModified properties
> 4) does changing the jcr:lastModified property trigger an observation event?
>
> at a first glance, i would say:
> 1) yes, please support it
+1 (and apply to jcr:lastModifiedBy property, too)
> 2) no, keep it writable
+2 (and apply to jcr:lastModifiedBy property, too)
1) and 2) combined would give us the best result probably: By default
(and when the mixin is first applied to a node) the property is set to
the current time. But this may then be overwritten by an uploaded file's
effective last modified timestamp.
Another use case would be a JSP Compiler writing class files into the
repository (as we do in Sling). Such a compiler could set the
jcr:lastModified and jcr:lastModifiedBy properties to the values of the
respective properties of the JSP source file.
> 3) all changes (except versioning and import operations) in an
> mix:lastModified aggregate affect it's last modified property. the
> aggregate is defined as sub-tree below a mix:lastModified node,
> without all other mix:lastModified sub-trees.
+1, makes absolute sense
> 4) don't know - probably not
I think it should because:
-- the jcr:lastModified[By] property is modified automatically
if other content is changed. Hence it is part of a bigger
content update and we would expect such an event
-- if the jcr:lastModified[By] property is explicitly modified,
it is a modification like any other modification and must
have an event.
Regards
Felix
>
> WDYT ?
> regards, toby
>
