И да - все что содержится в полях формы, это не INT, это строки.

Так я сюда и не учить кого-то пришел, а учиться.. По сути, это чуть ли не первый проект. И так уж сложилось, что данные выходят именно так. Может быть, настанет время, и я образумлюсь и все перепишу "как надо", а не черти-как, но пока нужно решить конкретную задачу, а скрипт выводит NaN :-?

Предполагаю что тут ситуация при которой frontend разработчк не имеет доступа к backend части. Результат - необходимость извращаться с регулярками.

А это как объяснить - <option value="1" > <?php print ($item1. ' (' .$score[0]['cost'].')'); ?> </option> ?

laimas,
Ему дали код, но не разрешили править, чтобы ничего ВНЕЗАПНО не сломал :haha:

Так а я о чем? Учится, значит учится грамотно проектировать БД, а это 99% успешного веб приложения. Будет понимание того, как оптимально хранить данные в БД, придет и понимание того, как можно оптимально эти данные и на странице представлять.

Вы по сути сделали следующее (пусть считаем, что с базой все ОК) - взяли и сознательно все смешали в кучу, а затем костылями пытаетесь выудить в ней нужное.

Вот вы можете ответить на вопрос - почему ваши две опции имеют value="1". Что такое 1?

PS. NaN, потому что, как я уже говорил, value="1" не есть число, это строка в которой 1 написано. То же самое и с возвратом по шаблону - вернется не число, а строка. Чтобы она стало числом нужно parseInt()

И да, вернитесь к серверной стороне. К чему "нужно еще и после селекта делать отдельный запрос с фильтром по выбранному value" не понятно, а я говорю о грамотном представлении данных на клиенте.

<option value="1" data-price="<?=$score[0]['cost']?>"> <?=$item1 . ' (' . $score[0]['cost'] . ')'?> </option>

Так разве есть проблемы с выводом?

Потому что это два value от двух разных селектов. По сути, номер это выбора в селекте. 1...n
Я применяю .match не к value, а к text. И пусть бы эти 1, 20, 100500 будут строками, а не числами. Мне их записать надо.

Вероятно, так тоже сработает. Но сейчас на странице около 17 опций на 5 селектов. Будет больше. В каждом отдельно прописывать

data-price="<?=$score[0]['cost']?>"

будет оптимальней рег.выражений?

А выбор пользователя ведь нужен не ему, а серверу, так ведь? А чем должен оперировать сервер? Уж точно не результатом на на клиенте, как 20+30+.... Сервер должен ведать ценами, он должен считать сам, а для этого он должен получать в качестве value полей формы не абстрактные 1, 2, 3, .... а идентификаторы товара, либо его характеристик, либо иное, но то, что определяется уникальным значением этого в базе. Всякие расчеты на клиенте, это сугубо сервис для пользователя, тем более когда речь идет о деньгах.

Нельзя сложить строки, результатом будет строка, либо NaN.

Да.