I don’t know if this has ever worked for me. I guess either it’s not well supported or I’ve just been doing it wrong since CakePHP 1.x
Figured I’d ask:
If I want to use the form helper to generate form elements on a create (“add”) action for associated models (not just immediately associated, but I’m talking separated by at least two or three degrees)… should I expect the helper will render the elements correctly based on field type in the database?
Because I only seem to be able to get them to render as text fields. I end up having to explicitly declare the input types I want to use for any given field.
Perhaps yet another symptom of something I’m doing wrong: I always end up having to manually assemble the associations in the controller after submittal and saving each individual model. It seems as if only immediately associated models get handled automagically.
Have you tried to first create the associations in the model tables and after that bake the view?
Cake’s bake method doesn’t seem to traverse more than one relationship during view generation.
This is a common scenario for me because I always find myself coding apps that require the user to define collections of things. As a result, I don’t like to present the user with a single-field “name of this list” form before redirecting to another controller to create each associated model (which, in turn, has many submodels).
Instead, I aim to present the user with a single page where they can dynamically add the first and second level subentities as much as they like, entering the data for each as needed… and then also entering a name for the primary entity… and then saving everything at once. This also prevents the case where the user saves a top level entity but never creates second and third level content for it.
To the user, it’s natural.
Another funny thing about this is that I can never really decide which of entities I should choose to focus my controller around. I’ve generally tried using the second one, just based on the idea that most of the fields being used in the form would be from that entity.
You’re right, it doesn’t. And the patch functions don’t (as I recall) go more than one level deep by default. But all of that is just code that you can change. I can assure you that saving down to multiple levels works just fine without having to do anything particularly fancy, just make sure your fields are named correctly and you pass the right options to patch.
I’m less sure about creating a new parent object as part of this process (e.g. creating an author from the “add book” page), because I don’t think I’ve done that. It might well work, but I can also see why it might not.
Yes, I believe I recall from my last project like this that I ended up having to create the parent entity in the controller, then obtaining entity id for it to use for creating each of the child entities.
Memory is a little hazy. I think I also had to use a foreach loop to handle the creation of each of those child entities… but I believe saveAll() did work for the children of the child entities.
I’m about to code a new project that depends on nested hierarchies of data that are supposed to present to the user as a single “thing”. So I was hoping to find out if maybe Cake might automate more of it for me than I was used to. I thought maybe I was making things harder on myself than they needed to be and that maybe I was missing out on some magical association methods.
If your form is for authors, you should certainly be able to have fields like
books.1.name, etc., then patch that all into a new author entity, and it will save everything at once.