Как создать уникальный буквенный id для каждой записи?

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

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

Vladimir Nazarov: рад помочь! ;)

На каком примере объяснить цикл do-while для студентов на php?

Скажите, вы нашли ответ на свой вопрос? Если да, отметьте решение, это будет справедливо по отношению к тем людям, которые делятся с вами своим опытом. Почитал ваши комментарии ниже, мне кажется примеров предложено предостаточно. И конкретно в моем сообщении настолько наглядно показан пример использования, что проще некуда. Нужно сгенерировать имя файла, т.е. как минимум 1 раз цикл выполнить надо (вот он - сакральный смысл do while), если дубликатов не обнаружено (а случаи коллизий крайне редки, и тем не менее защита нужна, в любом случае можно не указывать студентам, что используются хеш-функции), то выходим из цикла, иначе генерируем новое имя. Если вы считаете своих студентов совсем глупыми, приведите им в пример, ну не знаю - скрипт, который угадывает имя пользователя. Как минимум один раз он спросит - "Вы Паша?", если пользователь вводит "да", выход из цикла, иначе продолжает по списку перечислять следующие варианты. Базы данных тут не нужны же, да? А вообще, учить студентов надо реальным задачам, а не жалеть их и учить не понятно чему, это я вам по своему опыту говорю. Хотя может вы не платные курсы ведете и приходится вести диалог даже с "посторонними" к этой теме людьми.

Как организовать загрузку файлов в форме?

Ясно, но вы на будущее хотя бы комментируйте ответы к своим вопросам, пол часа расписывал решение, хотел помочь, и не ответа, ни привета.

Как организовать загрузку файлов в форме?

Скажите, вы решили эту проблему?

SQLSTATE[42602]: Invalid name: 7 ERROR: invalid name syntax?

Да вряд ли. У нас postgresql используется вот для этого (geektimes.ru/post/181652), с момента моей публикации проект вырос значительно, триггеров просто нереальное количество. Честно, нет проблем с yii2. Проверьте версию yii2, у вас явные отличия.

Как лучше разработать клиентское приложение на Yii?

Я не занимаюсь версткой, могу лишь сказать, что у нас админка строится на базе https://almsaeedstudio.com/preview, а пользовательским интерфейсом занимаются у нас дизайнер и верстальщик. В любом случае расширения "yii2 foundation" гуглятся, нужно лишь выбрать. Ну и по всей видимости во вьюшках подключить вместо дефолтных виджетов - виджеты foundation.
И не нужно класть php файлы в папку assets. Забудьте об этом. И что значит попытаться втиснуть. Поймите одну простую вещь, что и то и другое - php, что вы делаете запрос к example.com/getdeviceports.php?id=123, что example.com?r=device/ports&id=123. Оформите обработчики запросов как экшены конкретных контроллеров.

Как лучше разработать клиентское приложение на Yii?

Всё так. Используйте jQuery, только всё-таки запросы делайте не на какие-то отстраненные скрипты, а всё также к фреймворку - написать экшн, возвращающий json, не составит труда.

Yii2: Как сделать сортировку по кол-ву записей через кросс-таблицу?

Работает точно на 40к клиентах, за большее не скажу. Запрос yii2 генерирует как сказать, правильный, я такие же запросы использовал перед тем как проект на yii2 перетащить. Ну и для собственного успокоения можно повесить индексы на поля clients_services.service_id, clients_services.client_id, но это уже от конкретной ситуации.

Второй вопрос к толковым web-разработичкам, знакомым с паттернами

Ага, понятно, но где гарантии, что коллекция не подмешает данные, создавая ресурсы? ))) Сверки на этом этапе с БД нет? Наверное у меня паранойя…

Второй вопрос к толковым web-разработичкам, знакомым с паттернами

У нас в движке как раз все реализовано через мапперы, по умолчанию они у нас бывают двух типов, Коллекции и Ресурс модели, первая реализовывает работу с набором сущностей, вторая с одной конкретной.

Уфф, я снова с вами. Привел-таки создание объектов к $device=new device('gid', $gid) — теперь устройство можно создать, передав mac-адрес, серийный номер, gid (id), немного разгрузил проект.

Вопрос вот какой. Когда я вызываю __construct у Ресурса (говоря о вашей архитектуре), происходит запрос в БД и в случае нахождения записи в объект загружается массив. Вот как это сделано у меня пока-что:

