Насколько надежна parseInt?
 

Извиняюсь за глупый вопрос. Но очень важно.
Не хочется потом 200 кб скрипта переделывать.

В таблице заказа товаров выводятся значения в текстовом выражении.
Прежде чем поместить в корзину надо считать несколько числовых значений из строки.

Вижу два варианта:
1. Использовать, скажем, span и parseint 10.
2. В таблице использовать input-ы и с помощью css сделать их невидимыми, а следовательно, использовать $('#abc).val().

Что выбрать? Реально, не хочется потом все переделывать.

Спасибо.

Эдди,
parseInt работает только если строка начинается с числа. Если вы делаете что-то типа:

parseInt($('span').text());

и в span окажется например   в начале, то всё посыпется. Инпут понадёжней как по мне.

Таблица Заказа, это по логике уже и должна быть Корзина, то что вне Корзины, это не заказы, это всего лишь предложения, список товаров.

Выбор товара, это либо 1, либо можно набирать любое произвольное его количество. При этом как сервис на клиенте можно сразу рассчитывать цену набранного, которую удобно держать под рукой, непосредственно в поле ввода, в котором набирается количество товара. Держать ради этого скрытые поля в формах не выгодно и накладно. При этом parseInt может и не потребоваться - "2" * "2" = 4, а вот "2" + "2" = "22"

Серверу же для помещения товаров в Корзину совсем не нужна его цена, он и без клиента ее знает, ему нужен идентификатор товара и его количество.

У меня все сложнее. Это не товары. Это услуги. Есть основные услуги, есть дополнительные.
Сначала клиент выбирает одну основную услугу (которая в строке таблицы), плюс к тому выбирает доп. услугу, если она нужна.
При клике на стоимости основной услуги я должен положить заказ в корзину (в БД - сессии не подходят).
Потом к этой услуге клиент может добавить другую услугу, и это добавится в один и тот же заказ, если услуги совпадают.

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

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

Gulp + uglify https://www.npmjs.com/package/gulp-uglify

Я все понимаю. Только однозначно можете мне посоветовать?
Инпуты сделать или выдергивать из span значения полей?
КОд я начал писать, когда еще в JS вообще не разбирался.
Сейчас для начала надо запустить работу. А потому буду лакировать и уменьшать код.
И я уже знаю, как.

Что именно?

Есть три типа корзин, в зависимости от того где ее данные хранятся:

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

2) куки, тоже самое что и в сессии, но время жизни такой корзины может быть большим.

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

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

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

А данные необходимые серверу для того чтобы понять, что выбрано, так это типа:

<input name="product[12]" data-price="200" value=""> - и сервер получит в массиве под ключом 12, что является идентификатором товара, его количество. Цену 200 ему не надо, он ее как и все остальные данные о товаре может получить в базе. Эта цена нужна на клиенте, для расчета при наборе товара.

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

Это все понятно. Но Вы говорите об обычных магазинах с конкретными товарами.
У меня же немного другая ситуация. Можно сравнить ее с заказом автомобиля у производителя. С выборами опций.
Сначала клиент выбирает марку авто, помечая опции галками в чекбоксах.
Не регистрируясь.
Именно это мне надо, чтобы клиент проделал сначала все без всяких заморочек. А когда он накидал в корзину все, что ему нужно.
Просмотрел корзину, удалил лишнее, добавил необходимое, то он уже проделал работу.
И вот тогда он кликает на Заказать. И вот только тогда ему предлагается зарегистрироваться.
И он зарегистрируется именно потому, что уже проделал всю работу, и чтобы эта работа была проделана не зря.
А сессия к тому времени может и протухнуть.
Кстати, подумываю писать его ай-пи адрес также в бд.
Чтобы даже закрыв браузер, а потом снова его открыв и зайдя на страницу поиска, в корзине были выбранные им товары или услуги.

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

Насчет того, что писать надо только id товаров и услуг вопрос спорный.
Привожу аргументы:

Если не писать в БД стоимость, а она у поставщика изменится, то клиент будет неприятно удивлен, купив, скажем, айфон за 200 долларов, а когда войдет в личный кабинет, то этот айфон оказывается стоит уже 300 долларов.
Это тоже, как я считаю, ошибка интернет-магазинов.

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

В чем здесь я ошибаюсь?

