You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Brian Moseley <bc...@osafoundation.org> on 2005/06/21 02:50:38 UTC
default value for initializing date property
i'm using this code to define a property:
InternalValue[] defaultValues1 = {
InternalValue.create(Calendar.getInstance())
};
PropDefImpl createdDef = new PropDefImpl();
createdDef.setName(new QName(URI_TICKET, "created"));
createdDef.setRequiredType(PropertyType.DATE);
createdDef.setAutoCreated(true);
createdDef.setDefaultValues(defaultValues1);
createdDef.setMandatory(true);
createdDef.setOnParentVersion(OnParentVersionAction.INITIALIZE);
createdDef.setProtected(true);
createdDef.setMultiple(false);
createdDef.setDeclaringNodeType(ticketDef.getName());
with this code, the declaring node type definition successfully registers.
however, looking at custom_nodetypes.xml, the default value is being set
to the moment in time that i execute the above code to register the node
type ("<defaultValue>2005-06-20T17:43:47.364-07:00</defaultValue>").
this makes a kind of sense, but it's not what i want.
how can i define the property such that the property's value is set to
the time when the node is created, not when the node type is registered?
this is exactly how jcr:created behaves, isn't it?
Re: default value for initializing date property
Posted by Stefan Guggisberg <st...@gmail.com>.
hi digby,
On 6/30/05, Digby <li...@digby.net> wrote:
> Hi Stefan,
>
> > node type management has been intentionally left out in
> > version 1.0 of the spec. we plan to cover node type mgmt
> > (amongst other features such as access control mgmt etc)
> > in the next version of the spec (probably 1.1).
>
> Were you refering to the next JSR-170 spec or the next version of
> Jackrabbit (access control in particular)?
i was refering to the next version of the JSR-170 specification.
access control management in particular is a tough topic
as it's very hard to define a common demoninator among the
various established security models.
cheers
stefan
>
> Many thanks,
>
> Digby
>
>
Re: default value for initializing date property
Posted by Digby <li...@digby.net>.
Hi Stefan,
> node type management has been intentionally left out in
> version 1.0 of the spec. we plan to cover node type mgmt
> (amongst other features such as access control mgmt etc)
> in the next version of the spec (probably 1.1).
Were you refering to the next JSR-170 spec or the next version of
Jackrabbit (access control in particular)?
Many thanks,
Digby
Re: default value for initializing date property
Posted by Stefan Guggisberg <st...@gmail.com>.
On 6/21/05, Brian Moseley <bc...@osafoundation.org> wrote:
> Stefan Guggisberg wrote:
>
> > what i have in mind is a NodeTypeInstanceHandler callback interface
> > that can be registered for a specific node type. there are several
> > open questions/problems though, e.g. portability, xml format of a
> > node type with dynamic default values, dynamic values that depend
> > on other values, method signatures of the callbck interface etc etc
> > however it's on my todo list.
>
> ok, thanks. any suggestions for a workaround in the
> meantime? i suppose i could make the property not protected
> and actually set it when i create the node.
yes, that would IMO be an acceptable workaround.
>
> is there any provision in the spec for modifying registered
> node types, sort of like ALTER TABLE in sql? (sorry, don't
> have the spec handy, will check when i get to the office.)
> that would allow me to use the hack i suggest above and then
> adapt gracefully once dynamic default values are supported.
node type management has been intentionally left out in
version 1.0 of the spec. we plan to cover node type mgmt
(amongst other features such as access control mgmt etc)
in the next version of the spec (probably 1.1).
cheers
stefan
>
Re: default value for initializing date property
Posted by Brian Moseley <bc...@osafoundation.org>.
Stefan Guggisberg wrote:
> what i have in mind is a NodeTypeInstanceHandler callback interface
> that can be registered for a specific node type. there are several
> open questions/problems though, e.g. portability, xml format of a
> node type with dynamic default values, dynamic values that depend
> on other values, method signatures of the callbck interface etc etc
> however it's on my todo list.
ok, thanks. any suggestions for a workaround in the
meantime? i suppose i could make the property not protected
and actually set it when i create the node.
is there any provision in the spec for modifying registered
node types, sort of like ALTER TABLE in sql? (sorry, don't
have the spec handy, will check when i get to the office.)
that would allow me to use the hack i suggest above and then
adapt gracefully once dynamic default values are supported.
Re: default value for initializing date property
Posted by Stefan Guggisberg <st...@gmail.com>.
On 6/21/05, Brian Moseley <bc...@osafoundation.org> wrote:
>
> i'm using this code to define a property:
>
> InternalValue[] defaultValues1 = {
> InternalValue.create(Calendar.getInstance())
> };
>
> PropDefImpl createdDef = new PropDefImpl();
> createdDef.setName(new QName(URI_TICKET, "created"));
> createdDef.setRequiredType(PropertyType.DATE);
> createdDef.setAutoCreated(true);
> createdDef.setDefaultValues(defaultValues1);
> createdDef.setMandatory(true);
> createdDef.setOnParentVersion(OnParentVersionAction.INITIALIZE);
> createdDef.setProtected(true);
> createdDef.setMultiple(false);
> createdDef.setDeclaringNodeType(ticketDef.getName());
>
> with this code, the declaring node type definition successfully registers.
>
> however, looking at custom_nodetypes.xml, the default value is being set
> to the moment in time that i execute the above code to register the node
> type ("<defaultValue>2005-06-20T17:43:47.364-07:00</defaultValue>").
> this makes a kind of sense, but it's not what i want.
>
> how can i define the property such that the property's value is set to
> the time when the node is created, not when the node type is registered?
dynamic default values are not yet supported. there are some related
inline @todo comments. see
BatchedItemOperations#computeSystemGeneratedPropertyValues
and NodeImpl#computeSystemGeneratedPropertyValues.
what i have in mind is a NodeTypeInstanceHandler callback interface
that can be registered for a specific node type. there are several
open questions/problems though, e.g. portability, xml format of a
node type with dynamic default values, dynamic values that depend
on other values, method signatures of the callbck interface etc etc
however it's on my todo list.
> this is exactly how jcr:created behaves, isn't it?
the behaviour of jcr:created is spec'ed in jsr 170 and is hardcoded in
jackrabbit. once we have a clean way of declaring/applying dynamic
default values i'll replace that code with a generic solution.
cheers
stefan
>