class device implements ArrayAccess {
private $container=array();
…
public function __construct($param=null, $value=null){
…
$row=$core->db('pg')->get_row(«SELECT *, ST_AsEWKT(geo) FROM map.devices WHERE {$param}='{$value}' „);
if (empty($row)) return;
foreach ($row as $key=>$val) $this->container[$key]=$val;
}

А когда происходит выборка нескольких устройств, как из них создать правильные объекты device? Сейчас я просто функцией получаю записи из БД, и потом делаю так:
…
foreach ($rows as $row){
$device=new device();
$device->append($row);
$devices[]=$device;
}
…
Т.е. метод append получает массив данных и на выходе имеем полноценный объект класса device.
Честно, мне это не нравится. Через пару-тройку дней браться за создание коллекций, потому обращаюсь за помощью, разжуйте, как это реализовать?

Пока в голову приходят только тупые решения:
— получать не массив строк, а айдишники и по ним создавать объекты, что влечет за собой 5300 запросов, вместо одного, если получаем все объекты. Не вариант.
— общий метод, используемый и __construct и append, в котором происходит заполнение нужной информации по переданному в метод массиву данных. Но, что мне не нравится, так это отсутствие сверки с БД при создании таких вот объектов — где гарантии, что не создается фейковое устройство/абонент/тариф/населенный пункт/платеж и т.д.?

Вертикальное меню bootstrap3 — dropdown со сдвигом вниз не осилил

Спасибо, дружище, что не прошел мимо!

Второй вопрос к толковым web-разработичкам, знакомым с паттернами

)) Про моветон согласен. Используется сейчас исходя из того, что надо было кучу скриптов привести в порядок, раскидав по контроллерам с единой точкой входа и убрав схожие обработки. То тут, то там используются одни и те же данные (скажем населенные пункты нужны в абсолютном большинстве обработок, как и провайдеры и тарифы и тарифные зоны). Так вот, контроллеры отделились. Модели появились. И вот в этот синглтон и запихнул все нужные данные. А статические методы — тоже рудимент, я говорил об этом. Надо было получить по одной функции для получения более чем одного объекта данных, что говорить — изначально было 4 разных функции получения населенных пунктов. Так как сущности для работы с несколькими записями не сформированы, для удобства использования кинул функции в классы моделей. Т.е. сейчас практически у каждой модели есть статический класс search.

Несколько вопросов к толковым разработчикам относительно mvc и php?

Т.е. всё-таки колоться и грызть кактус дальше ))
По всей видимости так и придется. Что меня больше всего напрягает, это упрощая контроллер — усложняю модель. Теперь модель описывает не только объект с возможными методами, но и хранит несколько статических методов для работы с таблицами в БД. По всей видимости валидацию оставлять в модели, а сами запросы в БД выносить еще дальше.
А вот пример далеко не самого худшего метода класса user:

	public function update_name($name=''){
		$core=core::getInstance();
		if (strlen($name)<3) return;
		if ($name==$this->container['name']) return;
		$core['db']['my']->query("UPDATE users SET name='{$name}' WHERE id='{$this->container['id']}' ");
		write_log($this->container['id'], 'name', $this->container['name'], $name);
		$this->container['name']=$name;
	}

На $core пока не смотрим — в него на данный момент помещены все нужные данные. Сделано было для того, чтобы убрать повторные получения одной и той же информации и использования глобальных переменных. То, что туда собрано, скоро будет переработано. Вот в приведенном коде name не проверяется на угрозы. В контроллере же name получаю с помощью get_param и она же проверяет. Но ведь это не правильно. Проверка должна быть в модели. Тогда вопрос, считается ли плохим стилем проверять переменную дважды? Первая проверка хочешь не хочешь произойдет при получении в контроллере, вторая — в модели перед отправкой в БД на update. Опять же, понимаю, что указанный выше запрос в БД можно вынести дальше, в класс который только и будет делать запросы без проверок. Но ведь это тоже опасно? В-общем для меня это какая-то стена. Не понимаю уровень, на котором эта проверка должна пройти и которой будет достаточно. Ведь несколько проверок ведет к сложности в дальнейшем.

Несколько вопросов к толковым разработчикам относительно mvc и php?

