Re: 2D array by POST

On 5/19/23 20:27, J.O. Aho wrote:
> On 5/19/23 17:56, Jerry Stuckle wrote:
>> On 5/19/2023 2:19 AM, Liz Tuddenham wrote:
>>> J.O. Aho <[email protected]> wrote:
>>>
>>>> On 5/18/23 23:38, The Doctor wrote:
>>>>> In article <[email protected]>,
>>>>> J.O. Aho <[email protected]> wrote:
>>>>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>>>>> I need to send a 2-dimensional array from one file to another by 
>>>>>>> POST.
>>>>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>>>>
>>>>>>> I have tried :
>>>>>>>     Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>>>>> with
>>>>>>> $item = stripslashes($_POST['item']);
>>>>>>> but it does not work.
>>>>>>>
>>>>>>>     Any suggestions?
>>>>>>
>>>>>> 1. use session, store the value in the session and then use it in the
>>>>>> next page directly from the session.
>>>>>>
>>>>>> 2. serialize the variable and base64 encode the serialized data, post
>>>>>> this in the form and then base64 decode and unserialize.
>>>>>>
>>>>>
>>>>> Is base64 strong enugh?
>>>>
>>>> It's not about the encryption, it's about not making the html to break
>>>> as you don't know what the serialized data may contain.
>>>>
>>>> if the data is sensitive or you want to avoid user manipulation of the
>>>> data, then store the data in session and that is way it was number 1 of
>>>> the suggestions.
>>>
>>> The data isn't particularly sensitive, it is just a 'shopping list'
>>> passed from one part of a shopping program to another.  It could have
>>> been sent as dozens of individual variables, but that seemed clumsy as
>>> they were already nicely wrapped up in an array.
>>>
>>>
>>
>> J.O. has the right idea.  The way to do this is to store the data in 
>> the $_SESSION variable to pass it on to the next page.
> 
> You have the thread "Replace punctuation in an associative array" where 
> you can see an example on how it could be possible to work with the 
> session, I do not claim it's the best solution, but based on the 
> "requirements", it's a good solution for a half hour work.
> 
> 
>> This is especially true if it has things like prices - which the user 
>> can change if you give them access to it via a web page.
> 
> Yeah, I tend to favor to take prices from the database each time, this 
> more to keep the prices up to date, as then if someone changes a price 
> on a product that price change will get trough at once on all orders 
> that are not finalized.

Sorry, thought I replied to Liz, the two section I write was more 
intended for her than replaying to you.

-- 
  //Aho