Hi,
I''ve just started to try Symfony 2 so maybe some of the items I would like
to see on the form component are already implemented. If that's the case, I
apologize:
- A way to render all errors in a form, including global, fields and
embedded ones (I know that each field has its own way to render its error,
but it would be nice to have a simple way to render all the errors of a
form, with embedded ones too). Maybe "renderErrors( $includeEmbeddedErrors =
true, $includeGlobalErrors = true )", or something like that.
- I agree for the readonly widget idea. But not just a readonly field in the
sense a user cannot type a new value (which in some custom widgets would be
not that easy as adding a readonly attribute). I mean a field that, even if
you submit the form (and override the client side restriction) the form
doesn't change its value either on the server side. You could show just the
value to the user, but having a way to just mark a field as "readonly" with
an option would be nice, and reusable. You wouldn't have to modify the view
and, in some cases, it would be impossible or not so user friendly to just
show the value. For example, a widget to select the latitude and longitude
of a place with Google Maps. You could just show the numeric values, but
showing the real widget with the map and preventing the user to modify its
value even if it changes it and submit its a lot better.
- +1 for the multi-step form feature
- This one I'm not sure if it's already developed. I saw a "group field"
feature but I don't know if it's what I mean here (i didn't use that feature
yet). What I was thinking is on a simple way to group fields like this:
$form->addGroup( 'personal_information', array( 'firstname', 'lastname',
'address' ) ); // First argument just to name the group. Second
argument an array with fieldnames that are included in the group
$form->addGroup( 'user_account', array( 'username', 'password',
'password_repeat' ) );
Then in the view you'd have a simple way to separate fields logically, like
this:
<!-- In my view -->
<?php foreach ( $form->getGroups() as $group ): ?>
<div class="tab">
<div class="title"><?php echo $group->getName() ?></div>
<div class="fields">
<?php foreach ( $group as $field ): ?>
<!-- Render field -->
<?php endforeach; ?>
</div>
</div>
</div>
<?php endforeach; ?>
Again, this could be done by hand now, but having a way like this would be
easier and cleaner.
My 2 cents. Again, if anything of these items are already included, I
apologize for adding them here.
Best regards.
On Thu, Oct 7, 2010 at 2:08 PM, jaime <[email protected]> wrote:
> > > 1. A readonly widget (for displaying non-editable values)
> >
> > What's the point of that? Is that not the same as echoing the value in
> > your template?
> >
>
> For Symfony 1.4 I have developed some ReadOnly widgets, but with an
> extra functionality.
>
> I include the option "credential", in which, so only if the user has
> the credentials can modify the field, if he don't, it will be a
> ReadOnly field.
>
> For me it's useful when different people interact with the same form,
> I don't know if for others it might by useful or not.
>
> And there is something about the feature that Daniel talk?
> >the ability to break a form into multiple pages/parts (checkout process in
> a shop, an upload process of an asset that requires multiple steps)
>
> Thanks for all
>
> On Oct 7, 10:25 am, Bernhard Schussek <[email protected]> wrote:
> > Hi everyone,
> >
> > First of all, sorry for the long silence.
> >
> > Second of all, thank you all for the feedback. Fabien is right, we
> > need people to test the Form framework thoroughly and provide
> > feedback.
> >
> > I will comment on some of the above-mentioned points:
> >
> > > 1. A readonly widget (for displaying non-editable values)
> >
> > What's the point of that? Is that not the same as echoing the value in
> > your template?
> >
> > > Embedded forms with dynamic "add new" and "remove" which don't
> >
> > require loads of manual boiler plate code to get working.
> >
> > This does already exists and is called CollectionField. It enables you
> > to dynamically enter collections of values (like arrays, Doctrine
> > collections etc.) - these values can of course be composite values
> > like arrays, objects etc.
> >
> > CollectionField is also designed to be supported by JS, though there
> > currently is no example of that AFAIK.
> >
> > > 2. the ability to keep an already uploaded file even if some other
> validators fail (this is tricky and always requires loads of code even if
> there are plugins for that)
> >
> > This is planned and I already developed a prototype for that.
> >
> > > Dynamic, dynamic, dynamic. Take the drop-down list with the label "How
> >
> > did you hear about us?", with options "Internet", "Radio", "Other". If
> > other is selected, a text input is made visible -- and should be
> > validated - but only when "Other" is selected. Currently doable? Yes.
> > Straightforward? No.
> >
> > There also exists a prototype for that. The question is how much JS we
> > will want to provide with Symfony2.
> >
> > > Changing the value of a field after a bind.
> >
> > Why? This violates the workflow of the field.
> >
> > > Extensibility. Extending sfFormField, for instance, is almost
> >
> > impossible because the name of the class is hard coded on sfForm and
> > sfFormWidgetSchema.
> >
> > Solved.
> >
> > > Currently there's no easy way to do a $form->getObject() on an
> >
> > embedded form
> >
> > Solved.
> >
> > > Only shortcoming i have is i cant attach constraints to to fields
> directly from the form it self.
> >
> > Possible by adding a constraint on the getData() method of the field.
> > Look at the validation.xml bundled with the Form component for an
> > example.
> >
> > Bernhard
>
> --
> 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]<symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
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
