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]
