jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: 3.1.3.1 Removing Items
Date Tue, 24 Jul 2007 17:56:15 GMT
On 7/24/07, IvanLatysh <ivan@yourmail.com> wrote:
>
> Tako Schotanus wrote:
>
> >> > Yes.  Make the date field an optional property.  If the property
> >> exists,
> >> > then the field is present.  If not, then the field is absent.
> >> Excellent, but how would user fill-up this `absent` field when we
> decide
> >> to?
>
> Just before I answer on this one I want to mention that we are dealing
> with
> unstructured data manager where structure is a part of the data.
>
> > First of all you showed the original form in _some_ way so you could
> store
> > that information with the user data.
> That what we have to do in order to overcome JCR shortcoming with null's.
>
> > Or you could store a list of all the field names, or just the ones that
> > were left empty.
> >
> > You could store the fields in a user node type, that has a "value" sub
> > node,
> > not only could your application decide that a non-existing "value" node
> is
> > the same as "null", but you could add a whole bunch of extra information
> if
> > necessary (maybe the field was not editable but had a default value so
> you
> > want to remember that the value was not entered by the user).
> >
> > You could probably find lots more ways to model this.
> Yes I can and also I can use regular RDBMS or XMLDB to solve this problem.
>
> But discussion is not about a workaround but about an JCR behavior
> regarding
> Java null type.


I'm sorry, these are not workarounds, but perfectly valid alternatives,
you've given one, some of us don't agree with your solution and I've shown
that you could easily think of several others. I don't see why your way of
doing things is somehow superior and "the only way" of solving your problem.

-Tako

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message