[wp-trac] [WordPress Trac] #22325: Abstract GPCS away from the superglobals

[WordPress Trac]

#22325: Abstract GPCS away from the superglobals
-------------------------+-----------------------------
 Reporter:  rmccue       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  General      |     Version:
 Severity:  minor        |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by CaptainN):

 Replying to [comment:17 MikeSchinkel]:
 > The code I uploaded used an array for that, i.e.:
 >
 > {{{
 > $print_r(  _GET( array( 'level1', 'level2' ) ) );
 > }}}

 Ah! I missed that (I wrote mine while you were posting yours, and didn't
 check yours thoroughly - and mine was a proof of concept, not meant to be
 production code - more of a design mockup).

 The only weird thing with that, is I tend to think of array values as
 "next to" rather than "in to". That they are used essentially as pivot
 tables is a bit weird to me (but it's not unprecedented, and it's not
 bad). I suppose using multiple function arguments could be said to employ
 a similar hack, and multiple args does limit the ability to conveniently
 set a default in there.



 >
 > > Also, how would you know that you've set the default value? You'd
 still have to check that. Maybe more methods are called for?
 > >
 > > {{{
 > > // default value and set in the GPCS method
 > > if ( _get( 'myVar', 'default value' ) != 'default value' ) {
 > >     // validation passes
 > > }
 >
 > What's the use case where that is needed that `has_GET()`and not passing
 a default `_GET( 'myVar' )`  doesn't address?

 If you set a default value in a form (like "enter first name", or some
 invalid value in a select box, or even just an empty string), and you want
 the user to change the default, you'd have to check it on post back.
 has_GET only checks if the key is in the array.



 >
 > > // a function to check for a default value with NULL checks
 > > if ( _check( _get( 'myVar' ), 'default value' )  {
 > >     // the value is validated
 > > }
 > >
 > > // and if you need to output the value with a default
 > > echo _default( _get( 'myVar' ), 'default value' );
 >
 > `_default()` and `_check()` seems like more work than doing it the old
 way.  IMO, of course.

 To just check if the key is set.

 {{{
 // old way:
 if ( isset( $_GET['myVar'] ) )

 // vs:
 if ( is_null( _get('myVar') )

 // vs:
 if ( has_GET( 'myVar' ) )
 }}}

 Or if you need to check for a default value:

 {{{
 // old way:
 if ( isset( $_GET['myVar'] ) && 'default value' != $_GET['myVar'] )

 // vs:
 if ( _check( _get( 'myVar' ), 'default value' ) )

 // vs:
 if ( _GET( 'myVar', 'default value' ) != 'default value' )
 // or:
 if ( has_GET( 'myVar' ) && _GET( 'myVar' ) != 'default value' )
 }}}

 And finally to output the value:

 {{{
 // old way:
 if ( isset( $_GET['myVar'] ) ) echo $_GET['myVar']; else echo 'default
 value';

 // vs:
 echo _default( _get( 'myVar'), 'default value' );

 // vs:
 echo _get( 'myVar', 'default value' );
 }}}

 The second two in each of the three case (except maybe the first) are way
 better than the "old way". Of course, has_GET (et al) and _check could
 easily be written on top of either API solution for even more brevity -
 for example check_GET( 'myVar', 'default value' ) could be nice in the
 "check for default value example" above.

 I'm approaching this from an API design perspective. My primary goal is to
 make the API not suck. :-)

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22325#comment:18>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software