
<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 10 Jan 2007, at 10:58 AM, AjK wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">If only that were true. I'll give you an example of where it isn't true. I once created a "directory of people" for a client. I created a node type to hold the records so tax could be used. I created a form builder function and a db update function to handle it. All's well. Then the client says "some of the people in the directory are actual site users, would be nice if those users could be joined to their record so they can edit their own entry". Made sense, so I used a tab in "my account" to allow for "per user" editing and I initially tried to reuse my existing form builder and db update functions. Guess what? When the form is submitted on "edit node" the update function gets an object, when it's submitted via drupal_get_form() it's an array. Solution, I just cast the array to object in the db update function. But it demonstrates where Drupal is not consistent in it's use of data type containers. Is it an array or an object? Who knows unless you test for it.</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>Well. Forms in html / php are returned as arrays. And any casting we do from that, is going to end up having to be cast back if </DIV><DIV>we want to use the form submission stuff.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Some of my data api stuff requires doing away with objects in relation to forms / data models entirely (such as fixing the horrible node form situation where you have to</DIV><DIV>pass it an empty node object with the right type)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Arrays are just simpler and more flexible to work with in php. We often need to do things like array_merge, which won't work with objects.</DIV></BODY></HTML>