Иван М: Договорённости уже были. Программист уверяет, что он их выполнил до момента оплаты. Заказчик свою часть уговора не выполнил и требует отдать ему код. Если программист докажет, что его работа удовлетворяет условиям договорённости, он вправе требовать от заказчика оплаты. После оплаты программист может отказаться от второго этапа работ по той причине, что старые договорённости потеряли актуальность. Как минимум потому, что он договаривался с одним менеджером, а теперь другой. О чём бы они не договорились, это будут новые договорённости и другая цена.
Ну и, наконец, можно не использовать формы, а всю логику обработки массива впихнуть в save моделей. Но тогда туда пойдёт валидация, если она вообще нужна.
PhP_Raz: Ну тут уже мелочи остались. Начнём с теории: в мускуле есть схемы данных InnoDB и MyISAM. InnoDB имеет Внешние ключи. Но ORM пишутся с учётом того, что в системе таких ключей может не быть. Поэтому, исходим из условий оценки задания: если оно подразумевает работу со внешними ключами, можно писать коннектор под InnoDB. Если нет, пишем механизм связывания руками. Твоя задача - инкапсулировать механизм создания связей.
1. Пишем коннектор к БД. Пишем юнит-тест, который проверяет наличие соединения.
2. Пишем класс Category. Всё что делает этот класс - реализует CRUD для категорий. Связь пока не делаем. Делаем тесты на CRUD. Убеждаемся в том, что запись проходит нормально.
3. Пишем класс формы для категорий. Пусть в этот класс передаётся ассоциативный массив {'title'=>'value', 'id'=>'value or null'}. Класс проверяет правильность данных и запускает метод update, если есть id или create, если его нет. Пишем тест этой формы
4. Теперь нам нужны представления: четыре страницы Create, Read (View), Update, Delete. Причём, create отличается от update только тем, что вьюха будет передавать в форму id категории. За неимением нормального роутера (я бы взял этот, просто используй GET параметр. например 127.0.0.1/category_form.php?id=1. Аналогично делаем для category_view и category_delete.
5. Пишем класс Comment. С ним посложнее. В методе save ему можно будет передавать categories. Это список айдишников. Здесь мы не будем проверять, что айдишник реальный. Просто пишем код, который создаёт или изменяет объект. При сохранении нам надо пройтись циклом по списку айдишников категорий и проверить, что на каждый айдишник существует строка в таблице cat_id, где comment_id - равно айдишнику текущего коммента (не забудь, что метод сперва создаёт запись, а потом добавляет связанные объекты), а category_id равно айдишнику, на котором находится цикл. Удаление производится либо каскадом, если ты применял внешние ключи, либо ты вручную пишешь логику удаления cat_id, а потом comment. Проверяем тестами, что работает CRUD с пустым списком категорий и что работает CU с айдишниками в массиве. Тестируем удаление категории со связями.
6. Пишем класс формы для класса Comment. Принцип работы такой же, как у Category.
7. Наконец, пишем вьюхи для Comment. Не забывай, что на create/update надо получать список существующих categories и выводить их в select multiple.
8. На десерт - апдейтим класс Comment и учим его удалять cat_id если категория удаляется.
Crash: О да: мультипоточность, обработка HTML, обработка структурных данных, попутно можно peewee подключить и изучить оптимизацию SQL запросов. Потом понадобится подключить рендеринг с отработкой JS, и в дело включается node.js. Scrapy - не знаю, просто как Второе Пришествие Христа. Немного чистилища, и ты в раю :-D
Надо попросить ребят из phpinfo специально для Вячеслава написать статьи "Почему юнит-тестирование в PHP не имеет web-gui" и "Почему не надо начинать писать свою CMS, если вы ещё недостаточно знаете PHP"
Иван М: Это уже не проблемы разработчика. Если только он не суперпрограммист, который по ночам помогает обиженным директорам, бесплатно делая для них сайты.
Иван М: Я не говорю, что надо просить или требовать или намекать на повышение. Я сказал, что надо сдать то что есть и не задерживаться на таком проекте. Есть много хороших проектов, где платят много и вперёд, и менеджеры шутят в онлайне каждый день.
Иван М: Общение с директором - самое последнее, до чего можно довести взаимодействие вообще. Именно поэтому я предлагаю сперва пройтись по задачам и понять насколько вообще проект завершён. И валить с этого проекта, потребовав оплату прежде предоставления кода. Всё абсолютно честно. А если этот проект реально приоритетный для заказчика, он поднимет цену и программист окажется в обоюдовыгодных условиях. Потому что если человек сейчас поддастся на уговоры и останется на проекте, директор с 90% долей вероятности компенсирует за его счёт потерянного менеджера, а новый менеджер взбодрит исполнителя новыми условиями. Проходили всё это уже давно. Меняется менеджер - приготовься к изменению ТЗ и работе за еду... ну а в худшем случае, помойка с объедками есть в каждом дворе.
Иван М: заказчик не заплатил ни рубля. Авторские права принажлежат разработчику. Пусть заплатит или на бумаге признает факт сделки, а потом качает права.
Therapyx: Вообще, у Дмитрия наверху более правильный вариант. Только arrSound надо из условия убрать. И я бы настаивал на идентичности, а не эквивалентности. Впрочем, если айдишник может передаваться как строкой, так и числом, то лучше использовать эквивалент.
Therapyx: Для строк это не обязательно, но желательно. В JS == означает эквивалентно. Т.е. 1 эквивалентен true, например. Строка '15' эквивалентна целому числу 15. А знак === означает идентичность, и проверяет не только значение, но и тип данных. Поэтому, логично использовать при таких проверках идентичность, а не эквивалент. Но это ИМХО.
