I think you're all missing the very basic point here still. Whether or not
empty( $_POST ) is something you (and I) would personally do isn't the
issue. It doesn't work, and by all accounts it should. The same with all the
array_* functions. They *should* work, but don't. Calling $_POST->map(),
$_POST->merge(), or $_POST->anything() is totally and 100% different from
any expectations a new developer looking at our code would ever have, and is
totally different than the way *anything* else works in either Habari or
PHP. That alone should be absolutely enough.
Using Input:: instead, regardless of the real implementation, would put it
in line with the existing Habari "style" and make it more clear-cut that
there's a different way of doing these things. Again, no existing
preconceptions of how something should work that doesn't work anymore.
And handler_vars should be done away with. Everything should be accessed
through Input, so you're not getting "input" from multiple sources (be it
POST, GET, COOKIE, SERVER, or URL). That also makes it much easier and more
uniform for things like plugins to get at a piece of data, regardless of its
source (ie: no handler_vars in your plugin method).
On Wed, Dec 3, 2008 at 12:41 PM, Matt Read <[EMAIL PROTECTED]> wrote:
>
> On Wed, Dec 3, 2008 at 10:47 AM, Sean Coates <[EMAIL PROTECTED]> wrote:
> > Chris Meller wrote:
> >> 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)...
> >
> > Agreed: the importers are a mess. I cut my habari teeth on the s9y
> > importer and it really needs some love.
>
> same with adminhandler.
>
> >> In order to use any of our pseudo-arrays as actual arrays, you have
> >> to remember to use ->getArrayCopy() or ->get_array_copy_raw().
> >
> > I'd argue that we should almost never be doing this.
>
> no we shouldn't. getArrayCopy is overloaded in SG to return filtered
> data in case someone does use it. get_array_copy_raw() was intended to
> be a protected method, but was changed to public to make it easy to
> get raw data?
>
> > Chris Meller wrote:
> >> I don't see what you mean here. Of course you *could* work around
> >> those things, but why should you have to?
> >
> > There's a price to pay for better security: there's always a tradeoff
> > with convenience. In my opinion, this is a fair compromise.
>
> agreed.
>
> >> $_POST['foo'] or Input::post('foo') vs. $_POST->raw('foo') or
> >> Input::post('foo', false)..
> >
> > IF (and that's a big IF) we can't get the superglobals to work in a
> > reasonable manner, then I'd much rather see something like:
> > $_POST['foo'] or Input::post('foo') vs. $_POST->raw('foo') or
> > Input::raw_post('foo'). <-- MUCH easier to audit.
>
> most developers will be accessing handler_vars not $_POST directly. I
> would like to see handler_vars link to the individual 'arrays'. like
> $handler_vars->post['foo'] or $handler_vars->post->raw['foo'] which
> would be the same as $_POST['foo'], $_POST->raw['foo']. and
> $handler_vars->rewrite_args['foo'].
>
> So changing to using Input class would do same thing, only provide a
> global access to the handler_vars stuff.
>
> > Matt Read wrote:
> >> array_* functions will not work, and casting the superglobal to array
> >> will return the original unfiltered array. So if you pass a
> >> SuperGlobal to array_* you should call getArrayCopy and such.
> >
> > I don't agree here. Passing unfiltered data to (e.g.) array_map()
> > makes it hard to trace the output of the array_map through the current
> > context, thus defeating the "this data is safe" assumption.
>
> See comment above. getArrayCopy return filtered data, but I agree you
> should avoid using it. SG class provides the map()/merge() methods
> which will work like array_map/merge but give you back a new SG
> object.
>
> > Chris Meller wrote:
> >> It does work. I'm saying we shouldn't have to use count() instead of
> >> empty(), since that's not true of any other array (and as far as
> >> most people will ever know, $_POST should still be an array... they
> >> treat it like one 99% of the time).
> >
> > I think I'd argue that empty($_POST) would fall into that 1%.
> > Especially with FormUI (shouldn't this check for submission,
> > internally?)
>
> Yes, empty($_POST) is an unusual thing to do.
>
> > If it's not clear, I'm not ready to give up on the new superglobals
> > yet, however, I might be convinced if more concrete examples are shown.
>
> ++
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
