[development] Node reference in core?

[Daniel F. Kudwien]

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