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 19:10:23 GMT
Ivan, I do understand what you mean, I really do.
The CVS vs SVN just isn't a good example IMO because there was no other way
to get empty folders stored in CVS.
A very important secondary reason is that the information must necessarily
be retrieved from CVS as you put it in, that is the reason it exists! While
a JCR can be compared more to a database: you decide how to put the
information in, how to get it out and what it all means.

So instead of your example where a GUI form is modeled more or less like
this:

 + somePerson (foo:form)
    - name = "joe"
    - address = "some street 17"
    - city = "somewhere"
    - age = 32
    - telnr = null

I suggest that this format could be used:

 + somePerson (foo:form)
    + name (foo:field)
       - value = "joe"
    + address (foo:field)
       - value = "some street 17"
    + city (foo:field)
       - value = "somewhere"
    + age (foo:field)
       - value = 32
    + telnr (foo:field)

This way there is no need for a null value, all the information is there and
as a bonus you could even add extra information for each field:

    + name (foo:field)
       - value = "joe"
       - changed = true

to indicate that the field was changed by the use from its original value,
or:

    + birthdate (foo:field)
       - value = 1-5-75
    + age (foo:field)
       - value = 32
       - computedField = true

to indicate that the field contains a computed value and should not be
stored, transmitted, printed, whatever.

Dunno, but I only see advantages from doing it this way :-)

Cheers,
-Tako



On 7/24/07, IvanLatysh <ivan@yourmail.com> wrote:
>
> IvanLatysh wrote:
>
> >> 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.
> >
> > Again data structure stored in JCR are data itself, and removing a
> > property cause does lose.
>
> I need to explain what do I mean here ...
>
> As I can see many participants use JCR with known (defined) data
> structured.
> We do not know the data structure up-front, and for us data structure as
> much
> important as the data itself.
>
> I want to draw an analogy with CVS and Subversion.
> As you know CVS does not check-out empty folders (by default).
> So many dev. teams had to put some placeholders to force CVS to checkout
> this
> folder. As we all can see from our practice, dev. team value FS structure
> as
> much as the source code. Many teams used such work-around (not solution)
> until
> Subversion come around. On the other hand CVS does not allow to remove a
> folder,
> that cause quite a bit of pain for many teams. And now most people agree
> that it
> is a synthetic restrictions that make no sense.
> So Subversion come around and teams start switching to it since it is
> flexible
> enough to fit their model.
> Same thing happening with JCR null support. It is a synthetic restriction
> that
> many will live with until they have an alternative. But it does not mean
> that it
> is the right way to do.
>
> This why I have seen a few work-around for the problem, but it does not
> mean
> that it is a right way to do. Again developers do not look for a
> work-around
> when library perform in expected manner.
>
> --
> Ivan Latysh
> ivan@yourmail.com
>

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