PHP Developers Network

Well there's no point in arguing over how common wanting to pass this sort of array is. What I can say is that I'm currently working with php to handle a lot of forms adding data to a database and I've found the trick extremely useful over the last 24 hours. If you want to dismiss it because it's not generic enough for you then by all means do so. I still don't understand why you'd want to, though, as I assume you're quite happy using, for instance, the mysql_ php functions even though they only work with mysql_.

Bye!

First, you didn't give an example. For example, this is the example that you should have presented:

http://news.devnetwork.net/test.php?value[]=hello%20world&value[]=Whatsup&value[]=34343

Secondly, there is a reason I suggest using Sessions for this as the prefered method.

First, you don't have to register or unregister a session variable. Simply doing

$_SESSION['var'][] = 'value';

And that's it. In many cases, you may not be able to easily access the URL's being used on your website.

Also, you make the (wrong) assumption that the user will follow the path you have presented him.

For example: In a recent form I did, rather than simply pass the variable through, I save them in a session. Why? Because if the user leaves the form to go someplace else, and then comes back, I want that information there.

Another reason is potential security. The more information you open up, the more potential problems you invite.

I am not saying your way is bad. Rather, I am saying that I feel your approach, while different, isn't the best. solution.



Pessimistic? I guess my definition of pessimistic is different from yours. I don't see anyone being pessimistic. Rather, I see people questioning your methods, which isn't pessimistic. It's healthy.

If anyone, myself included, came on the board, and started talking about a new encryption method they invented called rot26 (=)), would you expect everyone to just say: Oh hey! Let's be sheep and just agree.

I wouldn't. Rather, I would expect people to question the person presenting the method. Not because we are out to get anyone. Rather, we have these honest questions about this solution.

If your only response to these questions is "why are you guys so pessimistic about this," then sorry, but that doesn't help your case. It's akin to me saying "Why don't you guys see how cool rot26 is! It's so obvious for me!"

Great, it's obvious for you. But that doesn't mean a damn thing in the real world. Explain WHY you think your idea is better.

Several statements, conclusions, that you have presented are final. And yet you do nothing to back up these claims. Let's take a look at your claims.

"in the situation I describe alone it seems to me that it is a neat trick"

You never gave an example of what your talking about. Rather, you just presented an overview, and nothing to backup your claims. Also, it's been my experience that "neat tricks" are simply that, and nothing more, and rarely productive.

"fairly obviously the most efficent (code wise at least)" way of dealing with it."

Are you sure? Efficient in what way? Is it robust? Secure? Fast? The less lines of code you have doesn't mean it's more efficient. I can think of several reasons why your idea isn't the most efficient, and yet you haven't presented any reasons why your idea is efficient.

"And it's really quite a common situation."

I am going to go out on a limb here and assume that I have more years coding PHP then you. I've never really run into the problem you present.

While seeking the true meaning of -> PHP - Advanced Theory and Design,
I stumbled on this. Hope it helps

Well, you don't have to get your panties all tied up into a knot.
So you have found this trick useful. Great! Maybe you could educate the rest of us. Sorry, but actions speak louder than words. What your basically saying is "This works better then these methods, but I won't back it up. You just have to trust me."

Rather than be hard-nosed about all this, simply present us with some examples of what you are actually doing. We haven't dismissed a thing, mostly because their has been nothing to dismiss. Just because something works for you, doesn't mean it's the right way to do it.

Or maybe the problem is you aren't explaining yourself correctly, or that we are reading what you wrote wrong. It's happened before. Rather than get all defensive, and assume a "I can't believe you don't see what I see" approach, try and clarify your point of view. Code would help here. No one is dismissing your solution. Rather, we are dismissing the lack of solution.



You see, now your trying to insult us, which isn't nice (and that is what you were trying to do, so don't try and deny it). Simply put, you don't understand why we don't want your solution? Maybe because you haven't presented one. You had an idea, people had questions about it.

Anyways, the idea you presented isn't bad. My question was rather simple. Immediatly when I hear people talking about passing values around a web page, I think sessions. Why? Because that is what they are good for. They are easy to use, and require less work than the solution you try to present.

Maybe you could explain why Sessions didn't work in your case. Or why you had to pass an array in an array? What's wrong with simply using $_GET?

So rather than get all uppity, come back and present your idea, and discuss it in a professional manner. Trying to insult the users here only reflects poorly on yourself.

Just a tecnical note;
[ and ] should be urlencoded to %5B and %5D , while some browser will automatically fix faulty url's you shouldnt rely on that..

