[drupal-devel] clipper and relations
Hi there, I just rewrote my clipper module. I abandoned the idea of taxonomy as relation manager, and went for the proposed (http://drupal.org/node/28480) relationship system. I introduced the table, and wrote a lot of APIs in my clipper module. I think this is interesting enough for anyone who wants to do anything with relations. I think that anyone doing anything with relations, should at least consider using the table, and probably re-using some of my apis. Dependency on clipper might not be wanted. SO if anyone feels like taking the API out of clipper, feel free to put that in a relation.inc. I will be more than happy to support such a library. Next in line for conversion to this system is shazamgallery. And please send me a note if if you have plans for a relation module or system, we might be of great help for eachother :) In my mind: outliner.module book.module (hehe) read_also.module autorelations.module (I did some patter matching magic before to find related nodes) .... ? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01 Sep 2005, at 11:17 AM, Bèr Kessels wrote:
Hi there,
I just rewrote my clipper module. I abandoned the idea of taxonomy as relation manager, and went for the proposed (http://drupal.org/node/28480) relationship system. I introduced the table, and wrote a lot of APIs in my clipper module.
Sweet. I still think clipper is a bad name , but i definitely support a relation.inc
In my mind: outliner.module book.module (hehe) read_also.module autorelations.module (I did some patter matching magic before to find related nodes) There are so many places this is needed, it's not even funny.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDFztDgegMqdGlkasRAjT+AJ4iIfVwbX73BQGoVYIh6xsko5eCHgCfcp7f JxxHV/ngPTotb3n7IiL93OA= =SnhQ -----END PGP SIGNATURE-----
On 1-Sep-05, at 2:17 AM, Bèr Kessels wrote:
I just rewrote my clipper module. I abandoned the idea of taxonomy as relation manager, and went for the proposed (http://drupal.org/node/28480) relationship system. I introduced the table, and wrote a lot of APIs in my clipper module.
That's great, Ber! We just talked a bit in the office here, since Colin will re-write a playlist module he's working on to use the relations table as well. We should standardize on the relationship label to be $module-$relation. So, for clipper, it should actually be clipper-child or clipper-parent, and for playlist it would be playlist-track. For parent/child, this would likely be a "default" relation modeled in the relation.module -- so likely just called "parent" and "child". Maybe you want to create a project/CVS for it? We can just put the relation table MySQL in there for now. -- Boris Mann http://www.bmannconsulting.com
My .02 on this: 1. I do not get the inverse order in clipper.module:
12 parent-child 15 means that node 12 is parent of 15 45 child-parent 10 means that 10 is parent of 45
Why not just write '10 parent-child 45' ? 2. how to impress the 'strength' or 'weight' of the relation between two nodes? 3. relationships are so genereric feature so they proably need a $domain(s) property(ies) so 'uid:12 <-> uid:13' and similar relations can be mapped. Implementing this (and domain for relation itself) we are approaching to RDF [1] territory really fast ;) k [1] http://www.ilrt.bris.ac.uk/discovery/rdf/resources/
Op woensdag 07 september 2005 08:52, schreef Kristjan Jansen:
Why not just write '10 parent-child 45' ? No, why? clipper is just a playground for me, to test the capabilities and limits of this concept of realtions. My thought was: it is possible to do reverse paernt-child relationjs, so there sill eventually be a module that will do that. Also: I feel that clipper-parent or clipper-child is too limiting. foo_relation.module might want to use the relations from clipper or any other parent-child relation too.
2. how to impress the 'strength' or 'weight' of the relation between two nodes?
The weight column? Or am I misunderstanding you?
3. relationships are so genereric feature so they proably need a $domain(s) property(ies) so 'uid:12 <-> uid:13' and similar relations can be mapped.
Yes, this has been bothering me too. So far I have not though up a better idea. Though some ideas have been cooking in my mind. A short summary will follow in the thread at http://drupal.org/node/28480. uid:12 uid:13 is not a good solution, for it needs pattern postprocessing, a lot of database overhead (eight extra characters per relation) but I have some ideas.. :-) Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 6-Sep-05, at 11:52 PM, Kristjan Jansen wrote:
My .02 on this:
1. I do not get the inverse order in clipper.module:
12 parent-child 15 means that node 12 is parent of 15 45 child-parent 10 means that 10 is parent of 45
Why not just write '10 parent-child 45' ?
Thinking about this today, we can actually probably just do "12 clipper-parent 15". Actually, parent-child would be modeled by default in the relation.module, but it lets me illustrate that we'll standardize on $modulename-relation.
2. how to impress the 'strength' or 'weight' of the relation between two nodes?
There is a weight column, we've just been skipping it in examples.
3. relationships are so genereric feature so they proably need a $domain(s) property(ies) so 'uid:12 <-> uid:13' and similar relations can be mapped.
It's actually a left-id and right-id, NOT restricted to node-ids. So, it can already handle user-ids or anything else. As per Adrian's example with buddylist, it might be something like: 12 buddylist-buddy 13 13 buddylist-enemy 14 It's up to the implementing module to decide what to do with the data in the table. The relation.module will just provide helper functions for dealing with a lot of the basics, implement basic relations and default displays. Modules can the focus on UI or other more complex display/workflow issues. Ideally, like event or attachment etc., any content type could be relation-enabled.
Implementing this (and domain for relation itself) we are approaching to RDF [1] territory really fast ;)
Is that a bad thing? :P -- Boris Mann http://www.bmannconsulting.com
On 9/7/05, Boris Mann <borismann@gmail.com> wrote:
On 6-Sep-05, at 11:52 PM, Kristjan Jansen wrote:
My .02 on this:
1. I do not get the inverse order in clipper.module:
12 parent-child 15 means that node 12 is parent of 15 45 child-parent 10 means that 10 is parent of 45
Why not just write '10 parent-child 45' ?
Thinking about this today, we can actually probably just do "12 clipper-parent 15". Actually, parent-child would be modeled by default in the relation.module, but it lets me illustrate that we'll standardize on $modulename-relation.
aha, so you are hinting that there gonna be a default set of relations defined in relation.inc like relation_parent_child relation_child_parent relation_* somehow i tend to prefer underscores, it's kinda matching the _hook naming conventions k relation-
please have a look at http://drupal.org/node/28480#comment-42850. Its a revised proposal for the relation mapping. I came with this after developing my second relation module. Op woensdag 07 september 2005 09:36, schreef Kristjan Jansen:
On 9/7/05, Boris Mann <borismann@gmail.com> wrote:
On 6-Sep-05, at 11:52 PM, Kristjan Jansen wrote:
My .02 on this:
1. I do not get the inverse order in clipper.module:
12 parent-child 15 means that node 12 is parent of 15 45 child-parent 10 means that 10 is parent of 45
Why not just write '10 parent-child 45' ?
Thinking about this today, we can actually probably just do "12 clipper-parent 15". Actually, parent-child would be modeled by default in the relation.module, but it lets me illustrate that we'll standardize on $modulename-relation.
aha, so you are hinting that there gonna be a default set of relations defined in relation.inc like
relation_parent_child relation_child_parent relation_*
somehow i tend to prefer underscores, it's kinda matching the _hook naming conventions
k
relation- Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07 Sep 2005, at 12:03 PM, Bèr Kessels wrote:
please have a look at http://drupal.org/node/28480#comment-42850. Its a revised proposal for the relation mapping. I came with this after developing my second relation module.
I second that. It's more columns, but it allows the data to be better normalized, and it allows us mapping to users and nodes, although theoretically it would be better when profiles are nodes too. Also, it gets out of the situation where we need to have a '-' or '_' in the name. Although in my opinion, the right relationship should be optional, or atleast defaulted to something. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDHtTVgegMqdGlkasRAukvAJ90OPjx8ty1ZD2+uMUhZ6KL7s0p6gCfQbCL PQzYdq5/toJDD1/HGHAKTwg= =N4T0 -----END PGP SIGNATURE-----
On Wednesday 07 September 2005 07:03, Bèr Kessels wrote:
please have a look at http://drupal.org/node/28480#comment-42850. Its a revised proposal for the relation mapping. I came with this after developing my second relation module.
+1 for Bèr proposal Since we're discussing the relation mapping fields, I'd like to invite you to think of 2 other fields: title and description. Although each node has its own title and body, when it comes to relations, each relationship may have a new title and new description which can be different from those of the nodes. Examples: 1 - If you're making a list of books (like Amazon's listmania). Each book (from bookreview module) has its own title and body, but when you create your list of favorite books, you can make annotations regarding what's important in each book, why you recommend them, etc. 2 - If you're creating a virtual tour using pictures, although each picture has its own title and body, since a picture can take different weights for several tours, you can have a different title and description for each picture in each relationship. (Bèr, think about it for shazam) There are many other situations... when you add a buddy you may want to describe who he/she is, when you bookmark a node you can write a description, etc...
On 08/09/2005, at 12:16 AM, Emiliano wrote:
On Wednesday 07 September 2005 07:03, Bèr Kessels wrote:
please have a look at http://drupal.org/node/28480#comment-42850. Its a revised proposal for the relation mapping. I came with this after developing my second relation module.
+1 for Bèr proposal
A generic api for handling relationships is a good thing, this is a wheel that is reinvented over and over again within drupal and the modules. The latest proposals ability to map any id to any id is good for my module too (user_related_content.module, uid <-> nid) Providing a good API for this will also mean we have far less SQL scattered throughout the code which I always see as a good thing too.
Since we're discussing the relation mapping fields, I'd like to invite you to think of 2 other fields: title and description. Although each node has its own title and body, when it comes to relations, each relationship may have a new title and new description which can be different from those of the nodes.
Examples:
1 - If you're making a list of books (like Amazon's listmania). Each book (from bookreview module) has its own title and body, but when you create your list of favorite books, you can make annotations regarding what's important in each book, why you recommend them, etc.
2 - If you're creating a virtual tour using pictures, although each picture has its own title and body, since a picture can take different weights for several tours, you can have a different title and description for each picture in each relationship. (Bèr, think about it for shazam)
There are many other situations... when you add a buddy you may want to describe who he/she is, when you bookmark a node you can write a description, etc...
The problem is that there is a huge number of types of data that may make sense to store with different relationships. I think we should actually take the description (in the current proposal) of what the type of relationship is out of the relationship table and put it into a relationship_type table. i also think most of the 'extra' information modules may want to associate with a module should be maintained in a separate table (much like we 'extend' nodes currently, let's leave the base relationship as a simple common base). Of course, I'm biased as this is the approach I took in user_relationship_module (the api in there is generic to store and retreive many 'different kinds' of relationships, and apart from the explicit naming of uid and nid is close to being very generic). Cheers, Eric
Hello, please try to keep all suggestions in the thread online. So we have a good thread that shows the progress and ideas all toghether. But about the body and title: No. IMO that really dos not belong in th relationships. You are free to add your own module and table, like node_wrapper.module, that makes new nodes, yet uses (parts of) the content of other nodes. That is, IMO the way to go with this. You can use the relation mappings for that ;) and the pictures can already take different weights in each gallery where hey appear, in shazamgallery. with the current table. Op woensdag 07 september 2005 16:16, schreef Emiliano:
On Wednesday 07 September 2005 07:03, Bèr Kessels wrote:
please have a look at http://drupal.org/node/28480#comment-42850. Its a revised proposal for the relation mapping. I came with this after developing my second relation module.
+1 for Bèr proposal
Since we're discussing the relation mapping fields, I'd like to invite you to think of 2 other fields: title and description. Although each node has its own title and body, when it comes to relations, each relationship may have a new title and new description which can be different from those of the nodes.
Examples:
1 - If you're making a list of books (like Amazon's listmania). Each book (from bookreview module) has its own title and body, but when you create your list of favorite books, you can make annotations regarding what's important in each book, why you recommend them, etc.
2 - If you're creating a virtual tour using pictures, although each picture has its own title and body, since a picture can take different weights for several tours, you can have a different title and description for each picture in each relationship. (Bèr, think about it for shazam)
There are many other situations... when you add a buddy you may want to describe who he/she is, when you bookmark a node you can write a description, etc... Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Wednesday 07 September 2005 11:43, Bèr Kessels wrote: Hi,
(...)you are free to add your own module and table, like node_wrapper.module, that makes new nodes, yet uses (parts of) the content of other nodes. That is, IMO the way to go with this. You can use the relation mappings for that ;)
Ok, I agree with you and Eric. If a module needs this fields, the module itself manages a table with them. That's ok. Cheers, Emiliano.
On 7-Sep-05, at 10:16 AM, Emiliano wrote:
There are many other situations... when you add a buddy you may want to describe who he/she is, when you bookmark a node you can write a description, etc...
exactly, I'm hopping into this conversation a bit late ... but yes there are several things I (we) can do with buddylist built on this framework - but describing / naming relationships (and optionally, they could be constrained by an admin - i.e. a site only defines "friend" and "family" relationships for buddies) ... having free relationship definitions would be excellent. -- James Walker :: http://walkah.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07 Sep 2005, at 5:06 PM, James Walker wrote:
exactly, I'm hopping into this conversation a bit late ... but yes there are several things I (we) can do with buddylist built on this framework - but describing / naming relationships (and optionally, they could be constrained by an admin - i.e. a site only defines "friend" and "family" relationships for buddies) ... having free relationship definitions would be excellent.
The relationship definitions are free =). I foresee there being buddy_friend and buddy_family relationships. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDHw/JgegMqdGlkasRAuU5AKCehU6y/huBydkMDcSzvPV/aEvlKwCfZryr ypXS2iLGHcmp6SssLSt0N8M= =Lv7q -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07 Sep 2005, at 4:16 PM, Emiliano wrote:
On Wednesday 07 September 2005 07:03, Bèr Kessels wrote:
please have a look at http://drupal.org/node/28480#comment-42850. Its a revised proposal for the relation mapping. I came with this after developing my second relation module.
+1 for Bèr proposal
Since we're discussing the relation mapping fields, I'd like to invite you to think of 2 other fields: title and description. Although each node has its own title and body, when it comes to relations, each relationship may have a new title and new description which can be different from those of the nodes.
Examples:
1 - If you're making a list of books (like Amazon's listmania). Each book (from bookreview module) has its own title and body, but when you create your list of favorite books, you can make annotations regarding what's important in each book, why you recommend them, etc.
This is why there is a unique relationship ID. You can create another table with those fields, and join them with the relationship id.
2 - If you're creating a virtual tour using pictures, although each picture has its own title and body, since a picture can take different weights for several tours, you can have a different title and description for each picture in each relationship. (Bèr, think about it for shazam) Each picture is a node, and weights are already in the spec.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDHw8agegMqdGlkasRAnQRAKC2614kxEdfRf2Ssx7Afaf0Ej/JQACcDk3j WUROu+KfBavimrI+w59wOfk= =f+l3 -----END PGP SIGNATURE-----
participants (7)
-
Adrian Rossouw -
Boris Mann -
Bèr Kessels -
Emiliano -
Eric Orton -
James Walker -
Kristjan Jansen