Как передать значение из JS в переменную PHP

[arhat78]

Если вы считаете количество товаров в корзине и их суму как проходом в цикле, значит структура вашей корзине неудачна.

Да, именно в цикле я и считаю. Других вариантов для примера не видел, научился только так.

А вы можете показать скрипты, где выбирается тип доставки (с учётом стоимости), где можно увидеть принцип осуществления подсчёта всех составляющих заказа? Иначе я так и будут стоять на месте, упершись в стенку....

[laimas]

Я вам уже говорил - циклом, значит неудачна корзина, и не знание РНР. Прочтите о функциях которые в коде, что я написал, станет понятно как. Цикл может потребоваться, если выводится список наименования товара, наряду с его ценой, количества, суммы за количество. В ином случае, как то для отображения информации о корзине на страницах, это излишество.

Скрипты, какие? Я вам дал ссылку на тему о корзине. Собственно ваш случай ничем от этого отличаться не будет, только лишь деталями какими либо.

Уясните себе раз и на всегда - клиентские скрипты в части что-то там посчитать и показать клиенту на основе данных от сервера, это сервис для клиента. Серверные скрипты обязаны проверять все данные пришедшие извне, а если требуются какие либо расчеты, то их должен производить сервер, а не получать от клиента.

Что такое стоимость доставки? Ну наверное же не 35 руб. которые вам прислал пользователь. Наверное же это зависит от веса отправления, расстояния и прочего, на основе которых и рассчитывается стоимость доставки. То есть в любом случае это некие параметры. Сервер должен знать эти параметры, которые может получать от пользователя, или получать не сами параметры, а идентификаторы их. Например, если речь идет о доставке в черте города, то это может быть идентификатор улицы, а в базе по нему уже параметр как расстояние от магазина до этой улицы, или уже готовая цена доставки. Если параметры, значит расчет по формуле.

Что у вас за доставка, кем (есть ведь доставка и курьерами, есть и почтой, у которой свои расценки), мне откуда знать?

[arhat78]

Ну Php я изучаю, для себя. Сколько смотрел уроков, корзины были тоже с циклами. Но посмотрю, изучу как у вас устроено, может что то и пойму и для себя вынесу (искренне на это надеюсь). Думаю с помощью вашего кода и подхода к корзине я сумею правильно выводить размеры обуви, так как пока не получается так, как я хотел бы.

А вот доставка.... Попробуйте на этом сайте: http://top-top.bl.ee (на нём я тренируюсь и пытаюсь обучаться) выбрать какой-нибудь ботинок, зайти в корзину и там нажать оформить заказ. Появится страница order.php, где будет выбор типа доставки (пока в упрощённом виде) и вывод стоимости.

[laimas]

array_map это тоже обход массива циклом, просто явно его нет, это встроенная РНР функция написанная на Си.

То что вы используете явный цикл, это не смертельно, но ведь помимо его вам нужны две переменные хранящие количество товара и общую суммы, это операции сложения/умножения в цикле.

У вас рядом с кнопкой Корзина отображается ее краткое описание - количество товара и общая сумма. Следовательно эта информация требуется часто, и ее получать выгоднее как функцией или процедурой. А разве не проще и лаконичнее в таком случае ее код как:

function total_basket($a) {
    return [array_sum(array_map('current', $a)), array_sum(array_map('array_product', $a))];
    //с учтом структуры корзины как описано по ссылке
}

где $a - массив корзины товаров. Можно непосредственно в функции обращаться к корзине, так как $_SESSION, это суперглобальный массив. А так как обращений к корзине будет много, это и добавление товара, и вывод корзины, и ее редактирование, то имя массива можно определить в одном месте через константу, например:

define('BASKET', 'bsk_name');
//и везде при обращениях, включая и внутри функции total_basket
return [array_sum(array_map('current', $_SESSION[BASKET])), array_sum(array_map('array_product', $_SESSION[BASKET]))];

Это гарантия того, что не будет дубликатов имен, или имен переменных и имен в $_SESSION. Если потребуется изменить, это нужно будет сделать только в одном месте.

Массивы, это тип данных с которыми в рамках веб приложения вы будете сталкиваться постоянно. А поэтому крайне желательно знать эти функции, и не просто знать, а уметь ими пользоваться.

