[symfony-devs] Re: i18n - the new form widgets - and labels!
Hi again all, For those interested, here's a really really simple demo of the new forms in action. http://www2.pookey.co.uk/frontend_dev.php/ This page is going to change over time - in the short term is will slowly grow with more interesting form examples whilst I play - in the long term, it will most likely break, and then vanish ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony developers group. To post to this group, send email to symfony-devs@googlegroups.com 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 -~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Ian P. Christian wrote:
class LoginForm extends sfForm
{
public function bind($vars)
{
$request = sfContext::getInstance()-getRequest();
if ($request-hasParameter(self::$CSRFFieldName))
{
$vars[self::$CSRFFieldName] =
$request-getParameter(self::$CSRFFieldName);
}
parent::bind($vars);
}
}
I'm talking to myself here - I'm hoping though that someone else might
want to come into the conversation ;)
This thing here going on with bind came from notjosh's blog [1]. It
seems like an odd think to have to do - and I'm pretty sure we're
missing something here... is this really the 'correct' way of doing it?
Regards,
[1]
http://notjosh.com/blog/archives/47-Symfony-1.1-Forms-and-Validation.html
--
Ian P. Christian ~ http://pookey.co.uk
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
symfony developers group.
To post to this group, send email to symfony-devs@googlegroups.com
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
-~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Hi Ian,
As the form framework is new, some comments:
Don't override the bind() method like this. One of the property of the
new framework is a very clear separation between 3 layers:
- sfForm : Controller
- sfValidator* : Model
- sfWidget* : View
So, the binding belongs to the Controller, not the model as you use the
request:
class UserActions extends sfActions
{
function executeLogin($request)
{
$this-form = new LoginForm();
if ($request-isMethod('post'))
{
$this-form-bind($request-getParameter('login'));
if ($this-form-isValid())
{
// do something useful with $this-form-getValues()
}
}
}
}
As far as internationalization is concerned, the best way to handle it
is in the view. You won't be able to just use echo $form, but it's
pretty simple to handle. See this slide for some examples:
http://www.aide-de-camp.org/talk/7/international-php-conference-2007?position=77
HTH,
Fabien
--
Fabien Potencier
Sensio CEO - symfony lead developer
http://www.sensiolabs.com/
http://www.symfony-project.com/
Sensio Labs
Tél: +33 1 40 99 80 80
Ian P. Christian wrote:
Hi all,
Because the new form system is new, I'm going to paste my whole form,
partly for example..
class LoginForm extends sfForm
{
public function configure()
{
$schema = new sfWidgetFormSchema(array(
'login_username' = new sfWidgetFormInput(),
'login_password' = new sfWidgetFormInputPassword(),
));
$schema-setLabel('login_username', 'Username');
$schema-setLabel('login_password', 'Password');
$this-setWidgetSchema($schema);
$this-setValidatorSchema(
new sfValidatorSchema(array(
'login_username' = new sfValidatorString(),
'login_password' = new sfValidatorString(),
)));
}
public function bind($vars)
{
$request = sfContext::getInstance()-getRequest();
if ($request-hasParameter(self::$CSRFFieldName))
{
$vars[self::$CSRFFieldName] =
$request-getParameter(self::$CSRFFieldName);
}
parent::bind($vars);
}
}
Here you can see i'm creating a simple form, 2 fields, both with defined
labels.
However, the labels for these forms aren't printed though the __()
function for i18n to take place.
Not sure if this is a bug, a feature I'm missing, or somethign the form
widgets just simply shouldn't be doing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
symfony developers group.
To post to this group, send email to symfony-devs@googlegroups.com
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
-~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
This is probably not going to help you but I would like to know where can I
find more documentation about the new stuff in Symfony.
The PhpDoc is not very explicit and I dont want to spend an entire day
taking a look at the code to understand.
*So here is my question*:
Do you have more links like the notjosh.com blog to explain the new features
in symfony (new pake tasks, cocoa event system, form, widgets etc.) ?
Thanks
Sincerely
-Hassen Ben Tanfous
On Dec 12, 2007 9:50 AM, Ian P. Christian [EMAIL PROTECTED] wrote:
Ian P. Christian wrote:
class LoginForm extends sfForm
{
public function bind($vars)
{
$request = sfContext::getInstance()-getRequest();
if ($request-hasParameter(self::$CSRFFieldName))
{
$vars[self::$CSRFFieldName] =
$request-getParameter(self::$CSRFFieldName);
}
parent::bind($vars);
}
}
I'm talking to myself here - I'm hoping though that someone else might
want to come into the conversation ;)
This thing here going on with bind came from notjosh's blog [1]. It
seems like an odd think to have to do - and I'm pretty sure we're
missing something here... is this really the 'correct' way of doing it?
Regards,
[1]
http://notjosh.com/blog/archives/47-Symfony-1.1-Forms-and-Validation.html
--
Ian P. Christian ~ http://pookey.co.uk
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
symfony developers group.
To post to this group, send email to symfony-devs@googlegroups.com
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
-~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Hassen Ben Tanfous wrote: *So here is my question*: Do you have more links like the notjosh.com http://notjosh.com blog to explain the new features in symfony (new pake tasks, cocoa event system, form, widgets etc.) ? Not yet - once I have a few more examples, I'm going to put them somewhere. :) -- Ian P. Christian ~ http://pookey.co.uk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony developers group. To post to this group, send email to symfony-devs@googlegroups.com 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 -~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Fabien POTENCIER wrote: Hi Ian, As the form framework is new, some comments: Don't override the bind() method like this. One of the property of the new framework is a very clear separation between 3 layers: I am doing that in my action - but the main issue is that unless I bind the CSRF field manually, it will error. IMO, that logic should not be in the action - that's why I've moved it to my bind method like that (which might also be wrong - but it seems less wrong ;) ) As far as internationalization is concerned, the best way to handle it is in the view. You won't be able to just use echo $form, but it's pretty simple to handle. See this slide for some examples: http://www.aide-de-camp.org/talk/7/international-php-conference-2007?position=77 Doing this kinda ruins part of the 'fun' in the new form handling. It's really nice that I can just add a bit of code in my form code, and have the template 'magically' show this new field. If I do as suggested there, I have to go back to writing lots of HTML again. I've notice there's some Decorator classes in amongst the form stuff, although I don't yet know what it's for - maybe some code can be written to handle this... i18n is handles so well in other parts of the framework, it would be a shame to see it almost forgotten in this respect... I'm happy enough to put my i18n logic in my form itself like I have - but that's not strictly the right place for it. It's preferable then having to maintain HTML templates for my forms at the moment though -- Ian P. Christian ~ http://pookey.co.uk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony developers group. To post to this group, send email to symfony-devs@googlegroups.com 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 -~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Ian P. Christian wrote:
Maybe you can already- but the way a form element is output should be
modifiable pragmatically, not just by using a manual method in the
template. For example, if you want errors to appear below a input,
rather then above, and you want to use table-less form layers - you'd
specify a different formatter class and it would just work. But.. I
should RTFS to find out of this is already possible ;)
worked it out, for those interested...
sfWidgetFormSchema::addFormFormatter($name, sfWidgetFormSchemaFormatter
$formatter)
then you set it...
$schema-setFormFormatterName('list');
2 are build in, list and table.
you can write your own as long as they extend sfWidgetFormSchemaFormatter
more to come soon :)
--
Ian P. Christian ~ http://pookey.co.uk
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
symfony developers group.
To post to this group, send email to symfony-devs@googlegroups.com
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
-~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Oops, a small typo on the first line:
$this-form = new LoginForm(array('login_username' =
$request-getParameter('username')));
--
Fabien Potencier
Sensio CEO - symfony lead developer
http://www.sensiolabs.com/
http://www.symfony-project.com/
Sensio Labs
Tél: +33 1 40 99 80 80
Fabien POTENCIER wrote:
Here your example modified to work out of the box:
class authActions extends sfActions
{
public function executeLogin($request)
{
// allows a username to be passed in the URL as a GET param.
$this-form = new LoginForm(array('login_username' = $username));
// if the form was posted...
if ($request-isMethod('post'))
{
$this-form-bind($request-getParameter('login'));
if ($this-form-isValid())
{
die('merp');
}
}
}
}
and modify your form class like this:
class LoginForm extends sfForm
{
public function configure()
{
// ... your stuff here
$this-widgetSchema-setNameFormat('login[%s]');
}
}
So, every field is now in an array (and the CSRF field is also there).
As an added bonus, the action does not have field name harcoded.
Fabien
--
Fabien Potencier
Sensio CEO - symfony lead developer
http://www.sensiolabs.com/
http://www.symfony-project.com/
Sensio Labs
Tél: +33 1 40 99 80 80
Ian P. Christian wrote:
Ian P. Christian wrote:
Fabien POTENCIER wrote:
Hi Ian,
As the form framework is new, some comments:
Don't override the bind() method like this. One of the property of the
new framework is a very clear separation between 3 layers:
I am doing that in my action - but the main issue is that unless I bind
Sorry, should have been a little more specific here..
My action consists of this:
class authActions extends sfActions
{
public function executeLogin($request)
{
$form = new LoginForm();
// allows a username to be passed in the URL as a GET param.
if ($username = $request-getParameter('login_username'))
{
$form-setDefaults( array( 'login_username' = $username));
}
// if the form was posted...
if ($request-isMethod('post'))
{
$form-bind(
array(
'login_username' = $request-getParameter('login_username'),
'login_password' = $request-getParameter('login_password'),
));
if ($form-isValid())
{
die('merp');
}
}
$this-form = $form;
}
}
But, as that is the form will error becuase of the CSRF field not being
bound.
As such, I moved that logic into the LoginForm class, as notjosh
suggseted doing in his blog (also stating that that might well not be
the right way).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
symfony developers group.
To post to this group, send email to symfony-devs@googlegroups.com
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
-~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Here your example modified to work out of the box:
class authActions extends sfActions
{
public function executeLogin($request)
{
// allows a username to be passed in the URL as a GET param.
$this-form = new LoginForm(array('login_username' = $username));
// if the form was posted...
if ($request-isMethod('post'))
{
$this-form-bind($request-getParameter('login'));
if ($this-form-isValid())
{
die('merp');
}
}
}
}
and modify your form class like this:
class LoginForm extends sfForm
{
public function configure()
{
// ... your stuff here
$this-widgetSchema-setNameFormat('login[%s]');
}
}
So, every field is now in an array (and the CSRF field is also there).
As an added bonus, the action does not have field name harcoded.
Fabien
--
Fabien Potencier
Sensio CEO - symfony lead developer
http://www.sensiolabs.com/
http://www.symfony-project.com/
Sensio Labs
Tél: +33 1 40 99 80 80
Ian P. Christian wrote:
Ian P. Christian wrote:
Fabien POTENCIER wrote:
Hi Ian,
As the form framework is new, some comments:
Don't override the bind() method like this. One of the property of the
new framework is a very clear separation between 3 layers:
I am doing that in my action - but the main issue is that unless I bind
Sorry, should have been a little more specific here..
My action consists of this:
class authActions extends sfActions
{
public function executeLogin($request)
{
$form = new LoginForm();
// allows a username to be passed in the URL as a GET param.
if ($username = $request-getParameter('login_username'))
{
$form-setDefaults( array( 'login_username' = $username));
}
// if the form was posted...
if ($request-isMethod('post'))
{
$form-bind(
array(
'login_username' = $request-getParameter('login_username'),
'login_password' = $request-getParameter('login_password'),
));
if ($form-isValid())
{
die('merp');
}
}
$this-form = $form;
}
}
But, as that is the form will error becuase of the CSRF field not being
bound.
As such, I moved that logic into the LoginForm class, as notjosh
suggseted doing in his blog (also stating that that might well not be
the right way).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
symfony developers group.
To post to this group, send email to symfony-devs@googlegroups.com
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
-~--~~~~--~~--~--~---
[symfony-devs] Re: i18n - the new form widgets - and labels!
Fabien POTENCIER wrote: So, every field is now in an array (and the CSRF field is also there). As an added bonus, the action does not have field name harcoded. Ah - that makes a lot of sense - thanks for pointing that out. Any feedback on the i18n? I've just realised there's going to be other cases where you'd want i18n to potentially 'just work' when using forms - and that's radio and select options. Maybe I just need to look at the decorator classes, and I'll be able to write my own class to handle outputting widgets... Maybe you can already- but the way a form element is output should be modifiable pragmatically, not just by using a manual method in the template. For example, if you want errors to appear below a input, rather then above, and you want to use table-less form layers - you'd specify a different formatter class and it would just work. But.. I should RTFS to find out of this is already possible ;) Thanks, -- Ian P. Christian ~ http://pookey.co.uk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony developers group. To post to this group, send email to symfony-devs@googlegroups.com 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 -~--~~~~--~~--~--~---
