+1
I've been saying for a bit that our current implementation just seems
a little... off. Our filter system should behave and look like the
rest of Habari... where you use *methods* to get the data you want.
Not only will this avoid any confusion about what $_* actually is, but
I think it will also serve to make our code cleaner.
Using either approach, we will of course need to rewrite some code.
Therefore, I think it is best that we nail down a good approach (like
yours) from the beginning, and stick with it.
On Dec 2, 2008, at 5:35 PM, Chris Meller wrote:
> The SuperGlobals implementation is novel and sounds great in theory,
> but hasn't stood up in practice. Having an object instead of a true
> array has made numerous things more difficult, especially if you're
> writing code that expects normal $_* arrays. In the end, it tries so
> hard to behave like the native $_* arrays, but falls just short
> enough that it'll easily drive you into madness.
>
> A few examples I ran into while trying to fix the WordPress importer:
>
> empty( $_POST ) always returns false. count( $_POST ) returns 0.
>
> isset( $_POST ) would obviously never work, since $_POST is always
> set. I'd never have done that, but whoever wrote the WP importer did
> (we really need to finish those coding standard)... I don't know
> that we could fix that without risking errors because people call
> methods on non-objects if it no longer exists. Using empty() would
> probably be better, but...
>
> In order to use any of our pseudo-arrays as actual arrays, you have
> to remember to use ->getArrayCopy() or ->get_array_copy_raw().
> That's annoying... and it hurts my fingers. It also doesn't let you
> use it in conditions such as if ( empty( $_POST->getArrayCopy() ) )
> because you can't use a method return value in a write context.
> Setting a temporary variable to the result array and testing against
> that is a waste of code and time.
>
>
> And just when you think I'm going to complain and run, here's
> another suggested approach, based a lot on the CodeIgniter and (more
> so) Kohana frameworks' implementations:
>
> Input::get($index, $filtered = true) { ... }
> Input::post($index, filtered = true) { ... }
> Input::server($index, $filtered = true) { ... }
> Input::cookie($index, $filtered = true) { ... }
>
> $foo = Input::get('foo'); // $_GET['foo'], filtered
> $foo = Input::get('foo', false); // $_GET['foo'], unfiltered
>
> While I would personally never simply check for isset or empty $_*
> for those who would and in instances where a true array of
> everything is needed, we provide a simple array of each: Input::
> $get, Input::$post, Input::$server, and Input::$cookie. That means
> if ( empty( Input::$get ) ) works fine once again. The naming scheme
> for an un-filtered version is up for debate...
>
> The basic principle here is that we don't use $_* - they're obsolete
> and can be filtered or totally unset all together. The key is that
> we don't even try to use them, thereby avoiding confusion when
> people think they know what kind of behavior to expect.
>
> As a simpler, more retro solution, we could always just filter $_*
> directly and provide some other similarly-named array that contains
> raw values. I'm not big on that approach, but it's always still an
> option.
>
> I do still like the idea of being forced to get a single input value
> at a time, as in my opinion it forces you to hold the reigns on your
> data and what data you're accepting more tightly, but no matter how
> it's implemented that is going to require a good deal of code
> refactoring in a variety of hidden-away places that will probably
> never throw errors. If we decide to go with that kind of approach
> (either the current one, or a new one), I think everyone needs to be
> more mindful of the pitfalls and be on the lookout for things like
> that - it seems like I'm the only one at present who's noticed.
> Fixing things like that can be difficult when it's not code you
> wrote and you don't know exactly which fields can, should, and might
> be submitted by any given form...
>
> >
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
