ODM: Sum up proxies, parent, children, references and the like
Uwe Jäger
I updated the wiki [1] to sum up what has been written about documents
and their relations with other documents. Besides some consolidation
on the topics there are new questions to discuss:
1. Should we include the Symfony component Console to have commands to
create proxy classes and other things (like checking if phpcr:managed
is available)?
2. How do we populate the content tree? Currently the path of a node
defines the node's parent. With @Parent and @Child annotations this
could be done more explicit
3. What should be filtered with the filters on a @Children annotation,
node names or node property values, node types ... a first start could
be a name filter like PHPCR Node::getNodes
4. Several simplifications as a first step getting something coded
(like @Children being immutable etc.)
All feedback welcome!
Kind regards
Uwe
[1] https://github.com/doctrine/phpcr-odm/wiki/References-and-related
Benjamin Eberlei
1. Yes, Console is good to include, its a dependency of almost every
Doctrine project.
2/4. Yes we should probably implement read only @Parent and @Child,
@Children first. Then look how to make it writeable.
3. Question back: What could be filtered?
greetings,
Benjamin
On Mon, 28 Mar 2011 23:58:26 +0200, Uwe Jäger <uwe...@googlemail.com>
wrote:
David Buchmann
Hash: SHA1
hi uwe,
thanks for this excellent sum-up! i added some comments in the wiki.
1. +1 for the console
2. yes, and it would avoid trying to add nodes where there is no parent.
i think its the right way that the node either needs to be a Child of a
node or have a Parent attribute.
3. i would filter on the phpcr getNodes syntax to keep things simple.
filtering on properties and such quickly gets us into the search. and
search is more powerful. i would draw the line where phpcr did it and
just filter on node names.
4. yes, i would keep @children immutable. @parent as well, changing the
parent is the move operation.
did you see my comment about iterators and collections? this is really
an optimization topic to do lazy loading. might be useful to note on the
wiki page for later.
cheers,david
ps: i looked into the jackrabbit side of register node type. i realized
how happy i am developing php and not java... i wrote to the jackrabbit
list and got some pointers. i will give it another try with the info i got.
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2RmcgACgkQqBnXnqWBgIvBbQCfVBOY/9DlDMgVZV7ZSs40RxPx
uCUAoJN37uml/xoHQwz2n9JoOCEZcDzL
=xOIE
-----END PGP SIGNATURE-----
Uwe Jäger
If you need any help on the Java stuff let me know I did some Java in the past :-)
Did you see the other wiki page about the node type?
Yes I will add the collection and the iterator information to the page, it was just late yesterday.
Kind regards
Uwe
Uwe Jäger
2/4: as David notes Child and Parent can be used to build the content tree so they are not read only but immutable (but Child could be reset)
3: I agree with David that we first should stick with filtering on children's names as this is already in phpcr.
Kind regards
Uwe
Lukas Kahwe Smith
Hash: SHA1
On 29.03.2011, at 10:35, David Buchmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi uwe,
>
> thanks for this excellent sum-up! i added some comments in the wiki.
>
> 1. +1 for the console
> 2. yes, and it would avoid trying to add nodes where there is no parent.
> i think its the right way that the node either needs to be a Child of a
> node or have a Parent attribute.
> 3. i would filter on the phpcr getNodes syntax to keep things simple.
> filtering on properties and such quickly gets us into the search. and
> search is more powerful. i would draw the line where phpcr did it and
> just filter on node names.
> 4. yes, i would keep @children immutable. @parent as well, changing the
> parent is the move operation.
but i guess when creating a new document the parent can be assigned just like the name? the question is then if we default to using the RepositoryGenerator instead of the AssignedIDGenerator that constructs the path from the parent and name (raising an exception if not possible).
regards,
Lukas Kahwe Smith
sm...@pooteeweet.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAk2RyTAACgkQ2FnmJDTfRPctdwCeKphan/sETdslO/gnP97Jr/ET
EuoAoNpBujXcz6dBa60volcRuKnCvf0u
=VW4u
-----END PGP SIGNATURE-----
Uwe Jäger
the mapping of the parent would be optional, so when @Parent is mapped
and is set it should be the parent, if it is mapped but nor set, then
the parent should be "jcr:root". RepositoryGenerator and
AssignedIdGenerator could supply the name in both cases from the
child's perspective. If @Parent is not mapped at all, then we use the
path exactly like now. I can also imagine situations when the parent
document should be responsible for the child's name. So I think we
need some more ideas and opinions on that topic (which then should
also include the solution for "renaming path to id" ...)
Kind regards
Uwe
2011/3/29 Lukas Kahwe Smith <sm...@pooteeweet.org>:
David Buchmann
Hash: SHA1
hi uwe,
> If you need any help on the Java stuff let me know I did some Java in the past :-)
great. i did too, but i am overwhelmed by the amount of classes involved
in a jackrabbit request. i got some pointers on the mailing list, lets
see if we can get it somewhere. we actually only need the server side of
it in java - not sure however if they will accept a patch without the
client side...
if we do the client side as well, we can use the simple client chregu
wrote
https://github.com/jackalope/JavaDavexClient/blob/master/examples/RegisterNodeTypes-Client.java
if we don't we have to implement it in the jackalope transport layer and
write a test in jackalope-api-tests to trigger it.
i will give this one more go tomorrow. lets keep us updated when either
of us achieves something :-)
just to be sure, i checked to make sure: in nt:file you can not even
have a property in a different namespace. would have been too simple.
cheers,david
iEYEARECAAYFAk2S8h8ACgkQqBnXnqWBgIstXACgyaPR9CONOwUY17nvf7zMiCkK
CW4AoLMWZDsWZvuAtYLq2gV9mI7T67cK
=VLgx
-----END PGP SIGNATURE-----