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"
$this->unsetOnEmpty('my_field', array('unless_credentials' => array
('superadmin')));
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-
project.com> wrote:
> 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
> (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 ;-)
>
> > 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
-~----------~----~----~----~------~----~------~--~---
