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 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.
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)
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?)
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?
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.
Please, don't click the delete button, instead hear the crys ;-)
I completely understand your feelings, which is also why I blogged about this topic extensively. I would indeed like to hear Fabien's opinion about the points you raised, and also about my propositions. If any of these suggestions can be used to enhance the Forms Framework (version 2.0?), I would be more than willing to work on it.
On 6 Jul., 00:04, Bernhard Schussek <bschus...@gmail.com> wrote:
> Hi Matthias,
> I completely understand your feelings, which is also why I blogged
> about this topic extensively. I would indeed like to hear Fabien's
> opinion about the points you raised, and also about my propositions.
> If any of these suggestions can be used to enhance the Forms Framework
> (version 2.0?), I would be more than willing to work on it.
2.0? ;-)
The problem I have is that these things are not new, they are ages old
and I need a solution now as I have to create tons of admin modules
and forms during the next 2 months. So I guess the only way to go is
sit down and create my own form system and my own generator classes.
Otherwise I will never be able to finish anything.. :-(
I said "2.0" because the things we ask for cannot really achieved without breaking BC.
> The problem I have is that these things are not new, they are ages old > and I need a solution now as I have to create tons of admin modules > and forms during the next 2 months. So I guess the only way to go is > sit down and create my own form system and my own generator classes.
I doubt that much will change in short time, especially without Fabien joining into the discussion. But as I said, we can work on this together.
+1 for plain fields with permissions, I never found a tidy solution
for this, always had to hack the templates with if/else and then unset
the field in the class when required. nasty.
> I said "2.0" because the things we ask for cannot really achieved
> without breaking BC.
> > The problem I have is that these things are not new, they are ages old
> > and I need a solution now as I have to create tons of admin modules
> > and forms during the next 2 months. So I guess the only way to go is
> > sit down and create my own form system and my own generator classes.
> I doubt that much will change in short time, especially without Fabien
> joining into the discussion. But as I said, we can work on this
> together.
> +1 for plain fields with permissions, I never found a tidy solution
> for this, always had to hack the templates with if/else and then unset
> the field in the class when required. nasty.
>> I said "2.0" because the things we ask for cannot really achieved
>> without breaking BC.
>>> The problem I have is that these things are not new, they are ages
>>> old
>>> and I need a solution now as I have to create tons of admin modules
>>> and forms during the next 2 months. So I guess the only way to go is
>>> sit down and create my own form system and my own generator classes.
>> I doubt that much will change in short time, especially without
>> Fabien
>> joining into the discussion. But as I said, we can work on this
>> together.
As far as I know, the i18n:extract still doesn't extract strings for
translation inside of the form classes. This is a real limitation for
large projects with a lot of different languages.
David Juhasz
Software Engineer, Artefactual Systems Inc.
> 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.
As I am concerned I am very satisfied with the actual form system. The point
seems to be a global lack of documentation (missing chapters) ; actually me
and my team are, every day, looking to the core to work efficiently with the
sub framework.
Another point was the difficulty to deal with embed forms and not using the
global echo $form. I have to use this snippet :
http://www.blogs.uni-osnabrueck.de/rotapken/2009/03/13/symfony-merge-...
> > 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 ;-)
Fabien Potencier wrote: > 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?
Yes. Let's assume that "subject" can be read-only depending on some user level (as you wrote later). So we have to inject the user into the form class, check the user level and disable the form field (unset it or set sfvalidatorpass or whatever). This is what you also described and it's fine for me.
The problem comes now: we ALSO have to put the user level check into the template to display either the field ($form['subject']->render()) or $form->getObject->getSubject(). This is a fairly ugly redundancy, and it is error prone (imagine you change the user level check but forget to change it in the template too). It's also difficult because the subject should appear the same way the form field does (the same visual label). We either have to code this by hand (thus breaking the form formatter dependency) or use a "dummy" field - and this is where a text-output-only field screams at you "implement me, so you will have much less work!".
To summarize this: having read-only form fields removes redundancy and application process dependency from the templates. I want to call $form['subject']->render() and totally ignore if the field is a text input, a select or just a text output. It just shouldn't matter for the template. This also helps "Forms for web designers", because the designer shouldn't have to know about user levels and getObject()->getSubject().
(Good, reusable) Forms are NOT only a bunch of input fields (if you look at them beside simple stuff like CRUD interfaces). Forms should be a combination of input fields AND application logic AND text outputs and the form framework should honor this (as it does regarding to labels, error messages and help texts).
"Forms for web designers" is fine, but let's have more "forms for coders" first, because there's much more (hidden) work in there at the moment.
> Fabien Potencier wrote:
>> 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?
> Yes. Let's assume that "subject" can be read-only depending on some
> user
> level (as you wrote later). So we have to inject the user into the
> form
> class, check the user level and disable the form field (unset it or
> set
> sfvalidatorpass or whatever). This is what you also described and it's
> fine for me.
I think your DRY concerns are valid. I typically include this sort of
conditional logic in the form configure method, then simply check
whether a field isset() in the template. This is DRY, and works most
of the time for me.
That being said, what you're asking for is a widget class with a very
simple render method. Why don't you package this up as a plugin?
> The problem comes now: we ALSO have to put the user level check into
> the
> template to display either the field ($form['subject']->render()) or
> $form->getObject->getSubject(). This is a fairly ugly redundancy,
> and it
> is error prone (imagine you change the user level check but forget to
> change it in the template too).
> It's also difficult because the subject should appear the same way the
> form field does (the same visual label). We either have to code this
> by
> hand (thus breaking the form formatter dependency) or use a "dummy"
> field - and this is where a text-output-only field screams at you
> "implement me, so you will have much less work!".
> To summarize this: having read-only form fields removes redundancy and
> application process dependency from the templates. I want to call
> $form['subject']->render() and totally ignore if the field is a text
> input, a select or just a text output. It just shouldn't matter for
> the
> template. This also helps "Forms for web designers", because the
> designer shouldn't have to know about user levels and
> getObject()->getSubject().
I agree that the forms could be easier for web designers to work with.
I am working on a "view" panel for the symfony 1.3 web debug toolbar
that will provide information about the variables passed to a
response's templates and partials, including form objects. Please take
a look at this WIP when you have a moment; I'd appreciate any feedback.
> (Good, reusable) Forms are NOT only a bunch of input fields (if you
> look
> at them beside simple stuff like CRUD interfaces). Forms should be a
> combination of input fields AND application logic AND text outputs and
> the form framework should honor this (as it does regarding to labels,
> error messages and help texts).
> "Forms for web designers" is fine, but let's have more "forms for
> coders" first, because there's much more (hidden) work in there at the
> moment.
After some days of thinking I came to the conclusion that my most
important needs are
- support for plain fields (as I really need to "switch to plain mode"
depending on user credentials)
- simplify unsetting of fields on certain (missing) credentials
I found a nice solution and put it into the BaseDoctrineForm class.
For example I can now do this:
$this->setPlainOn('my_field', array('unless_credentials' => array
('edit_my_field')));
which changes the widget and "turns validation off"
which is simply much shorter than long if statements and saves me a
lot of lines
I use this in admin generator forms and I also began to extensively
modify the admin theme which is really more fun with the new admin
generator! But of course you need some time to find out what to change
where..
This thing about having one class to set widget and validator is an
interesting inspiration from Bernhard, but to be honest it is not that
important to me. I also don't like too much magic. It's more fun if
you know what's going on.
The $form problem.. Hm.. of course it's for prototyping. But I think
some more magic in this case would be nice.. Who says that form
prototypes should look ugly? ;-)
I started using a partial located in a plugin instead of "echo $form"
as this allows me to make the prototyping even nicer. By implementing
this as a plugin it's fun to reuse. Now I can do something like this
in my templates for nice prototyping: <?php include_partial('forms/
default', array('form' => $form)) ?>
Last but not least, I'm working very hard on contributing back. I was
very quiet during my "2,5 years of symfony" regarding plugins.
But I will begin to publish a library of 20+ coherent (business
relevant) plugins later this summer which will blow you away. ;-)
Regards,
Matthias
On 7 Jul., 08:32, Fabien Potencier <fabien.potenc...@symfony-
> > 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 (seehttp://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 ;-)
