|
Posted by Jerry Stuckle on 04/14/07 02:48
strawberry wrote:
> On Apr 13, 2:12 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Schraalhans Keukenmeester wrote:
>>> strawberry wrote:
>>>> On Apr 13, 1:51 am, "strawberry" <zac.ca...@gmail.com> wrote:
>>>>> I'm trying to extend a class (written by others) and was wondering if
>>>>> there's a standard a way of passing a $_GET request to a class. Here's
>>>>> what I have (see below). If I hardcode $where, something like
>>>>> $where = " WHERE `firstname` = 'John' "
>>>>> and then pass it as an argument into the scope of a 'select' function
>>>>> then it works fine, but otherwise the query just appears to hang.
>>>>> I'm deliberately not including the class or class extender at this
>>>>> stage, but I'll add them to this thread later if required.
>>>>> foreach ($_GET as $condition_key => $condition_value) {
>>>>> $condition[] =" $condition_key = '$condition_value' ";
>>>>> }
>>>>> if(is_null($condition)){
>>>>> $where = " WHERE 1 ";
>>>>> }else{
>>>>> $conditionString = implode('AND', $condition);
>>>>> $where = " WHERE $conditionString ";
>>>>> }
>>> You're reposing the question? Or ?
>>> I am not sure myself which is preferrable: having the class handle the
>>> $_GET superglobal array itself, which makes the client code programming
>>> even easier, or leaving it to the client code, allowing for more custom
>>> use. I've seen both examples, each has their practical (dis-)advantages.
>>> If someone has a good argument on why to prefer one over the other (or
>>> even an entirely different way) I'd also be helped!
>>> Sh.
>> The program should handle it, not the class.
>>
>> You should make your classes as generic as possible. If you parse the
>> values in the program then pass the parsed values to the object, your
>> code can be used in a number of ways. If you parse it in the class,
>> you're restricted to using the $_GET array - and those specific index
>> (field) names.
>>
>> For instance - what happens if you have the data stored in $_POST
>> instead of $_GET? Or $_SESSION? You can argue that you'd just pass the
>> proper superglobal to the object.
>>
>> However, what happens if on one page you have a checkbox "Sex" - and on
>> another page it's called "Gender"? Or maybe even just "sex"? You can't
>> do it if you process the superglobal. You can argue that you can make
>> it a condition that the field must be named "Sex". But I don't like
>> unwarranted restrictions like that.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================
>
> Sorry Jerry, I'm confused. With the exception of "global $where",
> everything I've presented so far is in the program (test.php). Can you
> give me (or point me to) a practical illustration of what I should be
> doing to provide this functionality. Obviously if you need/would like
> to see more code, I can paste it here.
>
First of all, don't use $global. It creates a dependency between your
function and other parts of the code. If the function needs a variable,
pass it in the function call (by reference, if necessary).
As for an example:
function validateGender() {
if ($_GET['sex'] == 'M' or $_GET['sex'] == 'F')
return true;
else
return false;
}
...
...
if (validateGender()) ...
(Yes, I know you can do this with a ternary operator, but this is an
example).
The problem here is you have a required relationship between the form
and the function. Your form would have to have:
<form action=processinfo.php method="get">
<input type=radio name="sex" value="M">Male<br>
<input type=radio name="sex" value="F">Female
</form>
You couldn't have, for instance, "method=post". Nor could you have on
your radio buttons name="gender", or even name="Sex". And you couldn't
use it except from the form.
However, coding it as:
function validateGender($sex) {
if ($sex == 'M' or $sex == 'F')
return true;
else
return false;
}
...
...
if (validateGender($_GET['sex']) ...
This second one is more generic - it takes a value from any source, and
the original name can be anything (legal).
The second one is far more usable because it is far less restrictive
than the first one.
Make sense?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|