<input type="text" name="beer[]" value="some value">

is fine (No HTML Entities needed), but in an url it should be

?beer%5B%5D=some%20value

Thanks for your detailed reply. I really wasn't getting uppity or trying to 'insult' anyone - I was merely using an exaggerated example to try and demonstrate that saying "I'm never going to use this because it's not generic enough even if there are places where it might be a 'better' solution" was a ridiculous argument. I enjoy a heated discussion and I think that's a valid way of going about it. Having said that, it's very easy to misinterpret tone on boards - and I knew that, so I apologize.

You're right that discussing and understanding new ideas is important. I wasn't saying: don't try and explore this trick, see what its limits are. If you look back to the start of this discussion (and its predecessor on the 'Normal' board) I was just trying to find out if such a method was possible and the early reactions were: the only way of doing this are the three you mentioned - I'm not even going to consider another possibility. Later on, after we had worked out that it existed and had established its limits through a perfectly good discussion the original argument became 'it's not generic enough so I'm never going to use it even when ...'. Neither of these attitudes is about understanding the trick - it was just about being negative for whatever reason.

I did present an example situation - with the multiple select forms. Granted, I didn't present it in much detail because at that point I was just trying to establish that this method existed - it is only now that I'm being asked to justify its usefulness ... which I think becomes a different discussion - as you say, you have to consider security, program structuring etc.. It's not a simple matter.

I'm working on a fairly complex web application and if you are _really_ interested then I can go into detail as to why I think this is the best method in my situation.

Other than that, now we know it exists and what its limits are, if we're good programmers we should be able to work out (or discuss!) when to use it.

And as a starting point for that new discussion:

Regarding copious use of session variables, I think that that kind of completely non-modal design is only useful for small applications/sites.

Above a certain size you want to force users down specific paths or it becomes a nightmare keeping track of what they've done or need to do. In most cases it is simply impossible to keep everything non-modal as most things need to be done in a particular order.

More importantly, from a programming structure and security point of view this is like saying we should make all variables global or keep declaring and undeclaring global variables rather than passing parameters to functions. I'm not sure you'll find many who recommend that.

alexp

Not so.

My first priority is to create scripts which are easy to work with ie easy to modify if new program features are requested and easy to re-use in new programs. A generic solution is almost always better precisely because it's generic. I don't waste time trying to remember if it will work with a particular array or not, and if someone else is working on my script they don't waste time trying to figure out an obscure way of passing arrays.

It took me a while to realise it, but the CPU cycles which most need to be conserved are in the programmers head and not the web server.

I really DO like to see people thinking for themselves though.

As jason pointed out, in different circustances, different priorities. Code that is generic in the sense that it is optimised for future expansion is usually not optimised in terms of speed for the current specific circumstances. On a personal project recently I've been working with the Drupal code. It is wonderfully generic and modular but hugely inefficient in terms of database accessing - this is a real problem on the popular sites I'm dealing with.



I don't agree that the most generic programming solution is necessarily the best way of creating the most generic code (code that can adapt to different circumstances by changing parameters or adding modules) or code that can easily be changed (code which is easy to adapt - well commented, nicely structured). It's about looking at what is likely to change. For instance, if my array is being used to pass int database keys to a form page then it is unlikely the database keys are suddenly going to become complex strings. The whole structure of the database and code would have to change. What is very likely to change is the structure of the form page. So as far as making the code generic/easy to change, I want to make the form page function as simple and easy to read as possible - and not having to stick in a whole block of code that deals with a variable that may be a string or may be an array helps with that. The function knows it is going to get an array and deals with it as such.

Another example is my earlier one of the generic mysql_ functions. They are generic in the sense that everyone knows how to use them and are easy to change for common situations - if someone came to some code and wanted to change a query result from an array to an object they'd know how to do it easily. But they are not generic from a database point of view - you have to be sure that your database is going to be mysql or they won't work. So it's fine to call them directly if you have control over the installation and are only going to deal with sql databases but if you're creating a product you'll want to create a database abstraction layer and call functions from that. This is obviously more complex and less generally maintainable.

not that it matters, but I dont really understand the comparison to database abstraction..
I would say that the piece of code that started this thread is the opposite, the usage of implode on arrays in an url doesn not offer much flexibility, it is extremely limited as all values must be plain letters and numbers without any spaces..
an abstraction would be something fairly robust that handles any data , like a function that you tell to preserve this data until next document/post or similar, and the easiest and cleanest way is sessions, if it has to be in html I would say that serialize is the thing...