В моем случае все еще осложняется тем, что карты osm, база оборудования, оптики, муфт и прочего хранится в postgresql, а сам биллинг — в mysql. Конечно же есть цель получить красивое решение, с минимальными правками в дальнейшем (подстраиваясь под конкретную БД не задумываться — где и что может сломаться. Как я уже писал, у меня в контроллере в том же поиске абонентов формируется часть запроса в БД, дата подключения от и до, какой тариф, какой адрес и т.д. — но это говнокод).
А по-поводу смарти согласен, часть кода все равно приходится писать на php. Речь не о нем, если кто-то хочет вступить в дискуссию, просьба — в личку.

Несколько вопросов к толковым разработчикам относительно mvc и php?

Вот тут
$data=array(
'name'=>get_param('name', 'string', ''),
…
'tariff'=>get_param('tariff', 'int', 0),
);

Незнаю, такого рода вы хотели советы, или что-то другое. Но а если смотреть глобально — какая у вас цель? Может быть стоит воспользоваться готовыми решениями? Легкий фреймворк, вроде CodeIgniter, или возможно Yii или даже Zend 2/Symfony 2.

Выше отписался, не могу найти элегантное решение, как выделить нужные для формы поля — и на основе этой совокупности данных строить как html-форму, так и получение данных и отправку их на обновление в модель. Т.е. хотелось бы здесь вообще отказаться от get_param в явном виде. Пусть он вызывается в каком-то отдельном классе, для получения запросов. Вы наверное меня поняли. ))

Несколько вопросов к толковым разработчикам относительно mvc и php?

Спасибо. Я смотрел в сторону Doctrine, Но может не разобрался. В-общем что мне не нравится (повторюсь, возможно я не понимаю концепцию) — в нашем случае довольно много массовых обработок. Абоненты ищутся постоянно по различным поводам и из них вытягивается информация, кто, где, когда, к чему подключен и т.д. и т.п. Нам совершенно точно нужен доступ к объекту как к массиву. Но. Есть опасение, что написав (случайно или нет в ходе обработки) $user['tariff']=«Ураган» (скажем для вывода произвели замену tariff_id на tariff_name) мы автоматом запишем это значение в БД. Поэтому пока я разделил так, что доступ к объекту, как к массиву, но обновление через различные update_tariff.

Несколько вопросов к толковым разработчикам относительно mvc и php?

я бы сделал $user->createFromHTML(){}
и в нее убрал все эти get_param

даже можно сделать отдельный юзерФабрик, пожалуй, если не боитесь новые классы лепить

Лепить не боюсь, как раз таки спрашиваю, как это реализовать. Ну т.е. ведь НЕ ВСЯ информация, которая хранится в БД, появляется в форме создания/изменения. К примеру с $user, я передаю его в шаблонизатор, и он там уже подключает шаблон user/update.tpl. А в шаблоне ручками расписываю что показывать, а что нет. + к этому js — при изменении области — подгрузить районы и т.д. И потом в контроллере ловлю эти данные и закидываю поштучно в update_name, update_house, update_phone, update_tariff и т.д. В воздухе витает мысль, что это можно оптимизировать, но как — пока не приходит в голову. Объясните, как можно хранить набор используемых полей в формах и на его основе лепить форму и получение данных в контроллере с последующей отправкой на обновление в БД. Можно ли создать такой класс?

Несколько вопросов к толковым разработчикам относительно mvc и php?

Собственно, мы работаем над задачами, которых не предоставляют другие биллинговые системы. И надо сказать, оба человека, работающих над задачей — приверженцы open source. У меня есть желание, и второй сотрудник его поддерживает на все 100 — отточить систему и вылить на гитхаб. Если получится выделить средства на лицензирование, мы их выделим. Но пока еще работать, работать и работать. Ну и конечно стоит задача добиться читаемости кода и невысокого порога вхождения разработчиков в дальнейшем в систему. Никаких иллюзий насчет «вау, мой продукт порвет всех! Я=добро» нет, работаю в провайдере около 3 лет, все это время приходится копаться с разными биллингами (то перетаскивая абонентов при покупке руководством более мелких провайдеров), видим достоинства и недостатки, стремимся в рамках своей писанины и логики быть лучше.
А mvc, Вы знаете мне очень нравится этот подход. Но в каких-то местах, учитывая web-специфику, сталкиваюсь с непониманием того, как добиться соответствия такой архитектуре.

Несколько вопросов к толковым разработчикам относительно mvc и php?

получение по id. А создание реализовано так:
$data=array(
'name'=>get_param('name', 'string', ''),
…
'tariff'=>get_param('tariff', 'int', 0),
);
$user=user->create($data);
Если все хорошо, пользователь создается, заносятся все данные и возвращается заполненный объект класса user.