Developers

License

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished
to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

bugfix: newFormClassArgs option didn't work the way it was described in the README (option was automatically wrapped in an array) => please read the UPGRADE GUIDE that is packaged with this plugin! :)

bugfix: when using the multipleNewForms and newFormsInitialCount options it was indeed creating multiple forms to add related objects but it also did that for ONE-to-ONE relations ;-)

bugfix: newRelationButtonLabel did not work at all :(

new feature: customEmbeddedFormLabelMethod option is a method that is called on each existing related object (not the containing form!) so you can customize the form label that is shown in front of each existing embedded form. This option is new since version 1.4.0.

bugfix: The plugin finally works with embedded forms that have checkboxes, radio buttons and/or file upload fields (what's especially interesting is the use of sfWidgetFormInputFileEditable)!

I also finally added unit tests that should cover at least 80% of the functionality. Because I don't have that much time I used the symfony Core's unit tests as a starting point so they actually live inside the lib/vendor/symfony directory of one of my projects. If there's someone who knows how to set up plugin-internal unit tests (with a SQlite database for testing persistence stuff), I'd be glad to provide these unit tests. :) Help's always welcome!

Release 1.3.4 - 05/05/2010

Yikes! I forgot to add the new files that were introduced in version 1.3 and up. I was also naive enough to think PEAR would automatically include those. :(

Release 1.3.1 - 28/04/2010

Bugfix: Embedded i18n forms could not be saved; thanks for the bug info to SÃ¡ri MÃ¡rton!
Trivial: removed some debug logger calls (they were commented out anyway)

Release 1.3.0 - 27/04/2010

Thanks to koto (on GitHub) the whole workhorse class has been refactored into more manageable parts! :)

in addition to this koto has been kind enough to add the ability to add multiple new objects in one go, which he also documented in the README

add to that the ability to add new forms dynamically with JavaScript (think of rendering a partial with the "Add form" inside via AJAX) and you'll know that this rightfully deserved a minor version number increase!

Thank you koto!

Release 1.2.4 - 31/03/2010

added ability to display the empty form to add new related objects below the already existing related objects

documented new option in the README
Because of an error, there was no "real" release version 1.2.3, there is a tag for it in the Subversion repository but nothing more. :)

Release 1.2.2 - 30/03/2010

cleaned up TODO

no code changes!
Because of an error, there was no "real" release version 1.2.1, there is a tag for it in the Subversion repository but nothing more. :)

Release 1.2.0 - 16/02/2010

fixed: no useless "add new" forms anymore when the embedded relation is one-to-one and a related object exists :)

removed all debug code calls

improved code documentation

Release 1.1.0 - 11/02/2010

fixed a few bugs, so passing options to the embedded forms actually works.

not necessary anymore to create a dedicated form to add the delete checkboxes, this is now handled by symfony's event dispatcher and the form.post_configure event. :)

Be careful if you're using the new useFields method as this would unset the embedded forms again!

Also, please be aware that the embedRelations method does not follow the embedRelation method in that you cannot define an alias to use for the relation, you need to specify the relation key you used in the schema, which is, in this case, Repositories!

Each array defines one embedded relation and you can define a handful of options.

Options explained

Only the first option is required, the rest can be guessed using the schema and Doctrine. :)

considerNewFormEmptyFields (the only required option, array): trouble starts when the user does not want to add a new related object but only wants to edit the main object's properties.
As the embedded forms are validated, an error is thrown if one of the embedded form's field's is required.
To remedy that you'll have to add all the fields to this array and if all of these are empty (read: only works for text fields for now), the empty form is dropped and no empty object is saved to the database (or validation errors thrown).

noNewForm (boolean, not required): if false, no empty form to add a new related object is embedded so you can only manage existing related objects.

newFormLabel (string, not required): the label that is shown for the new embedded form. If the form is used in the admin generator, label definitions in the generator.yml take precedence over this option:

The key to use in the fields array above is 'new_relationName' ('new_Repositories' in this case, see the example above).

newFormClass (string, not required): the form class to use for the empty form

newFormClassArgs (array of arrays, not required): form class options to pass to the empty form class on instantiation.
Explanation for why it's an array of arrays: the way embedRelation works uses reflection to construct the right form objects. Now, the first argument is always the model object, the second is the form option array and the third is the local CSRF secret for the form.
You don't need to worry about the first one (the model object) because this is always null for the new form. If you want to pass some more options to the related form object (like the user object to avoid using sfContext) just follow the example above.
I could have changed this (because I implemented it) but I don't want to confuse the developer because when you look at the option formClassArgs below it's the same mechanism and I can't change that short of copying the whole embedRelation method over to the ahBaseFormDoctrine class, thereby losing the chance to automatically get upstream bugfixes. :)

formClass (string, not required): the form class to use for the existing related objects.

formClassArgs (array of arrays, not required): form class options to pass to the existing related objects form class on instantiation
As of version 1.1 it's not necessary to create a separate form class for the existing related forms to display the delete checkbox.
This is now handled by the symfony event dispatcher. If you want to change how that works you can always copy over this method and change it to suit your needs:

This works because we're calling the plugin's event handler method.
This either returns the form so it added the delete checkbox and the validator and you can act on that, or it returns false and you don't act on that. Neat and tidy. :)

displayEmptyRelations (boolean, not required): set this to true (false is the default) if you want to check for existing related objects yourself. This can be done in the form template and is useful if you want to let the user know that 'There are no related repositories yet.'. The default is just not displaying anything in this case, which works for me. :)

Questions, bugs, feature requests?

I can be reached via e-mail: info@asapdesign.de

If you find bugs, have questions and/or feature requests, you can post to the symfony-user mailing list,
of which I am an avid follower. :)