3341 Posts in 982 Topics by 703 members
|Go to End|
5 August 2010 at 1:54am Last edited: 19 December 2011 7:14am
Has anyone developed an application with SilverStripe where an object has a many to many relationship with another object, and the related object has a many to many relationship with another object? e.g. Let's say I have a resource, and the resource has stages. A resource can have 1-n stages and a stage can be assigned to 1-n resources. In addition, a stage can have 1-n categories and a category be assigned to 1-n stages for each resource, but the relationship between stages and categories is not the same for every resource. Can SilverStripe handle a data model such as this? What would the workflow look like? In my estimation a user would:
1. Create a resource
2. Assign a stage
3. Assign categories to the stage related to the resource.
4. Repeat steps two and three for each additional stage assigned to the resource.
19 December 2011 at 4:51am Last edited: 19 December 2011 7:14am
I work since four weeks with SS, and my primary concern is not the flashy lights and bells, but the management of a datamodel with several levels : objectA N----M object B N------M object C N------M object D
I have same concerns of yours and I'm afraid that SS is not capable of handing this.
F.Ex the DOM is very nice but only handles up to 2 levels .
19 December 2011 at 6:48am Last edited: 19 December 2011 7:14am
This is a little confusing the title is "many_many" but the notation in both posts are "1-n" and "n-m"... maybe if you stick to a slightly more long hand "has_many" or "many_many" this would be crystal clear.
Using ModelAdmin I have not come across any relationship depths it is unable to handle in the form...
a has_many b
b has_many c
c has_many d
It opens a greybox popup to edit the relationship and then if you keep drilling down it down replace the greybox popup with the new one. This has a limitation of no back (i.e. once editing d you can only return to a, not c).
If d has_many a this creates a circle and the scaffolding fails - easily fixed by removing it within getCMSFields, but it ends the ability to "drill down" into the relationship.
I normally handle the many_many with multi select rather than the ManyManyComplexTableField, but I assume if I didn't it would allow the editing of the relationship as above.
So to summarise - avoid circular relationships and try to use ModelAdmin.
|Go to Top|