Hey Ryan, Thanks for the exhaustive feedback! It's much appreciated.
2011/4/22 ryan weaver <[email protected]>: > I'm not sure about having the "required" option defaulting to true. My fear > is that developers - using non HTML5 browsers - will unknowingly have a > bunch of required fields. I think the developer should have to turn this on > manually. Also, in the current state, is required guessed from validation? Currently, "required" is only guessed when the field type is guessed as well. I want to change this so that "required" is always guessed and false if unguessable. The problem is that we then always need the data class. Not sure yet how to continue here. > * Is it possible to "embed" another form type without creating a form type > class? Yes.[1] $builder->add( $builder->create('author', 'form') ->add('firstName', 'text') ->add('lastName', 'text') ); > * Is it only possible to set a form theme (in an actual template) in Twig? I > don't see a way in PHP - I'm guessing you can still override things globally > (still needs to be doc'ed in a cookbook) Right now yes. I haven't looked at how this was possible with the PHP templating yet. > * On the collection field, modifable=true seems to be what's necessary to > output the $$name$$ field, but it doesn't actually seem to bind to the > objects unless modifiable=false. I don't know exactly what you mean, but I'll try to give an example. $builder->add('tags', 'collection', array( 'type' => new TagType(), )); With this code you can edit a to-many relation "tags". Each tag will be modifiable through a TagType subform. You are _not_ allowed to add or remove tags. $builder->add('tags', 'collection', array( 'type' => new TagType(), 'modifiable' => true, )); In this case, you can also legally add or remove rows (should we split the option to "allow_add" and "allow_delete"?). You will have the "$$name$$" prototype which you can clone using javascript when new rows are needed. > * What is the "FormType" used for? In the AcmePizza, you extend > AbstractType, whose parent is FormType. So, what's the difference between > FormType and AbstractType? Just a little pointer here will go a long way AbstractType implements FormTypeInterface, it does not extend FormType. FormType extends AbstractType. The type "form" is a child type of "field" and adds functionality that is typically needed for form instances: * data binding to objects * error_bubbling true by default * form is multipart if any child is multipart > * Is it intentional that the "preferred_choices" in the ChoiceType does not > work when expanded=true? Not intentional, but known. How should we render an expanded field with preferred choices? > * For the ChoiceType, you have to set required=false to get an "empty" > option at the top of your select field. That seems wrong - I can have a > required select menu, but I don't want to auto-select the first option for > the user. I think these should be separated - and driven entirely by the > presence/absence of the user passing in an "empty_value" option to the form > helper Ok. In this case I would automatically set "empty_value" to "" when "required" is false and no explicit "empty_value" is given. Is that a solution? > * What's the point of the "value" option for a checkbox? It always resolves > to true/false regardless of the value (which is correct). Is the value > option necessary for when other fields use the checkbox type (e.g. the > choice type) This is a leftover from symfony1 and currently doesn't work. I think we can safely remove it until we have a use case for it. > * The timezone options display kinda sucks - I'd rather see (GMT+7) > America/Chicago or something similar. Is this possible or is there more to > the problem? We are relying on PHP's timezone list here (and we shouldn't change that). So we can't really change the amount of timezones, only how they are displayed. Improvement suggestions? PR? > * The "integer" type on on the percent type seems strange. It means that I > can't store a "55.5" value on my object and use it - it's changes to 56 when > output to the user. And when the user submits "55.5", the pure decimal value > sticks to the object Have you tried setting the "precision" option to 1 or 2? > * The "%" signin the percent type template should perhaps be toggleable Why? > * What is the use-case for the "divisor" option in the money type? Money is usually either stored as float of the basic currency (dollars, euros etc.) or as integer of the smallest currency unit (cents etc.) because floats have the problem of storing "non-existent" money (how can you pay out 0.004 dollars?). Setting the divisor to 100 allows you to store money as cents, for example. Not all currencies use 100 as a divisor, which is why this is a configurable value. > * The language codes are a mixture of 2-letter and 3-letter - what standard > is that? Reading wikipedea (http://en.wikipedia.org/wiki/ISO_639), the > standards were either 2 letters or 3 letters, but the languages output are a > mix? I believe this comes straight out of PHP itself - I'm just wondering > what the proper way to describe it is We are relying on ICU data here. http://userguide.icu-project.org/locale#TOC-Language-code > * The file type is either broken, or I'm confused :). First, it seems to > force the value of the given field to be an absolute path to a real file > (e.g. can't just be foo.jpg), else it throws an exception. The form framework never knows when you actually persist the uploaded data, so it can't move the files to their end location. Instead, it stores the files in a temporary location and hands you the absolute path to that temporary path (if you change the option "type" to "object", you'll get a File object). Setters and getters for files should always accept/return absolute paths. If you change the "file" option "type" to "object", they should accept/return Symfony\Component\HttpFoundation\File\File objects. public function setFile(File $file) { $this->file = $file; } public function getFile() { return $this->file; } You should move the file before you actually persist your data. You can do that in a PrePersist hook. /** @orm:PrePersist */ public function prePersist() { if ($this->file) { $this->file->move('/final/location'); } } @PrePersist and @PostLoad are also the right places to turn absolute paths into relative paths and back. Cheers, Bernhard [1] Depends on commits in https://github.com/symfony/symfony/pull/640 -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
