Hello, all. This is Karl, aka Karlheinz, the developer for the Discogs module. I'm trying to work with Zirafa, author of the Pushtape module, to come up with a centralized discography framework for Drupal. (I'm also going to see if the Spotify module wants to get on board with this.) We have, however, run into a snag. His module is track-centered, whereas mine is album-centered. In order to have tracks and albums as separate nodes, we need to have some sort of reference to multiple track nodes from an album node. Furthermore, we also need the ability to add Track nodes as we are creating an Album node - that is, we need the ability to create multiple nodes, and their references, all from the single form used to create an album. What should NOT happen is that the user has to create each track individually before they create an album that has those tracks - this is a workflow nightmare. (And it's currently how Pushtape works.) There are currently three D7 modules used to create node references: References, Entity Reference, and Relation. References is the only one not currently in beta - and it's being depricated in favor of one of the other two. Furthermore, as far as I can tell, none of the above allow you to create the references unless the nodes already exist. I had hoped that the new Fields API in D7 would have included this functionality, but alas it was not the case. (I was actually very surprised at this; frankly, I believe it should have been in Drupal since day 1. A "node" is just a piece of information, after all, and there's a reason everyone uses a "relational" database for information.) So, I'm wondering if there isn't the possibility of moving this functionality into Drupal core. If not for D7 (which seems like a lost cause), then for D8 at the very least. In the meantime, is there any one of the three aforementioned node reference modules that the folks at Drupal core think is most promising? We absolutely, positively need this functionality, and we don't want to have to change dependencies - again - due to issues with third parties. p.s. I've been reading all the posts about re-purposing this list to include module developers. We've had this conversation before, but if it's being considered again, I am all for it. The support list is ABSOLUTELY NOT useful in any way for us, and there is currently NO appropriate mailing list for module developers to use. In the meantime, I've been using the Module Development and Code Questions section of the forum, when I need to.http://drupal.org/forum/4 -Karl.
On Thu, Mar 1, 2012 at 11:19 AM, Karl Giesing <khzmusik@hotmail.com> wrote:
His module is track-centered, whereas mine is album-centered. In order to have tracks and albums as separate nodes, we need to have some sort of reference to multiple track nodes from an album node.
Furthermore, we also need the ability to add Track nodes as we are creating an Album node - that is, we need the ability to create multiple nodes, and their references, all from the single form used to create an album. What should NOT happen is that the user has to create each track individually before they create an album that has those tracks - this is a workflow nightmare. (And it's currently how Pushtape works.)
The first thing that came to my mind is http://drupal.org/project/relativity but there is no D7 version as yet. It would be a great start to having a parent node as the album cover and the children of that node be the tracks. -- Earnie -- https://sites.google.com/site/earnieboyd
I havent done alot of work in relations recently but from what ive seen and used the relations module will probably be the way to go to establish the relationship longer term but references gets thejob done today for you. You might want to consider using a ctools multistep form with an onscreen link on the "add album" edit page that links to "add a track modal/multistep" and have it return the nid that is created for relation to add it to the relation on the node youre making in the last step. I think this might be best handled as a custom multistep form that takes the albums initial data repurposing the node edit form, track data doing the same and then saves the entities in the correct order but hopefully someone has a more concrete answer for you that has been down your path. Good luck and please let us know how you settle it. -- Michael Favia michael@favias.org tel. 512.585.5650 http://www.favish.com
Am 01.03.2012 17:19, schrieb Karl Giesing:
Furthermore, we also need the ability to add Track nodes as we are creating an Album node - that is, we need the ability to create multiple nodes, and their references, all from the single form used to create an album. What should NOT happen is that the user has to create each track individually before they create an album that has those tracks - this is a workflow nightmare. (And it's currently how Pushtape works.)
There are currently three D7 modules used to create node references: References, Entity Reference, and Relation. References is the only one not currently in beta - and it's being depricated in favor of one of the other two. Furthermore, as far as I can tell, none of the above allow you to create the references unless the nodes already exist.
Creating 0-n other entities as part of the initial creation/form flow of a parent entity, and handling that correctly in terms of what data to store where and what to do in case of validation errors down the line, is the tricky part. That's a conceptual problem. Before even thinking of moving module X or Y into core, we need to solve that conceptual problem. AFAICS, there are two possible ways to approach it: 1) Form-stacking or multiple form-states The parent entity creation form additionally needs to contain the full creation forms for the referenced entities. As well as each respective $form_state. This requires a proper and clean encapsulation of form structures and submitted form values. Because, you guessed it, all of the child entity forms have the identical form structure (hence, same structure of submitted form values), and it's even possible that the child form and parent form happen to use the same names/structures. Furthermore, the entire reference validation between the children and the parent needs to work on hypothetical unsaved data, the submitted form values. You cannot proceed to form submission (and start to save entities) if there's a form validation error somewhere down the line. Lastly, form submission would have to be processed "top-down", so as to be able to inject the parent entity reference ID at the correct spots for the child entities. That said, we've prepared at least Field API in Drupal 7 for this use-case in http://drupal.org/node/942310, primarily for these projects: - http://drupal.org/project/combofield - http://drupal.org/project/embeddable - http://drupal.org/project/subform - http://drupal.org/project/field_collection chx created http://drupal.org/project/multiform as an attempt to attack the Form API problem. I don't know how mature these projects are. In any case, this approach is very complex and has a high potential to be error-prone. 2) Auto-save Instead of dealing with the complex problem at all, solve it in the most pragmatic way: Create the parent entity early, very early; i.e.: Save the parent entity when entering the parent entity creation form. Thus, the parent entity exists, and so you can reference it from within that very creation form. Apparently, a couple of other CMSs, and even more so, offline and mobile compatible web applications are doing that already. Disk space is cheap and bogus/empty entities can be automatically pruned out later. And of course, auto-save is a very nice usability feature on its own. There's merely one giant show-stopper: form validation of required fields (or entity CRUD-level validation of properties and field values). Auto-save basically means that either no field can be required, or that we'd save invalid data. I don't want to pretend that this approach would be easier, but in terms of total bang for the bucks, it would make much more sense to me. Overall, we should have a serious discussion, BoF, if not even sprint on this topic. Thanks, sun
On Thu, Mar 1, 2012 at 12:53 PM, Daniel F. Kudwien wrote:
Am 01.03.2012 17:19, schrieb Karl Giesing:
Furthermore, we also need the ability to add Track nodes as we are creating an Album node - that is, we need the ability to create multiple nodes, and their references, all from the single form used to create an album. What should NOT happen is that the user has to create each track individually before they create an album that has those tracks - this is a workflow nightmare. (And it's currently how Pushtape works.)
There are currently three D7 modules used to create node references: References, Entity Reference, and Relation. References is the only one not currently in beta - and it's being depricated in favor of one of the other two. Furthermore, as far as I can tell, none of the above allow you to create the references unless the nodes already exist.
Creating 0-n other entities as part of the initial creation/form flow of a parent entity, and handling that correctly in terms of what data to store where and what to do in case of validation errors down the line, is the tricky part.
How about taxonomy? You could have a term for the album and each track node for the album adds the term. -- Earnie -- https://sites.google.com/site/earnieboyd
One way to solve this in D7 is to use either a combination of Node Reference and Node Reference URL or Entity Reference and Entity Reference Prepopulate. Node Reference URL and Entity Reference Prepopulate are alternative widgets for those fields that let you set a value in the url. They also create an 'Add new ...' link on the referring entity that will go to the url to add a new node, set the value by reference to the source node, and then return you to the place you started. That won't make it possible to create multiple tracks at once, but it does let you create the album first, then click on an 'Add new track' link on the album to add tracks to it. The technique for doing this in D6 is described in http://www.lullabot.com/articles/photo-galleries-views-attachand used by http://drupal.org/project/views_gallery. The same technique works in D7 using either of the above combinations. Karen On Thu, Mar 1, 2012 at 12:40 PM, Earnie Boyd <earnie@users.sourceforge.net>wrote:
On Thu, Mar 1, 2012 at 12:53 PM, Daniel F. Kudwien wrote:
Am 01.03.2012 17:19, schrieb Karl Giesing:
Furthermore, we also need the ability to add Track nodes as we are creating an Album node - that is, we need the ability to create multiple nodes, and their references, all from the single form used to create an album. What should NOT happen is that the user has to create each track individually before they create an album that has those tracks - this is a workflow nightmare. (And it's currently how Pushtape works.)
There are currently three D7 modules used to create node references: References, Entity Reference, and Relation. References is the only one not currently in beta - and it's being depricated in favor of one of the other two. Furthermore, as far as I can tell, none of the above allow you to create the references unless the nodes already exist.
Creating 0-n other entities as part of the initial creation/form flow of a parent entity, and handling that correctly in terms of what data to store where and what to do in case of validation errors down the line, is the tricky part.
How about taxonomy? You could have a term for the album and each track node for the album adds the term.
-- Earnie -- https://sites.google.com/site/earnieboyd
Organic Group? We deal with a similar issue with community media. Producers have a Project/Series which contains multiple Shows/Episodes. Most stations organic groups to associate the Shows to the Project... which has the added bonus of allowing multiple users permission to update the Project as well as provide the relation for other content types as well (like the taxonomy suggestion). We require users to submit Shows individually because there is a lot of additional metadata for the Show. To save time, we included an option in cm_project to set the Project's value as the default for any field shared between the two types. Seems like if would be easy enough to add form fields to add X number of track nodes when the Album node is created using the OG to establish the relation. - Kevin On Tue, Mar 13, 2012 at 8:22 AM, Karen Stevenson <karen@elderweb.com> wrote:
One way to solve this in D7 is to use either a combination of Node Reference and Node Reference URL or Entity Reference and Entity Reference Prepopulate. Node Reference URL and Entity Reference Prepopulate are alternative widgets for those fields that let you set a value in the url. They also create an 'Add new ...' link on the referring entity that will go to the url to add a new node, set the value by reference to the source node, and then return you to the place you started.
That won't make it possible to create multiple tracks at once, but it does let you create the album first, then click on an 'Add new track' link on the album to add tracks to it. The technique for doing this in D6 is described in http://www.lullabot.com/articles/photo-galleries-views-attach and used by http://drupal.org/project/views_gallery. The same technique works in D7 using either of the above combinations.
Karen
On Thu, Mar 1, 2012 at 12:40 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
On Thu, Mar 1, 2012 at 12:53 PM, Daniel F. Kudwien wrote:
Am 01.03.2012 17:19, schrieb Karl Giesing:
Furthermore, we also need the ability to add Track nodes as we are creating an Album node - that is, we need the ability to create multiple nodes, and their references, all from the single form used to create an album. What should NOT happen is that the user has to create each track individually before they create an album that has those tracks - this is a workflow nightmare. (And it's currently how Pushtape works.)
There are currently three D7 modules used to create node references: References, Entity Reference, and Relation. References is the only one not currently in beta - and it's being depricated in favor of one of the other two. Furthermore, as far as I can tell, none of the above allow you to create the references unless the nodes already exist.
Creating 0-n other entities as part of the initial creation/form flow of a parent entity, and handling that correctly in terms of what data to store where and what to do in case of validation errors down the line, is the tricky part.
How about taxonomy? You could have a term for the album and each track node for the album adds the term.
-- Earnie -- https://sites.google.com/site/earnieboyd
participants (6)
-
Daniel F. Kudwien -
Earnie Boyd -
Karen Stevenson -
Karl Giesing -
Kevin Reynen -
Michael Favia