И последнее. Насколько я понял, еще недостаточно изучив JS, сессии - это не стезя этого языка. Это php. А мне надо, чтобы за весь период выбора услуг/товаров и опций к ним страница ни разу не перезагружалась. Можно, конечно аяксом присобачить сессию. Но я уже сказал выше, что пройдет 25 минут, и она протухнет. Или клиент закроет браузер, или свет у него отключится.

Больше скажу в пользу того, что писать в БД надо практически все.
Даже название товара/услуги. В моем случае легко название услуги может измениться. А уж цена скачет в зависимости от курса валюты.

И еще. У меня не предусмотрено регистрировать клиентов вообще. Только субагентов, которые получают комиссию.

Ну, тогда будем считать, что у меня четвертый тип корзины. :)

Извиняюсь, что тут поэму уже написал. Но хочу, чтобы было ясно.

Код под пол мегабайта (65% которого - комментарии) - это не для корзины.
Это форма поиска сложная. При изменении любого элемента меняются еще несколько аяксом.
КОрзина потянет на 10 КБ в js и на 15 КБ в php.

Вы думает это так принципиально чем торговать, бубликами, авто или услугами? Каким образом это может влиять на элементы выбора товара или услуг, а именно элементы формы? Товары влияют лишь на архитектуру формы, возможно на поэтапность операций, но подменять элементы формы, а тем более не использовать их на каком либо этапе, не давая возможность на каждом из них внести изменения, это что по вашему сервис?

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

Кстати, подумываю писать его ай-пи адрес также в бд. Попробуйте, вот только IP, это вещь зачастую динамическая, может быть вообще левая.

Сессия автоматически продлевая при каждом обращении к серверу, то есть если клиент активен, то она может работать пока страницу не покинут окончательно. Кроме это есть куки.

Насчет того, что писать надо только id товаров и услуг вопрос спорный.

Вы еще и спорить хотите после ваших же слов - Если не писать в БД стоимость, а она у поставщика изменится? А где говорилось о том, что стоимости не нужно в базе? Вы совсем не поняли чего вам сказали, а сказано было следующее - "для того, чтобы серверу знать о выборе пользователя товаров или услуг, ему нужно знать только ID товара/услуги и количество набранного, а цену, название товара и прочие его параметры сервер сам узнает запросом к базе по ID товара/услуги".

Сессия на сервере, стартуется севером, клиенту передается только ее ID, по которому и идентифицируется сессия пользователя при запросах браузера. В остальном вы просто не знаете механизма работы сессии.

Суть не во всем этом, а в следующем - если обслуживающий ваш сервис клиентский скрипт весит пол мегабайта, то первым вопрос должно быть - "а то ли я делаю?".

Мусор в базе убирается своим сборщиком. Потому что мои услуги имеют срок действия. По окончании срока автоматом удаляются кроном.

С одного ай-пи могу десятки клиентов быть. Но в наш кризис это не суть.
Он будет один.

То, что сессия продлевается, я знаю, но по истечении 24 минут она сдыхает. А я еще сказал, что могут отключить свет.

И главное в Вашем последнем абзаце.

Да, я знаю, что сделал немного увесисто. Но я ведь объяснил, что когда начал писать скрипт, в джаваскрипте вообще ничего не смыслил.
Потому и мои частые вопросы здесь.
Пока скрипт весит 100 КБ со всеми комментами. Но когда допишу, будет весить много больше. Если сжать, то в 100 КБ уложусь. У нас же сейчас интернет не по дозвону с телефона.

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

laimas И вообще я благодарен за все ответы. За вообще внимание к моем вопросам. Спасибо. Очень ценю.
Да, Вы не говорили, что цену писать не надо. Сервер ее знает. Но надо писать айпи, а с сервера брать и писать цену и прочее. Разве не так?

Вашими устами да мед пить.

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

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

А что бублики, что авто, один хрен, потому как суть одна и та же будет.

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

Про сложность скрипта.
В качестве доп. услуг может фигурировать, скажем, страховка.
До 65 лет она стоит одних денег, после других денег. А после 75 лет вообще не делается.
У одного клиента виза есть, у двоих нет, это тоже надо предусмотреть.
Номера в отелях бывают более 10 разных категорий. Для одного выбрал категорию Сьют, другой хочет в сингле стандарт размещаться.
Отсюда и проблемы с размером js.
Питание может быть нескольких видов.
Можно продолжать до бесконечности все витиеватые тонкости такого бронирования.
Это не купить булочку или айфон.

Изучил онлайн-бронирование конкурентов. ТИХИЙ УЖАС.
Самый частый ответ: "По вашему запросу ничего не найдено".
А я делаю так, чтобы по запросу было точно найдено, а если нет такой услуги, то и в форме ее нет.
СОгласитесь, это новый подход.

Ваш вопрос начинался с некой таблицы Заказов, в которой проблемой было что-то рассчитать.

Ну пусть об этом забыли, пусть выбрали тур, потом еще что-то добавили, потом страховку, потом еще что-то.... Могу сказать сразу, что все это можно выбрать и указать стразу, тут как раз проблема неудачного представления данных, что обуславливает поэтапоность. А может вполне можно было бы обойтись без нее, ведь в конечном итоге корзина отображает все параметры заказа, так ведь? А если она отображает все, значит все можно было выбрать за один присест.

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

Кстати, что такое можно писать в комментариях для скрипта размером 12 КБ, которые весят 500 КБ? :)

// цикл начал
for (var i = 0; i < 5; i++) {
	// тут 0
	// сдвинул на 1
	// уже 1
	// сдвинул на 1
	// уже 2
	// сдвинул на 1
	// уже 3
	// сдвинул на 1
	// уже 4
	console.log(i);
}
// цикл кончил =)

:write:

Ну тогда это скромность :)

laimas,
:)

Если я написал 500 КБ, то я преувеличил. Невнимательно прочли.
Я написал, что пока скрипт составляет 100 килобайт. Из них больше половины - комменты.
Думаю, что когда закончу, будет полмега, а выбросив все лишнего - только 100 КБ.
Я бы тут не стебался.

Сёдня пятница. Можно и поржать. Я с Вами... :p

Так преувеличено или не внимательно прочли? :)

Все правильно, сегодня пьяница, все шутят.

96 килобай пока. Большая часть - комментарии. Но если пятница, то ржем вместе. :)

В ответ на письмо:

Я не стебаюсь. ) Давайте вернемся к этому:

Извиняюсь за глупый вопрос. Но очень важно.
Не хочется потом 200 кб скрипта переделывать.

В таблице заказа товаров выводятся значения в текстовом выражении.
Прежде чем поместить в корзину надо считать несколько числовых значений из строки.

Вижу два варианта:
1. Использовать, скажем, span и parseint 10.
2. В таблице использовать input-ы и с помощью css сделать их невидимыми, а следовательно, использовать $('#abc).val().

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

Я просто позволю себе немного рассуждения. Допустим на неком предварительном этапе я отдаю пользователю некую таблицу заказов. Что я при этом буду делать?

а) если этот этап позволяет произвести оценку выбора, например общую цену, то отдавая таблицу сервер сразу просчитает ее.

б) исходя из вежливости нужно дать возможность пользователю изменять этот предварительный выбор. Для этого достаточно помести в таблицу флажки, значениями которых будут идентификаторы выбранных значений, то есть выбранный флажок передаст на сервер ID значения, которое нужно будет удалить. А чтобы при этом произвести перерасчет общей цены помещаю в флажок цену выбранного идентификатора. То есть это будет так - <input type="checkbox" data-price="450" value="222" />.
А для расчета общей суммы достаточно обрабатывать события изменения состояния флажков, выбирая те, что не отмечены, суммируя цену получаемую из data-price. Это все что требуется, и это мизерный код.

Если вы "мечетесь" не зная из чего что получить, то у вас или неудачное представление данных, или вы не достаточно хорошо представляете решаемую задачу. Вот суть моего изначального ответа была.

laimas Вы в каждом посте говорите о неудачном представлении данных.
Я не программист-профессионал. Я не делаю работу на заказ.
То, что я делаю, я делаю для себя. Я начал делать свой сайт, когда еще 95% конкурентов своих сайтов не имели.
Я не ставлю себе задачу изучить все языки программирования на зубок.
Если передо мной стоит задача что-то сделать, я это делаю, ища нужные ответы в поиске или на форумах.
Кстати, форум по javascript - один из самых вменяемых.
Если бы я то же самое спрашивал, скажем, на phpclub, меня бы послали подальше со второго поста.
Ваш предыдущий пост сейчас еще раз сейчас внимательно осмыслю.

Про флажки не понял. Это что?

Ну а о чем говорить? И причем тут все языки программирования?
У вас стоит некая задача что-то там рассчитать, и на клиенте, так? Ну так вам и говорят, и не только говорят, но и показывают, как можно организовать представление данных на клиенте, чтобы их получать при расчетах.
Основа ваших данных в форме это что? Элементы формы. Ну так добавьте в эти элементы недостающие данные, чтобы получать их из элементов, ибо при расчетах вы же к ним обращаться будете.

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

Огромное спасибо всем. Особо laimas.

Все же скрытые поля. По любому в таблицу не ай-ди выводятся. А ай-ди нужно-таки куда-то вывести, чтобы их сохранить (в моем случае в базе, не в сессии).
Ай-пи тоже буду писать. Может, у кого адрес динамический, и потеряют то, что начали заказывать. А вот те, у кого статический, точно не потеряют.
Хоть какой-то мизерный процент удастся подцепить. :)
В общем, кризис вносит свои прерогативы.

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

А вот для идентификации клиента пишут не IP, а куки ему.

А вот можно. :lol: Когда нихрена в JS не смыслишь. И как только проект оставляешь на пару дней, потом на свой скрипт смотришь как БАРАН на новые ворота. :blink:
Гуглом сжал 100 килобайтный файл .js (будет 500 кб). Получилось 23 КБ.

Все же сделал не по скрытым полям, а по ссылке:

//Получаем значение атрибута href и выбираем только параметры в массиве
var params = $(this).attr('href').split('?');
alert(params[1]);

Теперь ломаю голову, как при пометке чекбокса доп. услуги дополнить GET нужными данными. :)

Вообще-то, я сначала делаю так, как считаю нужным. Как мне хотелось бы видеть сайт, если я бы был клиентом.
И только потом изучать конкурентов и дополнять/улучшать онлайн.
Иначе буду как все. Стоит за 250 000 рэ купить готовый скрипт.

(Вспомнился анекдот:
"Грузин послал в Москву сына учиться и институт.
Потом прислал ему личный автомобиль.
Сын звонит, жалуется:
- Папа, здесь все мои друзья на автобусах ездят, и только я один на авто.
Ну, папа и послал ему чемодан денег со словами:
- Купи себе автобус и будь как все". :)

Клиенту ваши терзания как то побоку, достаточно глянуть на url этой строки в браузере - 58077 это идентификатор, стальное за ним ради SEO, если не брать во внимание 4.

Сперва данные, их взаимосвязи, они и определяют как их будет определять и сервер, и клиент.

SEO вообще не при чем.
Я в robots.tst отменяю всякие роботы.
Это зона личного кабинета.

И еще вопрос. Надо ли личный кабинет по защищенному протоколу подключать?
Задумался. Потому что, к примеру, из lenta.ru ушел весь отдел. Создал свой сайт meduza.io (кстати, что за домен?).
И все идет по протоколу https. Излишество?

Национальный домен Британских территорий в Индийском океане. Совпадает с сокращением Input Output («ввод/вывод»).

Так дело и не в SEO, а в структуре url, которая определена структурой данных. Собственно она, структура данных, определяет get-параметры запроса. А у вас какие-то терзания, то это пишется, то другое, то речь о Ajax, то с чего-то href.split, то "тут рыбу заворачивали"... :)
Читаешь и сложно понять, что же там делается, и что за проблемы.

Разницу между http и https же знаете, вот и ответ, излишество это или нет, тем более для раздела администрирования.

Круто же Медуза зашифровалась:
- https
- Острова в Индийском океане.
:)

laimas Разницу между http иhttps знаю.
Интересует, насколько оправдано в лично кабинете делать https?
Насчет структуры, буду ли urlom или чем иным работать, покажет практика. Пока сделал в тестовом режиме.
"Тут рыбу заворачивали". Вот это не понял.

На все 100%. И уж если безопасное соединение, то пусть для всего сайта, зачем ограничиваться только администрированием. Если IP статический, то вообще вход в административный раздел можно разрешить только по этому IP.

https://my.mail.ru/mail/ludmilafish/...2327/2129.html - ситуация та же :)