А вот отображение корзины, где у вас выводится подробная информация о них, тут уж без цикла не обойтись, но и в этом случае, если вывод, это формирование строки описывающей таблицу, то я бы поступил так:

echo '<form><table><tr>ячейки шапки таблицы</tr>' . implode(array_map(function($k, $v) {
   //return сформированная строка таблицы 
}, array_keys($_SESSION[BASKET]), $_SESSION[BASKET])).'</table><button>Send</button></form>'

В вашей корзине выбор доставки, это два типа, причем только первый имеет цену. Эти типы доставки должны быть прописаны в базе под идентификаторами, сделав запрос по которому можно получить цену 300 или 0, добавив ее к сумме заказа. И делать это надо в сценарии, который оформляет заказ. От клиента требуется только выбранный ID доставки, и получать его надо на той же странице, которая содержит сценарий оформления заказа.

PS. Примеры под РНР не ниже 5.4

[arhat78]

laimas, ну допустим тип доставки я буду доставать из БД. Как тогда при нажатии на ту или иную кнопку тут же будет меняться "общая сумма"? Я и попробовал JS, чтобы на этой же странице без перезагрузке менялась "сумма".

[laimas]

Я уже отвечал на это - без перезагрузки, значит таблицу корзины на странице должен формировать js-сценарий по данным возвращенным сервером на асинхронный запрос. Все изменения в корзине можно производить js-сценарием без запросов сервера, включая просчет суммы при изменениях количества товаров и выбранном способе доставки.
На сервер измененное количество и тип доставки отправляются после нажатия, например Применить. Если корзина не будет очищена, значит север производит расчет и далее по плану....

[arhat78]

laimas, в общем вы меня вообще в тупик поставили. Думал, что можно каким то образом передать значение в php-переменную, а теперь вообще не знаю что делать. Так было с размером, так теперь и с доставкой.....

[laimas]

Чем я вас загнал в угол? Вот ваш вопрос:

ну допустим тип доставки я буду доставать из БД. Как тогда при нажатии на ту или иную кнопку тут же будет меняться "общая сумма"? Я и попробовал JS, чтобы на этой же странице без перезагрузке менялась "сумма".

а) Допустим БД, а можно и нет, храня эти два значения в переменных, суть то не в этом,а в том, что задает их сервер, и знает сервер, и клиент не должен возвращать это значение как рубли. Выполнение финансовых операций в вашем магазине, это же не бухгалтер Алевтина Петровна со тетрадкой и счетами в руках, которая не пропустит "подвоха", а бездушный скрипт, и если рубли будет указывать клиент, а вы обязуете свой скрипт принять это, значит обман обеспечен.

Конечно, курьера не обманешь, но ведь и ваш магазин может разбогатеть на ботинках, появятся новые виды услуг, которые могут быть связаны с безналичными расчетами, и если их стоимость вы будете отдавать на откуп клиенту, то вы и в суде не докажите, что вас обманули. А расширение услуг их добавление/редактирование означает, что описывать их как переменные не удобно, а вот в базе удобно, храня их описания и значения в полях типа ENUM. И на текущий момент пусть у вас в базе будет только два enum значения, а цена определяется по ходу и правкой текста, типа такого в таблице конфигураций:

CREATE TABLE IF NOT EXISTS `config` (
  `delivery` enum('Наш курьер (Стоимость доставки 300 руб)','Самовывоз') NOT NULL 
  DEFAULT 'Наш курьер (Стоимость доставки 300 руб)' 
  COMMENT 'Тип доставки',
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='Конфигурации'

Понимание этого не заводит вас в тупик? Тогда далее.

б) Мне трудно отвечать конкретно по действам нажатия на ту или иную кнопку потому как сумма заказов зависит не только от каких-то ваших кнопок, но и от изменений количества товаров в корзине. Речь ведь в данном случае идет о полном представлении корзины, ее редактировании, и для операций с ней необходимости прикручивать Ajax нет. Ajax это всего лишь один из способов общения с сервером, за кнопки и действия по ним он не отвечает, поэтому описывать задачу редактирования корзины как нечто зависящее от него не стоит. Достаточно иметь js-сценарий который будет просчитывать сумму заказа при изменениях количества товаров или их удалении. Сохранение же изменений может быть принято сервером при таких действиях как Сохранить (Обновить), Очистить, Оформить заказ. При этом, в последнем случае перед оформлением заказа нужно проверить не изменялось ли состояние корзины.

