Add a valued() function to encourage consistency in input fields

[jeremyfelt]

A valued() function would fit well with the helper functions selected() and checked().

Makes it easier to add a value if it exists, and to escape the value with esc_attr().

Makes it easier to provide a placeholder text.

Use would be:

<input type="text" <?php valued( $possible_num, true, '4 digit number' ); ?>>

Which would result in:

<input type="text" value="1234" placeholder="4 digit number">

Or

<input type="text" placeholder="4 digit number">

(Depending on the original value of $possible_num)

[scribu]

I don't really see the benefit. Unlike checked and selected, writing value="" has no adverse effects, so there's no if statement necessary.

[solarissmoke]

Also, the proposed function would fail if you supplied it a falsy value, e.g., '0'.

(by fail I mean it wouldn't output a value when it should output "value='0'")

[jeremyfelt]

Updated function

[jeremyfelt]

Good catch. New diff attached with fixed function that handles 0 correctly for both $value and $placeholder.

I think the benefit comes when writing several input fields for meta boxes. Would make code cleaner to read and easier to keep consistent.

[nacin]

Core doesn't use placeholder values, so I'm not sure how useful this is yet.

[ocean90]

Would make code cleaner to read

Really? With your function you need to check first if a placeholder or a value attribute is meant. And I'm not a fan of the name valued.

[scribu]

This doesn't seem more readable to me:

<input type="text" <?php valued( $possible_num, true, '4 digit number' ); ?>>

I have no idea what the second and third parameters do, unless I look up the definition for the valued() function.

The placeholder attribute has no place in the valued() function.

[scribu]

In general, let's not make the same mistake we made with submit_button(), where we ended up with code like this:

submit_button( __( 'Apply' ), 'button-secondary action', false, false, array( 'id' => "doaction$two" ) );

You get +100 psychic points if you can guess what those two false values represent, without looking at the definition.

[jeremyfelt]

You get +100 psychic points if you can guess what those two false values represent, without looking at the definition.

That could be the case with many functions. I think the true/false for echo/return works here.

I do think placeholder is a useful addition for UI purposes, but see how it could be considered fluff in a function that could provide values for more than type="text".

With the default values of the function though, only this is required:

<input type="text" <?php valued( $possible_num ); ?>>

I don't have any reasons to leave out a blank value="", so it may be that the if statement is unnecessary. Of course once you take that out, it appears I may be overreaching a bit.

[ocean90]

What should I do if I want placeholder and value?

[jeremyfelt]

Replying to ocean90:

What should I do if I want placeholder and value?

You would supply 3 arguments.

[ocean90]

Replying to jeremyfelt:

You would supply 3 arguments.

Oops. Yes, I misread the function. :)

[nacin]

You get +100 psychic points if you can guess what those two false values represent, without looking at the definition.

I know that one controls <p> tags being wrapped or not, but I didn't know which. It turns out the other one is the name attribute.

That could be the case with many functions. I think the true/false for echo/return works here.

This works sometimes, but it ​gets old really quick.

In fairness, valued()'s third argument is the same as the third argument for checked() and selected() — whether to echo. Unfortunately, the first and second arguments do not have parity. In checked(), selected(), and disabled(), the values are compared to ascertain whether to issue the corresponding selector. They are designed to help with loops because the code gets messy here quick.

Not to pick at a function name itself, but neither attribute is called valued, while they are called checked, selected, and disabled. All three of those are also boolean attributes that control the input state, not something that requires a value.

If we are to consider a valued() function, we might as well just have an input() function that serves up the whole element. Generally, I think HTML is enough of an "API" all on its own.

[azaozz]

Replying to scribu:

In general, let's not make the same mistake we made with submit_button()...
...You get +100 psychic points if you can guess what those two false values represent...

Agreed. Don't see a point in replacing simple HTML attributes with PHP functions that generate them. This type of functions would always need lots of args to be able to cover the more common cases which makes the code a lot harder to read. On top of that they usually don't cover all possible cases making them redundant.

[scribu]

That said, I have a generic ​html() function that takes care of using the appropriate esc_*() helpers. I'm still not sure if it was a good idea, though.

[jeremyfelt]

All good points, I'm convinced. Thanks for taking a look, all.

The only case where this now seems to make sense is the one esc_attr() can already handle, creating redundancy.