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
