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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
