Re: php processing name vs. id field

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2 July 2010 15:01, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 2010-07-02 at 08:49 -0400, Bob McConnell wrote:
>
>> From: Ashley Sheridan
>>
>> > Not sure if my other email got through earlier. Replacing the name
>> > attribute on form fields with the id one is not feasible at all. They
>> > don't even behave the same. What would happen if you had two forms on
>> a
>> > page that both had an element with the same name? Using the name
>> > attribute, everything is fine, but not so if you were using the id
>> > instead.
>>
>> These conditions sound like a bugs to me. I can't imagine any reason why
>> different forms could have the same name or id. That applies to any set
>> of elements on a page. Each one must have a unique moniker, no matter
>> which attribute you use. Even the simple validations I use will complain
>> about your duplicates, as they should. Making them all unique also makes
>> it much simpler to use tools like Selenium or Silk Test to automate the
>> testing process.
>>
>> Looking at the HTML 4.01 references given earlier in this thread, I see
>> that id is now a core attribute, i.e. it is available for all but a
>> handful of tags, while name is only available for the tags where it is
>> explicitly included. So it still appears to me that id is the preferred
>> attribute, as it is more generally available.
>>
>> Bob McConnell
>>
>
>
> It's not a bug in the code. Imagine this scenario:
>
> <form name="product_filter">
>    <input type="submit" name="action" value="By Product Name"/>
>    <input type="submit" name="action" value="By Product ID"/>
> </form>
>
> A valid form with two input elements given the same name, which sends a
> different value to the server depending on which button was triggered.
> Seems valid enough to me. Only one value is ever sent, so why do I need
> to give them unique names and further complicate my server-side code?
>
> Imagine further that there is another form on the page containing the
> product listings, and each one has a delete button. Now we all know the
> folly of putting things like delete code into an <a> tag, so a button
> will do the job:
>
> <button type="submit" name="action" value="pid_1">Delete
> Product</button>
> <button type="submit" name="action" value="pid_2">Delete
> Product</button>
> <button type="submit" name="action" value="pid_3">Delete
> Product</button>
>
> Perfectly valid, and something that is done a lot on apps I've seen and
> built. Giving each a unique name just gets in the way, as you need to
> use some sort of loop and pattern matching on the server just to get the
> data you need.
>
> ID is not a substitute for name on form elements. The reason name is
> only available for a few elements is because it has a specific use-case,
> which is not the same as the ID attribute at all.
>
> I never said the forms themselves would have the same name or id, but
> elements within them might have the same name, and two forms might have
> elements with the same name. If the ID were to be a substitute for the
> name attribute, then this could never happen, our scripts would become
> more complex, and all for no gain.
>

Let's also not forget radio buttons that *by design* should have the
same name - if they don't, they don't work properly.

Regards
Peter

-- 
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux