Как превратить велосипед в фотонный звездолёт

[Rise]

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

[laimas]

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

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

Есть менеджер и машины для прогулок описанные в базе (не файлах), и серверный скрипт.

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

Полученные данные пишутся в базу (не файл) в таблицу заказов также под своим идентификатором. Из базы данных по идентификатору выбранной машины получаем цену проката за час, умножаем на выбранное время и эти расчеты шлем заказчику на почту/телефон/пейджер/etc и менеджеру почту/телефон/админку сообщение о новом заказе.

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

Вариант 2. Ваша фирма/контора/артель/etc из 1 кг железа производит 20 кг золота. Клиент хочет получить у вас 50 кг, при этом он имеет возможность только отправлять запрос, без сервиса, так как формула получения золота "делим 1 кг железа на 5, возводим в квадрат части и складываем их вместе" является большим се6кретом, держится исключительно на сервере и своем, и защищенном от любых атак и взломов, что при таком способе добычи желтого металла может и возможно организовать.

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

[avalan4e]

Rise,
По сути, только расчет. Количество машин не ограничено. Но могу предположить, что автопарк всё же может насчитывать до 20-50 автомобилей. С учетом всех замечаний передал следующим образом:

var days = 3;
$('#days').change(function() {
  days = $(this).val();
  $('#vote_status').text(countPrice(type_val, model_val, days));
})

var model_val = -1;
var model;
$('#models [name="optradio"]').change(function() {
  model = $(this).attr("id");
  model_val = $(this).val();
  $('#vote_status').text(countPrice(type_val, model_val, days));
})

var type_val = 1;
var type = "standart";
$('#types [name="optradio"]').change(function() {
  type = $(this).attr("id");
  type_val = $(this).val();
  $('#vote_status').text(countPrice(type_val, model_val, days));
})

function countPrice(t,m,d) {
  if (m > 0 && d > 2 && t > 0) return t * m * d;
  else if (d < 3) return "Выберите количество часов не меньше 3-х";
  else return "Error: обратитесь к тех. поддержке";
}

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

[avalan4e]

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

[laimas]

Как Вы оцениваете вариант, если на серверной части создать массив прайслиста и использовать полученные из $_POST идентификаторы для доступа к соответствующему элементу?

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

$pricelist = array();
$handle = @fopen("pricelist.txt", "r");

$price = json_decode(file_get_contents("pricelist.txt"), 1);

И если так мало данных выгружать этот JSON клиенту (идентификатор машины=>[описание машины, цена, и прочее необходимое]), а готовя список в качестве значений опций указывать идентификатор машины. Выбор в списке будет означать - получить из объекта данные этого авто и рассчитать.

Вот только если сервер должен и хранить выбор пользователей (заказы), то писать их в файл, это неудачное решение.

[warren buffet]

Массив нельзя хранить в файле

А вот у меня есть массив в файле

<?php return array (
  12 => 
  array (
    'id' => '12',
    'pid' => '0',
    'path' => 'stl',
    'title' => 'Стиль',
    'text' => 'Общая характеристика по стилю',
    'show' => '1',
    'c' => 
    array (
      13 => 
/* and so */

Что мне за это будет?

---

ТС, ты превратил банальную задачу клиент-серверного интерактивного обмена в какую-то историю О. Отправляешь по вводу - ну отправляй, получай, рендери и все как обычно. Просто у тебя получится вот что: на 1 байт глупых данных из формы, ты будешь поднимать мегабайты хлама на сервере и ради чего?

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

[laimas]

А вот у меня есть массив в файле

Ты совсем больной или что?

[warren buffet]

laimas, мне еще интересно, как клиент может обмануть сервер? Ну, скажем заказать несуществующий товар в несусветном количестве.

[laimas]

А причем тут массив? Нельзя непосредственно тип данных Array, Oject записать в файл, нужна либо сериализация, либо JSON, либо свой велосипед изобретать. И уж коли вместо базы использовать массив, то выгоднее не просто текстовый файл, а необходимая структура данных в нем.

Тех кто слепо веруют, что форма/данные пришедшие извне есть истина, тех не только легко обмануть, но и взломать. А как это делается, читать на haker.ru.

[warren buffet]

Нет, вот пришел id товара которого нет в бд. Как ты его вообще оформишь?