Это не вызывает проблем?

в) Ну и последнее - камень преткновения, общая сумма + доставка.

Выбор доставки у вас производится на странице оформления заказа. Если тип доставки описывается полем ENUM, как показано выше, то этому описанию на странице будет соответствовать выбор посредством двух радиокнопок:

<label>
    <input type="radio" name="delivery" value="1" data-dlv="300" checked />
    Наш курьер (Стоимость доставки 300 руб)
</label>
<label>
    <input type="radio" name="delivery" value="2" data-dlv="0" />
    Самовывоз
</label>

значения которых 1 и 2, соответствуют значениям ENUM описывающем тип доставки, а атрибуты data-dlv содержат значения цены за доставку, которые будет использовать js-сценарий при расчетах.

Если ваш пользователь может выбрать тип доставки только на этой странице, а по умолчанию выбрана доставка курьером, то сервер при выводе этой страницы должен проставить в ячейке "Доставка" 300, просчитать общую сумму заказа, поместив ее в соответствующую ячейку, и с учетом доставки. Ваш серверный сценарий этого не делает, хотя всеми данными для этого обладает, а претензии вы предъявляете мне.

После вывода страницы и при смене типа доставки уже сценарий на клиенте будет получать из атрибута data-dlv стоимость выбранной доставки изменяя сумму с доставкой в ячейке таблицы. При оформлении заказа же, на сервер будет отправлено ее значение 1 или 2, которое и заносится в таблицу базы описывающей заказы.

Этого достаточно чтобы выйти из тупика?

Ну и как резюме: если вы учитесь, то учитесь не прикручивать сразу разные плюшки к своему проекту, они не есть главное. Главное научится видеть/представлять задачу целиком, ее поэтапное решение, что необходимо выполнять на каждом ее этапе, какими данными придется оперировать и что является их источником. Принцип только один - от общего к частному. Частности можно решать множественными способами, но без видения общего частности будут как кошка, которая сама по себе.

[arhat78]

laimas, очень интересно, есть над чем поразмыслить. А какой код будет обрабатывать данный data-dlv="..."

[laimas]

Конечно надо размышлять.

1) В вашем магазине есть регистрация и надо полагать, что заказать боты в нем может только регистрированный пользователь. А если так, то зачем покупателю постоянно заполнять личные данные на странице оформления заказа? А регистрация тогда зачем?

Если же помимо регистрированных пользователь магазин не отказывает в заказе и не регистрированным, то и в этом случае можно обойтись без постоянного заполнения данных. Корректный ввод адреса, даже свое ФИО, это ахиллесова пята в форме, то, в чем наиболее часто допускают ошибки. Но если данные введены корректно, то их можно запомнить на клиенте в локальном хранилище (о регистрированных пользователях данные хранятся в базе), и при выдаче страницы этими данными заполняются поля формы. Правда это делать нужно с согласия клиента, ибо эти данные никак не защищены.

2) Сводная таблица о заказе должна отражать о нем все, а не так как у вас - товар, количество, всего за товар, а общего количества товаров нет, как и нет общей суммы за товары. Доставка в таблице при таком выборе как у вас вообще может не отражаться, ибо и тип и цену отражают радио кнопки. Но если думать о расширении услуг, то да, выбор должна отражать сводная таблица, и она же должна отражать и конечную сумму к оплате, которая будет просчитываться при выборе доставки. У вас же эта сумма сама по себе как текст после радио кнопок. А если еще будут бонусы и скидки, и что тоже раскидывать по странице? Зачем распылять внимание покупателя?

3) Должна быть определена доставка по умолчанию, о чем написано ранее - одна из двух как та что не требует лишних затрат или та что удобнее. Тоже самое потребуется, если магазин будет предлагать различные способы оплаты. Используйте тег LABEL, иначе искать и щелкнуть кнопку среди текста не совсем удобно.

Все надо обдумать, определиться со структурой, а уж потом думать о коде ее обрабатывающем. Поэтому конкретно какой код будет обрабатывать data-dlv я сказать не могу, а получить это значение в среде jQuery - $(selector).data('dlv').