Hi Matthias, Matthias N. wrote: > Hi developers, > > the form system along with the admin generator is really a major > problem. It doesn't make any sense to work on enhancements (sf 1.3) as > long as people are not able to use all of the current features. There > are some people complaining about missing features in the form system. > There are blog posts out there, for example [1] trying to offer > solutions. I think two things play a role in this context: > > 1. Some things really are missing or can (must) be improved to help > solving a lot of problems. > 2. Some things only seem to be not or bad supported -- but they > probably are simply just not documented. > > I'll try to explain some problems. > > One of the most discussed problems seems to be the lack of support for > plain fields (display the value instead of an input field) in the > admin generator (or rather in the form system). There are workarounds > for this but it would be nice to have a solution. I think there are > two possible concepts: Either use different widget classes for > normal / plain -- or use an additional render method, for example > "renderPlain()".
There is no such thing as a plain field. It does not make any sense to me. The form system is about form fields. So, we manipulate form widgets. The power of the form system is that you can display your form the way you want by using the form API (see http://www.symfony-project.org/forms/1_2/en/03-Forms-for-web-Designers): $form['subject']->renderLabel() $form['subject']->renderError() $form['subject'] /// and so on So, if you want to display something, like a property of the object related to the form, it is quite easily to insert wherever you need it code like this: <?php echo $form->getObject()->getFoo() ?> Am I missing something here? > There is often a need to change things depending on > authentication or credentials so it would also make sense to provide > better support for work with the sfUser object. For example sometimes > you want to allow editing a field only if the user has a certain > credential or you want to not display it when a credential is missing. > One problem here is that there must also be a solid concept for the > validators as it can easily lead to security wholes when you only > "hide" a field but don't prevent the value from being submitted. I think we have very strong support for this kind of things. So, a form need to do things, based on a User model object? Pass the User object to the form constructor and do you stuff in the configure/doUpdate/whatever method of the form: class SomeForm extends sfForm { public function __construct($defaults = array(), $options = array(), $CSRFSecret = null) { if (!isset($options['user']) { throw new InvalidArgumentException('You must pass a user options for this form to work.'); } } public function configure() { if ($user->hasCredential('admin') { // add some widgets, change validators, ... } } } That's strong, because the same logic will be used for displaying AND validating the form. > > Another thing is, it would be nice if one could reuse "logical field > definition" (combination of widget and validator) for example for > things like email, date, or names which are very common and used very > often. I don't know but maybe the sfFormField can be extended to also > include a validator? or would it make sense to use mergeForm() for > such things? (lack of documentation) I like the decoupling between the validation and the widget because it means you can change the way things are displaying for the same semantic field (validation). That said, I'm also aware that this is sometime quite verbose, and we are working on providing a simpler API for common usage. > > Also a problem is the formatter stuff. It looks ugly but maybe it's > also only a problem of missing documentation? There must be a good way > to create "form themes" to render forms using a single echo line where > ever possible. Maybe the form rendering can be extended to use a > generator with several templates? And maybe it would also be useful to > configure the formatters on a class base so it would be possible to > configure this on a central place (view.yml?) I think the documentation is really clear on this specific subject: the echo $form statement is ONLY for prototyping. I'm convinced that most of the time, you need to take care of the form display by hand (field by field) to make your form ergonomic and usable. Also, it is the responsibility of the template to take care of the display logic. And I think this clears up a lot of things. Lots of people want to use the echo $form statement, whereas I think it's just a way to get started faster. > > Next thing is a simple question: How can I unset a form field > depending on whether the value of a field is empty or not? In this case, you want to disable the validation based on the value of a field, right? > > And the last one is a feature request: There should be a way to attach > arbitrary elements to form fields, so one can have an additional help > information or other stuff you need to display along with the fields > or the labels. Same things as before as I suppose you are talking again about the echo $form statement. On a side note, I want to add that I'm working on a system to make the echo $form more flexible, but when I read such emails, I think I will regret it as people will want to add more and more stuff in there. Last but not the least, keep in mind that everything is open to the discussion. So, if you want to make things better, I would be more than happy to help you contribute back to symfony. Fabien > > Please, don't click the delete button, instead hear the crys ;-) > > regards, > Matthias > > [1] http://webmozarts.com/2009/04/12/improving-the-forms/ > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
