Переключил на php и не увидел того убожества что вы процитировали. В общем не важно. Важно что в теории готовые коды никакого особенного программирования от вас не должны требовать. Они и форму нарисуют и проверят и результат покажут.
1. Так не бывает. Любой грамотный программист четко знает чем может грозить дамп БД в браузер. А кто не знает - это его проблемы.
2. Вы ее никогда не видели, но пишите как будто она есть - нагрузка. Ну ладно, сколько секунд занимает миллион преобразований текста в 1кб? (не говоря про банальное кеширование).
3. Это надо разжевать, да. Смутно помню преданья старины глубокой, с этой магией, так чем там все закончилось?---------- Добавлено 06.08.2015 в 16:21 ----------Для тех кто попкорна набрал полное ведро: это вопрос не техники, но культуры. Техника тут чисто реализация, а принципиальное решение вытекает из культурного уровня, важность которого нельзя переоценить. Фундаментально невозможно создать дуракоустойчивую БД. Любая девачко запузырит вам 10 раз одного и того же - товара, клиента, пациента - просто потому что у нее нет культуры задать вопрос: а вы раньше обращались, или поискать что уже было похожего внесено в бд, ну и в таком роде. Культура хранения данных лишь продолжение этой культуры проектирования и пользования реляционными БД. Которые, сами понимаете, ну никакого отношения не имеют к сраным браузерам и рвотному хтмлю.
Ну при чем тут хтмл и база данных? Ну где тут вообще связь чтобы иметь хоть какое-то основание для пункта 1?
Потому что бд приспособили для выдачи в браузер? - Так это частный случай, не более того.
Где вы такое угребище нашли, этот "класс ютубе"? Ютуба что ли раздает? Это не API, это кал. Скрипт тупо читает типа файл по урлу, если успеет прочитать, то выдаст, если нет - досвидос. Все остальное что там накалякано - какой-то жуткий рендер вперемешку со вспомогательными функциями частью из статического класса Main. Он в DLE что ли есть?
Короче, если хотите что-то сделать, рассказывайте человеческим языком что хотите сделать.---------- Добавлено 06.08.2015 в 08:29 ----------То есть я бы вам сразу предложил, превентивно, забить на php и найти реальное API на ява-скрипте.
Вставьте в код заведомо загружаемого файла вот такой функционал:
const PAGE_ENCODING='UTF-8';// поменяйте на свою кодировку если не такаяfunction htmlents($value){ return htmlentities($value,ENT_QUOTES,PAGE_ENCODING,false);}function echoit($msg) { echo '<br><pre>'; if($msg) echo htmlents(print_r($msg, true)); else var_dump($msg); echo '</pre><br>';}
Например echoit($_POST); die; и вы увидите этот массив прямо в браузере, нормально, по человечески нарисованным. Это важно для понимания устройства переменных типа массива и понимания методов работы с ними.
В php по "массивам" все круто заточено, там этих функций как грязи всяких. В кавычках потому что в реальности это все коллекции, куча переменных в balanced tree, что гораздо облегчает и понимание и управление массивами. Например можете считать что $store['admin_password'] означает: переменная admin_password находится в пространстве имен store. Или аналогия с папкам, вложенными папками и файлами: admin_password лежит в store.
$store = $_POST;// с любым элементом массива поступаем как с любой обычной переменной$store['admin_password']=encryptPaswd($store['admin_password'],getEncryptKey());
Короче, массив это переменная внутри которой другие переменные, внутри которых могут быть еще переменные и так далее. Со всеми переменными массива работа ведется как с переменными. Можно удалять, добавлять, складывать, заменять и тп.
Вообще, конечно, интересно, как не имея элементарных базовых знаний вы там умудряетесь какой-то сайт рисовать. :)---------- Добавлено 06.08.2015 в 07:37 ----------Например в рендерах можно валить все обратно в ту же переменную, как там было:
// модель$form_array = array( 'name'=>array('title'=>'Ваше ФИО', 'required'=>3, 'type'=>'text', 'value'=>null), 'email'=>array('title'=>'Е-почта', 'required'=>5, 'type'=>'email','value'=>null), 'image'=>array('title'=>'Фотка', 'required'=>0, 'type'=>'file','value'=>null),);// renderforeach($form_array as $name => & $op) $op='<label'.($op['required']?' class="required"':null).'>'.$op['title'] .'<input name="'.$name.'" type="'.$op['type'].'" value="'.$op['value'].'"/></label>';echo join($form_array);
Запись & $op (с амперсандом) означает что $op берется как ссылка на очередной элемент массива, а не значение этого элемента и тем самым открывается возможность писать новые значения прямо в эти элементы, прямо в $form_array если как таковой он больше не нужен.
Есть одно но. Если в цикле будут условия и по этим условиям будут пропуски, то join() разорется о попытке сконвертить массив в строку.---------- Добавлено 06.08.2015 в 07:46 ----------Да, может возникнуть еще один из концептуальных вопросов почему бы не делать сразу echo в цикле, зачем писать, потом валить в буфер и все такое.
Потому что жизнь заставит возвращать массивы и тексты, а прописанные повсюду в прошлом эхи заставят обставляться ob_start() ... return ob_get_clean() что в сущности эквипенисуально.
Сперва надо сервер на винде заиметь, чтоб всем показать свой убдате лог.
Тогда проверьте как там сделано согласно этому мануалу http://tltech.com/info/rewriterule-in-htaccess-vs-httpd-conf/
Поле типа Text оправдано только в записях типа статья, то есть когда текст это главное и текст может быть большим: максимум 65535 байтов, что на длину символа скажем в юникоде кириллицы - делим на 3.
Во всех остальных случаях для текстов применяют нормальные varchar поля с заведомо достаточным количеством букв.
Потому что текст это в сущности блоб https://dev.mysql.com/doc/refman/5.0/en/blob.html с той лишь разницей что драйвер "знает" как трансформировать байты поля типа текст. Следовательно такое блобное поле выпадает из рамок буферизации, требует особого с собой обращения что и влечет дополнительный расход ресурсов.
Короче говоря только некультурные люди втыкают тип text в кортеж о скажем товаре или пользователе, то есть когда в тексте фиксируются описания свойств, а не охрененная телега по истории КПСС.
В статье по ссылке выше оракл советует включать это поле в запрос только в крайних случаях. То есть достаточно его не запрашивать и запрос станет другим.
Специально от таких как вы не открывается.
Это был бы мегаподарок всем кому не лень, ибо на винде все разложено по полочкам и заранее известно что где лежит.
Надо скрыть индекс. Выше я давал пример как это делается, там есть комментарии.
У вас в хтакцессе вообще кроме тех двух строк ничего нет? Целиком процитируйте.
Конечно прикольно, это вообще целый сайт есть для таких приколов, если вы не в курсе - govnokod.ru Потому что нельзя строить доктрины в программировании, будете по 100500 раз все переписывать, стопудово. Надо смотреть как люди делают, искать лучшие решения и делать еще лучше на их основе. Так все и делают кстати.
Ну вот, присвоение переменной значения массива обеспечивает простейшее наследование. Например нам нужны в куче элементы двух массивов и один из элементов из кучи не нужен:
$foo = array('bar'=>1,'baz'=>2); $store = $_POST + $foo; // краткая форма array_merge() unset($store['zerocatename']);
Теперь что такое $_POST? Это данные из браузера, с формы, да? Стало быть массив у вас уже и так есть, по которому форму нарисовали, а от поста вам только данные нужны, при чем отсутствие данных тоже дает данные. Значит надо переписать данные, заодно проверяя их правильность - что и называется валидация.
foreach($form_array as &$field) validate($field); // $_POST суперглобальный, его не надо передавать аргументом
Таким образом переписали все данные из поста в модель формы - $form_array, при этом те данные которые не пришли оставили дефолтные данные, например null и можно принимать решение - допустимо это или нет. А как это узнать? Надо записать в модель формы не простой массив, а золотой, то есть со всем барахлом. Например
$form_array = array( 'name'=>array('title'=>'Ваше ФИО', 'required'=>3, 'type'=>'text'), 'email'=>array('title'=>'Е-почта', 'required'=>5, 'type'=>'email'), 'image'=>array('title'=>'Фотка', 'required'=>0, 'type'=>'file'), );
Тут все в куче - и данные модели и данные представления, например тип поля - это представление. Поэтому обычно делают не массив, а функцию (метод) который на этапе моделирования возвращает только данные модели, а на рендере другой метод обогащает модель данными для представления. Ну это уже слишком далекая перспектива для вас, но знать о ней полезно :) ---------- Добавлено 05.08.2015 в 22:12 ---------- Тем не менее надо завершить круг. Имея такой "золотой" массив вы сами видите что превратить его в форму очень просто
$html=array(); foreach($form_array as $name => $op) $html[]='<input name="'.$name.'" type="'.$op['type'].'" value="'.$op['value'].'"/>'; echo join($html);
value добавляется точно так же, как элемент, и его можно брать из поста, но не так чтобы напрямую, поскольку в посте такого элемента может и не быть, и не все инпуты обозначают свое значение текстом, но суть именно такова - превратить модель формы в хтмл-форму не бином ньютона.---------- Добавлено 05.08.2015 в 22:14 ----------Если ваш пост приходит не с формы от юзера, а от апи, то представление не требуется, конечно. Но проверять все равно надо.
