I'm building a system that requires a member to be linked to another content node and for one additional attribute to be added with the link information.
Basically I have a Member that say "I'm going to this event", "I'm thinking about going", "I'm not going" so these are the additional attributes I'll probably hold as settings Nodes.
And now at the front end when the user is on the website (and signed in) i want them to be able to click a button that will link their Member ID to the Node ID with the additional attribute as described above.
Please could someone give me an idea of whether this can be done with the Umbraco ID in stead of creating additional tables in the database?
You could establish a relationship between a member (or its id) and a content node id) using the existing umbraco api (it's similar as when you're copying nodes - there's a little checkbox 'related item'). I know of some blog posts about this subject, just can't find those atm, will do some searching...
That looks like what I'm needing the only addition to that is the third link or attribute. That is the flag to say "I'm going to this event", "I'm thinking about going", "I'm not going"
As any Member can link to 1 or many Events I don't want to hold this additional attribute on the Event or on the Member but on the link.
I cant see a good way of chaining the relationship so I link Member to attribute to Event, I think it really needs to work Member to (Link with additional attribute) to Event.
Cheers for the help. I'm still a little confused but i'll try to explain and see if i'm going down the right route. At the moment i think of the relationships as:
1. Link Event to Attendance - This is a ContentItem to ContentItem Relationship. I'll call it relateEventToAttendance
2. Link Attendance to Member - This is a ContentItem to Member Relationship. I'll call it relateAttendanceToMember
I think i'm missing a step at the moment. I need to unbind the relationship between the Node and the AttendanceType and the Member and AttendanceType but i dont know how to do that. Any pointers you have to add the third relationship to disconnect these 2 things would be very much appreciated.
My initial thoughts were three db rows, creating relationships that define how a member can be associated to an event.
id
dual
parentObjectType
childObjectType
name
alias
..
1
39EB0F98-B348-42A1-8662-E7EB18487560
C66BA18E-EAF3-4CFF-8A22-41B16D66A972
Member is going to this Event
relateMemberGoingEvent
..
1
39EB0F98-B348-42A1-8662-E7EB18487560
C66BA18E-EAF3-4CFF-8A22-41B16D66A972
Member is considering going to this Event
relateMemberConsideringEvent
..
1
39EB0F98-B348-42A1-8662-E7EB18487560
C66BA18E-EAF3-4CFF-8A22-41B16D66A972
Member is not going this Event
relateMemberNotGoingEvent
You could then use the API like :
/* Get all Members going to Event */
RelationType relationType = RelationType.GetByAlias("relateMemberGoingEvent");
Relation[] relations = Relation.GetRelations(documentEvent.Id, relationType);
Member member;
foreach (Relation relation in relations)
{
member = new Member(relation.Parent.Id);
}
(I've not tested it, but as 'dual = 1' on the relation type, I think it looks on both keys.)
Ahh. Yes absolutley I was coming at the issue from the point of view of how i would do it in a DB. The way you sugest for three options works perfectly however it would get somewhat problematic if it became a true many to many relationship.
The problematic bit does not relate to my problem.
But i mean if you have for example 100 or 1000 possible links that are required then you'll need to add a Relationship Type for each possible link and if you have 3 places where this is required then you have the potential to have 3x 100 or 3x 1000 Relationship Types.
I don't see it being very managable at that stage.
Maybe i'm barking up the wrong tree though and there is a better way.
Slightly abstract, but It's a shame there isn't an ObjectType guid for a RelationType; was thinking how to implement a hierarachy of RelationTypes, and what benefits that could offer...
Link Node id to member Id
Hey
I'm building a system that requires a member to be linked to another content node and for one additional attribute to be added with the link information.
Basically I have a Member that say "I'm going to this event", "I'm thinking about going", "I'm not going" so these are the additional attributes I'll probably hold as settings Nodes.
And now at the front end when the user is on the website (and signed in) i want them to be able to click a button that will link their Member ID to the Node ID with the additional attribute as described above.
Please could someone give me an idea of whether this can be done with the Umbraco ID in stead of creating additional tables in the database?
Cheers
Jon
Hi Jon,
You could establish a relationship between a member (or its id) and a content node id) using the existing umbraco api (it's similar as when you're copying nodes - there's a little checkbox 'related item'). I know of some blog posts about this subject, just can't find those atm, will do some searching...
Cheers,
/Dirk
Found it... http://blog.hendyracher.co.uk/umbraco-relation-api/
Alternative solution: add an extra property on the member type to hold the node id.
Cheers,
/Dirk
Hi Dirk
That looks like what I'm needing the only addition to that is the third link or attribute. That is the flag to say "I'm going to this event", "I'm thinking about going", "I'm not going"
As any Member can link to 1 or many Events I don't want to hold this additional attribute on the Event or on the Member but on the link.
I cant see a good way of chaining the relationship so I link Member to attribute to Event, I think it really needs to work Member to (Link with additional attribute) to Event.
any ideas?
Cheers
Jon
Hi Jon,
How about adding three rows to the umbracoRelationType table to define each of these relationships ?
You can then infer the type of association between MemberID to NodeID by the particular relationship alias used.
HTH,
Hendy
Hi Hendy
Cheers for the help. I'm still a little confused but i'll try to explain and see if i'm going down the right route. At the moment i think of the relationships as:
1. Link Event to Attendance - This is a ContentItem to ContentItem Relationship. I'll call it relateEventToAttendance
2. Link Attendance to Member - This is a ContentItem to Member Relationship. I'll call it relateAttendanceToMember
I think i'm missing a step at the moment. I need to unbind the relationship between the Node and the AttendanceType and the Member and AttendanceType but i dont know how to do that. Any pointers you have to add the third relationship to disconnect these 2 things would be very much appreciated.
Cheers
Jon
Hi Jon,
My initial thoughts were three db rows, creating relationships that define how a member can be associated to an event.
You could then use the API like :
/* Get all Members going to Event */ RelationType relationType = RelationType.GetByAlias("relateMemberGoingEvent"); Relation[] relations = Relation.GetRelations(documentEvent.Id, relationType); Member member; foreach (Relation relation in relations) { member = new Member(relation.Parent.Id); }(I've not tested it, but as 'dual = 1' on the relation type, I think it looks on both keys.)
Ahh. Yes absolutley I was coming at the issue from the point of view of how i would do it in a DB. The way you sugest for three options works perfectly however it would get somewhat problematic if it became a true many to many relationship.
Cheers
Jon
Hi Jon, how do you mean it'll become problematic ?
The problematic bit does not relate to my problem.
But i mean if you have for example 100 or 1000 possible links that are required then you'll need to add a Relationship Type for each possible link and if you have 3 places where this is required then you have the potential to have 3x 100 or 3x 1000 Relationship Types.
I don't see it being very managable at that stage.
Maybe i'm barking up the wrong tree though and there is a better way.
Jon
Slightly abstract, but It's a shame there isn't an ObjectType guid for a RelationType; was thinking how to implement a hierarachy of RelationTypes, and what benefits that could offer...
Yes thats what i was thinking because then you would only ever need 3 types to do any type of linking. I guess it may be worth a feature request.
is working on a reply...