[development] Changing button #name?

Lee Rowlands leerowlands at rowlands-bcs.com
Thu Jun 24 00:54:43 UTC 2010


Yes, sorry should have said this was in conjunction with previous comments
as well :-)

-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of Alex Bronstein
Sent: Thursday, 24 June 2010 10:52 AM
To: development at drupal.org
Subject: Re: [development] Changing button #name?

Hi Lee,

You're correct that $form_state['clicked_button'], if it is set 
correctly, contains lots of useful information, including #id, #parents, 
and #array_parents. The problem is anything based on 
$form_state['clicked_button'] requires that it be set to the button that 
was actually clicked, and that can only happen when no two buttons 
within a form contain identical #name and #value. If buttons have the 
same #name and different #value, all is ok. If buttons have different 
#name and the same #value, all is ok. But if two buttons have the same 
#name and the same #value, there is no way for the Form API or any 
server-side code to know which of the buttons was actually clicked, 
since clicking either button would send the exact same $_POST information.

Alex.

Lee Rowlands wrote:
> Hi Richard
> Are you using '#tree' => TRUE?
> If so, you can access $form_state['clicked_button']['parents'] which will
be
> an array of the keys of the parent elements. If each row in your table is
> built as follows:
> $form['rows'][$row_id]['field1'] = array(...),
> $form['rows'][$row_id]['field2'] = array(...) etc and you are rendering
this
> as a table using a theme function and element_children to determine the
> valid values of $row_id (is there any other way?) then your
> ['clicked_button']['parents'] will contain an array including the final op
> but also the 'parent' $row_id, this can tell you which button was pressed.
> Have a look at the quicktabs module for an example.
> HTH
> Lee Rowlands
>
> -----Original Message-----
> From: development-bounces at drupal.org
[mailto:development-bounces at drupal.org]
> On Behalf Of Richard Morse
> Sent: Thursday, 24 June 2010 2:03 AM
> To: development at drupal.org
> Subject: Re: [development] Changing button #name?
>
> On Jun 23, 2010, at 11:37 AM, Adam Gregory wrote:
>
>   
>> Actually all buttons in a Drupal form have the name "op" so that you can
>> easily determine which button was pressed in the submit function. i.e. if
>> ($op = 'blah) or switch ($op).
>>
>> If you are using the Drupal Ahah framework for this then your submit
>> function should handle it. But since all your buttons are titled Remove,
>> what you can do is use $form_state['clicked_button']['#id'] to determine
>> which button was clicked in your submit function. As #id is built of the
>> array key you give the element in the $form variable.
>>     
>
> I know that by default they are all named 'op'. This is my problem; I
cannot
> distinguish the buttons by their '#value', because it is always the same.
> I'm solving this by setting the '#name' to allow me to determine precisely
> which button was clicked. If I don't set '#name', then *regardless* of
which
> button I press, the 'clicked_button' structure in the $form_state
> corresponds to the last button of the same '#value' added to the form.
Part
> of the awkwardness here is that HTML doesn't allow you to display some
text
> in a button while having a different value.
>
> Ricky
>
>
> The information in this e-mail is intended only for the person to whom it
is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com 
> Version: 8.5.406 / Virus Database: 271.1.1/2686 - Release Date: 02/13/10
> 19:35:00
>
>   

Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.406 / Virus Database: 271.1.1/2686 - Release Date: 02/13/10
19:35:00



More information about the development mailing list