Код нужно писать не как попало, а аккуратно и по правилам. Почему? Потому, что на неакуратно написанный код не хочется даже смотреть.

Если тебе лень выравнивать код руками, закачай его на http://beta.phpformatter.com/ и нажми «format». Робот исправит выравнивание и отступы в мгновение ока (да, прогресс не стоит на месте). Если ты используешь мощную IDE вроде PhpStorm, там тоже есть функция форматирования кода.

Горячие клавиши для форматирования кода в разных IDE: https://gist.github.com/codedokode/8759492

Вообще, в PHP долгое время не было единого стандарта оформления кода, все писали как попало и было много бардака, но сейчас дело лучше — есть стандарты PSR-1 и 2. Вот как надо оформлять код:

- переменные и функции пишутся с маленькой буквы, подчеркивание не используется, используется camelCase, пример: $x, $numberOfPeople, printResults()
- Название функции начинается с глагола, в стиле «сделайЧтоТо»
- не знаешь английский? Не беда, в 21 веке есть решение этой проблемы. Не пиши транслитом, открой лучше Гугл Транслейт или slovari.yandex.ru и найди название для переменной там
- в именах классов используется CamelCase, первая буква большая, «_» может использоваться
- мы предпочитаем подстановку переменных вместо конкатенации строк: "I am $age years old" — хорошо, 'I am ' . $age . ' years old' — плохо из-за обилия точек и кавычек
- мы используем для отступов 4 пробела (можно настроить редактор, чтобы при нажатии Tab он вставлял 4 пробела)

Вот ссылка на стандарты, где все это описано подробнее и даны примеры оформления:

PSR-1: https://github.com/samdark/fig-standards-ru/blob/master/accepted/ru/PSR-1-basic-coding-standard.md
PSR-2: https://github.com/samdark/fig-standards-ru/blob/master/accepted/ru/PSR-2-coding-style-guide.md

------------------

Итак, ты зашел в тред и решил помочь какому-то анону, дав ему совет или подсказку. Спасибо! Но прочти сначала эти напоминания, чтобы твоя помощь действительно была полезной.

Давай удочку, а не рыбу

Лучше не давать готовое решение проблемы, а рассказать как его искать. Может дать ключевые слова для гугла или ссылку. Но помогай, а не пытайся показать превосходство. Если даешь ссылки на нерусскоязычные статьи, упомяни об этом.

Будь доброжелателен

Не годится: «Ты мануал хоть раз в жизни открывал, обезьяна?»
Не годится: «В гугле забанили?»
Не годится: «Твой код плохой»
Хорошо: «Вот, как можно улучшить этот код: ...»
Хорошо: «Ты неправильно используешь функцию abc(). Вот ее описание: ссылка, и как видишь ей надо передать строку, а не массив»

Не придирайся к знанию английского или русского языка.

Объясняй

Не очень хорошо: «сделай как в этом коде»
Хорошо: «если ты вставляешь текст от пользователя в SQL запрос, то получается SQl-инъекция, которая позволяет взломать твой сервер (ссылки). Чтобы этого избежать, надо вставлять данные с помощью плейсхолдеров (ссылки)»
Хорошо: «Помни, что код пишется для людей. Если писать такие большие функции, то в них становится трудно разобраться...»

Не проповедуй

Мы учим использованию самых распространненных подходов, стандартов, библиотеки фреймворков. Если ты не любишь ООП, пробелы в коде, jQuery, сам PHP, то рассказать об этом стоит в каком-нибудь другом треде.

Не придирайся к знанию английского языка, анон пишет как умеет.

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

>>1001824

Можно разбить текст на отдельные слова, каждое слово проверять, и уже в найденном слове делать замену без \b что позволит заменять любое число букв.

>>1001778

doctrine2 использует Data Mapper, Yii2 - ActiveRecord.

Для начала ознакомься с этими паттернами если не знаешь их https://github.com/codedokode/pasta/blob/master/db/patterns-oop.md

Главное отличие в том что с DM модели не привязаны к БД и не содержат кода для работы с БД. В теории, они не привязаны к доктрине тоже и в теории это позволяет заменить доктрину на другой DM, но я бы на это не рассчитывал. В то же время с Юи твои модели будут содержать код работы с БД и будут намертво привязаны к Юи.

А вообще, я с Юи и с ActiveRecord так много не работал, чтобы с ходу назвать недостатки.

>>1001338

Только вместо чисел лучше константы использовать.

>>1001858

Можно, там даже уже готовый протокол придуман (WAMP, Websocket application message protocol по моему).

>>1001207

Если много пользователей, серверу может стать тяжело.

>>1001178

Да, компоненты СИмфони не привязаны к фреймворку Симфони и их можно использовать где угодно.

>>1001154

Ты мыслишь не в парадигме REST. Идея REST как раз в том чтобы сессии были не нужны, а id нужного объекта содержался в URL.

Вот как с твоими сессиями скинуть кому-то ссылку на какую-то страницу?

>>1002685

Ты разобрался вообще в том, как работает паттерн Materialized Path? У меня такое ощущение, что пока не разобрался в теории. А просто где-то увидел пример и пытаешься сделать по аналогии, не понимая принцип.

У меня в уроке дан пример. Там путь состоит из значений, которые должны при сортировке давать нужный порядок вывода комментариев.

Для этого каждому комментарию верхнего уровня проставляется какое-то значение, которое возрастает. Например: порядковый номер, id, время вставки. Затем, когда вставляется дочерний комментарий, он наследует номер родителя и добавляет к нему собственный номер.

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

Ну к примеру путь 001.003.002 обозначает, что наш комментарий имеет 2 предков и сам список комментариев такой:

001
001.001 <- это идут дети комментария 001
001.002
001.003
001.003.001 <- это дети комментария 001.003
001.003.002 <- наш комментарий
.....

В качестве номера можно использовать разные значения: порядковый номер, начиная с 1, id, время, лишь бы они при сортировке давали нужный порядок вывода. Но порядковый номер занимает меньше места и потому выгоднее. Хотя, для его вычисления нужно делать лишний запрос.

Время хорошо тем, что его можно получить без дополнительного запроса к БД, но оно занимает намного больше места.

Если хочется оптимизировать по максимуму, то есть еще более эффективные способы хранения пути. В случае с числом, оно кодируется цифрами, каждая из которых занимает 1 байт. Байт может хранить одно из 256 значений, но мы используем только 10. Соответственно для более эффективного хранения было бы лучше задействовать какую-то систему кодирования, использующую больше символов - base64, base127 и так далее. Лишь бы она не использовала точку. Ну и надо учесть что для хранения строки используется скорее всего кодировка utf-8 и нужно чтобы используемые символы бы эффективно в ней кодировались.

Если не использовать ltree, то можно сделать путь бинарным и использовать все 256 возможных значений байта. То есть сделать например что 1, 1.5 или 2 байта кодируют один сегмент пути. А точки тогда становятся не нужны. Это дает максимальную плотность хранения данных.

Есть еще альтернативная система, когда вместо пути с точками используются дробные числа от 0 до 1, и при вставке нового комментария ему присваивается число, находящееся посередине между предыдущим и следующим комментарием. Но там нужно учесть что тип DOUBLE имеет ограничение по точности и после какой-то глубины начнут получаться одинаковые числа.

> Гугл предлагает использовать функцию lastval(), но поскольку я использую ORM придётся сначала добавлять запись в бд, а затем обновлять её.

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

>>1003364

Можно, но они написаны на языке Си. Его впрочем можно при желании тоже изучить.

Вот исходный код интерпретатора PHP: https://github.com/php/php-src

Си, как ты можешь заметить, внешне напоминает PHP, но есть и отличия:

- перед переменными не ставят знак доллара
- при объявлении (создании) переменной нужно всегда указать ее тип
- у функций также указывается тип возвращаемого значения и типы аргументов

Например код в PHP: $a = 1 соответствует такой строчке на Си: int a = 1;

Вот функция на Си, которая вызывается при вызове функции count в PHP: https://github.com/php/php-src/blob/master/ext/standard/array.c#L776

Тут видно, что идет проверка типа аргумента функции count и в зависимости от этого вызываются другие функции. Вот кусочек кода который отвечает за массивы:

> zend_long cnt; // объявляется переменная типа zend_long

> ...

> case IS_ARRAY:

> cnt = zend_array_count(Z_ARRVAL_P(array));

> ...

> RETURN_LONG(cnt);

То есть вызывается функция zend_array_count. Вот ее код:

https://github.com/php/php-src/blob/master/Zend/zend_hash.c#L295

К сожалению, чтобы его понять, придется изучить не только Си, но и способы хранения php-данных (вроде массивов). Они описаны например тут https://romka.gitbooks.io/php-internals-book-ru/

Я могу сказать, что в случае с count(), там в структуре, представляющий php массив, хранится число элементов и count просто возвращает это значение.

>>1000416 (OP)
Оп, привет.

>Но задачу на SPA хорошо бы сделать. Мало кто сейчас такие штуки умеет делать.

Я решил сделать SPA из оп-поста, немного изменив условия. Программа для сохранения и напоминания дат праздников у друзей и родственников. Функционал программы похож на тот, что в задаче "Расписание для преподавателей". Основное окно - вкладка "Расписание", где вместо студентов друзья и родственники, а вместо оценок на календаре их праздничные даты. Кликнув на день в календаре можно добавить день рождение родственника или отредактировать уже созданное. Программа присылает оповещения на почту на кануне и в день праздника.

Решил для фронт-энд части использовать React (потому, что он и Angular на Upwork делят проекты 50/50, но React новее);
Серверная часть - Silex (потому что почти Symfony).

И то, и другое, мне не знакомо. С чего начать?

План такой:
0. чтения мануалов и создание хелоувордов React/Silex.
1. определиться с функционалом, и сделать варфрейм интерфейса;
2. проектирование бд;
3. создание части функционала серверной части при помощи Silex (регистрация?);
4. верстка необходимого части интерфейса для проверки серверной части;
5. интеграция React;
6. повторение п. 4 и 5 до полной готовности приложения.

Прочел туториал Реакта про игру Tic-tac-toe, сейчас возьмусь за доки и туты по Silex.

Какую версию ES использовать, ES3 или уже можно перейти на ES2015?

>>1000396

>> Как остановить setInterval, который был вызван в предыдущем событии?

>Есть clearInterval, но проще использовать setTimeout.

>clearInterval

А как его вызвать на интервале который был вызван до него?

//После клика на другой блок, интервал на первом кликнутом блоке не остановился
https://jsfiddle.net/tux1yebv/

>setTimeout

А зачем тут setTimeout, который вызывается всего один раз с делеем? Он сбрасывает setInterval?

>> Как лучше сохранять не отправленные сообщения?

>Можно сохранять их в localStorage. Но тогда есть риск, если пользователь на каком-нибудь общем компьютере набирал сообщение, то потом его может найти и прочесть другой человек. Можно сохранять сообщение на сервер. Но тогда может человек сотрет сообщение, а на сервере оно сохранится. Тоже некрасиво.

Мне нравиться вариант с сохранением на сервер, но где именно? Можно сделать отдельную таблицу unsendedmessages в БД.

>Но тогда может человек сотрет сообщение, а на сервере оно сохранится.

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

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

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

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

А какую именно информацию нужно написать? Расположение сервера где находиться БД? Или просто уведомить о том что сообщения сохраняются либо в БД, либо локально (в течении сессии)?

А что если один пользователь захочет хранить историю а другой нет? Тогда в любом случае сообщения будут храниться в одном экземпляре (если денормализовать сообщения на inbox и outbox).

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

http://phpclub.rf.gd/pr/res/919074.html#934872

>Если ты хочешь хранить сообщения на сервере (для истории и синхронизации), то надо хранить их зашифрованными. А ключ хранить где-то в другом месте. Но может быть лучше вооще их не хранить? Или хотя бы спрашивать пользователя, хочет ли он вести запись истории или нет. Программа, которая уважает приватность пользователя, не должна ничего записывать без его согласия.

>ключ хранить где-то в другом месте

А можете посоветовать где лучше всего хранить ключ?

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

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

notify = function () {
//отсылаем уведомление
$.ajax(...);
}

getNotify = function () {
//получаем уведомление
$.getJSON(...);

setTimeout(function() {
//сбрасываем уведомление
$.ajax(...);
},

1000
);
}

$(textarea).on('keypress', function(e) {
notify();
});

setInterval(function() {getNotify();}, 1000);

Наверно, тут никакого рассинхрона не будет, я не знаю. Я слишком запутался в вопросе как работают счётчики.

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

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

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

>Также, перед проектированием АПИ, советую почитать про REST и HATEOS (и далее, стандарт про шаблоны URL https://tools.ietf.org/html/rfc6570 ), но тут конечно есть разные мнения, ну к примеру в иделогии REST одним запросом нельзя получить несколько несвязанных массивов данных, а HATEOS раздувает размер ответа.

Это мне тоже нужно сначала изучить прежде чем что-то спросить.

>Насчет MVC, там у тебя все запутано. Ну вот например тут модель лезет в DOM:

>https://github.com/someApprentice/chat/blob/master/public/js/chat.js#L51

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

Получается считать величину отступа нужно в отоброжении?

>> $('.contacts-not-found').remove();

>Вот вместо постоянного копирования этих кусков кода, обычно удобнее найти элемент и сохранить ссылку на него в переменную и далее работать с этой ссылкой. Это сделает и код аккуратнее, и заодно и ускорит работу, так как $(..) имеет сложность O(N) от числа элементов DOM на странице, там оптимизирован только поиск по id.

А где обычно создаются такие переменные? В самом вверху, перед "классами" MVC?

>Вот еще пример плохого использования jQuery: $('textarea[name="message"]').val($('textarea[name="message"]').val() + "\n");

Как тогда по другому добавить перенос на новую строку по нажатию Ctrl + Enter?

>> Contreller.prototype.getConversation = function(withUser) {

>> $.getJSON('api/getmessages.php?with=' + withUser, function(results) {

>> window.history.pushState({}, '', '/conversation.php?with=' + withUser);

> Во-первых, с историей лучше работать через JS-библиотеку, это позволит поддерживать браузеры без pushState(). Во-вторых, если со страницы диалогов вызвать эту функцию, в историю не запишется переход на ту же самую страницу? В-третьих, ты делаешь переход только после получения ответа, это плохо, так как при проблемах со связью и обновлении страницы переход не произойдет. Ну и нет обработки ошибок при выполнении запроса.

>Вообще, для работы с историей, есть такая штука, как клиентский роутер: https://www.google.ru/search?q=js+router&newwindow=1&gbv=1&sei=TWEyWc6YBYLVsAHegKrACg

Клиентский роутер это и есть JS-библиотека о которой вы упомянули в начале? Если нет, то что есть JS-библиотека в таком случае?

>Ну и нет обработки ошибок при выполнении запроса.

А что за обработка ошибок должна быть? Имеется ввиду та которая присходит при неудачном получении JSON?

>>997929
>>1000424

> Куки на 10 лет + привязка к IP-адресу.

Вообще, тут есть недостатки. У многих провайдеров динамический IP. В случае с беспроводным интернетом или с DSL-модемом - при пересоединении получаешь новый адрес. В теории можно определять по IP-адресу подсеть (через базу спарсенную с whois) и привязываться к подсети, но за 10 лет и это может поменяться, и надо поддерживать базу.

Также можно привязываться к городу, определенному по GeoIP. Опять же базу придется поддерживать в актуальном состоянии.

Так что стоит все это учитывать при привязке к IP. Так как по факту получится, что авторизация будет слетать по непонятным для пользователя причинам.

> ЗАКРЫВАЙТЕ ФОРМЫ

Эти ошибки можно обнаружить, проверив HTML код валидатором вроде этого https://validator.w3.org/ также есть какие-то расширения для браузеров, позволяющие быстро отправить страницу на валидацию.

По коду:

> https://github.com/Merkalov/Students/blob/master/README.md

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

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

Публичная папка у тебя есть, но она сделана как-то не так. Идея публичной папки в том, что в конфиге веб-сервера она прописывается как корневая папка и соответственно за ее пределами файлы недоступны снаружи. И значит index.php должен лежать в ней. Так будет безопаснее ну и как-то логичнее разделить файлы на публичные и непубличные.

Ну например сейчас у тебя можно скачать SQL дамп из-за этого.

В дампе не надо указывать имя БД, так как это не позволяет его залить в другую БД. Не нужно в дамп прописывать CREATE DATABASE.

> CREATE TABLE `info` (

Плохое название таблицы. Любая таблица хранит информацию, так что слово info ничего не значит. Также, я не очень понял зачем тут 2 таблицы для хранения информации о пользователях. Не помешал бы комментарий. Название можно было бы сделать user_profile или user_details.

Связи между таблицами надо оформить с помощью внешних ключей.

https://github.com/Merkalov/Students/blob/master/config/127_0_0_1.sql#L33

> `userID` varchar(255) NOT NULL,

Это ссылка на таблицу users? Тогда тип явно должен быть не varchar. Также, если связь 1-1, то незачем делать 2 разных id, можно сделать userId первичным ключом.

Также, у тебя там как-то непонятно сделана привязка к IP, а можно с нескольких разных IP заходить?

> `name` text NOT NULL,

TEXT позволяет хранить до 65536 байт, что явно много для имени. Нужно использовать тут varchar.

> `gender` varchar(11)

Тут лучше подойдет ENUM (или на худой конец TINYINT). В коде пол надо сделать константами.

> `numberGroup` varchar(11)

11 символов многовато для номера группы

> varchar(255)

Кстати у varchar ограничение - не 255, а по моему 65535, но фактически там есть еще ограничение на размер строки таблицы в 65535 байт, один символ в utf8 занимает несколько байт, так что реально получится меньше.

> https://github.com/Merkalov/Students/blob/master/config/127_0_0_1.sql#L161

> ALTER TABLE `users`

> ADD PRIMARY KEY (`id`),

> ADD UNIQUE KEY `id_3` (`id`),

Эти индексы дублируют друг друга.

Конфиг БД возможно стоило все же вынести в отдельный файл, чтобы не надо было править что-то в коде. При этом вынести в конфиг стоит только то, что можно менять (тип БД или кодировку нет смысла выносить).

> https://github.com/Merkalov/Students/blob/master/config/Database.php

Вот ты сделал класс-фабрику для получения объекта Medoo. А для других классов ты тоже сделаешь свои фабрики для каждого? Если нет, то почему? Ну и посоветую почитать урок про DI https://github.com/codedokode/pasta/blob/master/arch/di.md

> https://github.com/Merkalov/Students/blob/master/index.php#L6

> ini_set('display_errors',1);

Это лучше прописывать в php.ini, иначе как твой код выкладывать на продакшен?

> require_once(ROOT . '\vendor\autoload.php');

Бекслеши не работают в линуксе. Лучше использовать прямые слеши.

> define('ROOT', dirname(__FILE__));

Зачем константы? Почему не просто переменная? У переменной ограничена зона, где она доступна в то время как константа доступна глобально, что поощряет использовать ее где попало.

> //Вызов FrontController

> use Controllers\FrontController;

use ставят в самом начале файла, а не в конце. Почитай PSR-1 и 2.

> $router = new FrontController();

Одинаковые вещи нужно называть одинаково.

> $this->routes = include($routesPath);

Лучше require, почему - смотри в мануале

> $url = mb_strtolower($_SERVER['REQUEST_URI']); //в нижний регистр

> trim($url, '/');

Вот это плохая идея. У тебя из-за этого получится так, что одной странице соответствует множество URL. Это плохо и с точки зрения логики (УРЛ это ведь идентификатор страницы и он должен быть единственный) и с точки зрения поисковой оптимизации. То же касается слешей, не надо делать 2 УРЛ отличающиеся только наличием слеша. Лучше выбрать один вариант, а при неправильном расположении слешей или регистре букв можно редиректить на правильный URL.

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

> } elseif ($total == $counter) {

Как-то переусложнено. Лучше писать так:

foreach ($routes as $route) {
if (...) {
return $this->handleRoute(...);
}
}

// вывод 404 ошибки

> $controllerName = ucfirst(array_shift($segments)) . 'Controller';

Лучше просто писать имя контроллера как есть в конфиге. Тогда оно например найдется при поиске по имени класса. То же касается и имени метода (хотя это мое мнение, во многих фреймворках делают как у тебя).

Вообще, имя класса можно писать как SomeClass::CLASS - тогда оно будет проверяться на отстутствие опечаток, на то что такой класс существует, будет работать автодополнение. Как минус, будет срабатывать автозагрузка.

> self::_redirect('404', 302);

Вот я у каждого первого встречаю эту ошибку. Где такому учат? Редирект это ответ с кодом 302, он имеет смысл "искомая страница есть, но она в другом месте", а надо выдавать страницу с кодом 404. Почитай про коды статуса ответа в протоколе HTTP.

И не стоит начинать название функции с подчеркивания.

> ob_start(); //Уворачиваемя от вывода любой инфы, ведь мы всюду суём заголовки

Может лучше сначала вывести заголовки, а только потом тело страницы?

> https://github.com/Merkalov/Students/blob/master/controllers/InfoController.php#L26

> public function actionMyInfo()

> ob_start();

Зачем это тут второй раз? Есть же в фронт контроллере? И конечно не надо пытаться костылем заткнуть неудачную архитектуру.

> https://github.com/Merkalov/Students/blob/master/models/Cookie.php

Тут почему-то все методы статические. Однозначно стоит почитать про DI.

Класс Cookie назван неправильно. Он что, хранит информацию о какой-то куке? Нет.

То же самое касается метода checkCookie. "Проверить куку". Непонятно из названия, что делает этот метод, что он возвращает, а комментариев нет.

> $hash_cookie = md5($_POST['email']);

Ок, то есть зная email мы можем автоматически сгенерировать куку для авторизации от его имени?

>>997929
>>1000424

https://github.com/Merkalov/Students/blob/master/models/Student.php
Какой паттерн тут реализован? Прочитай урок, если не знаешь: https://github.com/codedokode/pasta/blob/master/db/patterns-oop.md

Класс назван неправильно. Он что, хранит информацию о студенте? Нет. Значит название должно быть другое - например, StudentTableGateway или StudentDbHelper, или что-то еще такое.

Принцип MVC у тебя не соблюдается. Идея MVC в отделении кода обработки HTTP-запроса от внутренней логики приложения, а у тебя в одном классе смешана работа с БД, разбор параметров POST-запроса, работа с авторизационными куками и определение текущего пользователя. Вот у тебя есть метод addInfo(), а как его вызвать с произвольными данными, не полученными из формы? Чтобы допустим добавить студента программно, не через форму? Разумеется, с пустыми куками?

И перечитай внимательно урок https://github.com/codedokode/pasta/blob/master/arch/mvc.md

Особенно это:

> Например, в программе на PHP Модель не должна обращаться к внешним переменным вроде $_GET/$_POST/$_SESSION/$_COOKIE и не должна ничего выводить через echo. Все необходимые данные она получает через аргументы функций, и возвращает результат через return.

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

У тебя пока нет MVC, просто ты назвал папки controllers, models и views.

> public function searchID($searchQuery)

> "OR" => [

> "name" => $searchQuery,

> "surname[REGEXP]" => $searchQuery,

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

Ну и результат поиска помещается в переменную $userID - там только один id хранится, судя по названию?

> $full_name = $database->select('info',

> return array_shift($full_name);

Что-то я не очень понимаю, там разве нет метода для выборки единственной записи?

> public function getInfoSomeStudents($startLimit, $sort, $typeSort)

Тут нет проверки переменных sort и typeSort, это безопасно? Тут не сделают SQL инъекцию?

https://github.com/Merkalov/Students/blob/master/models/Helper.php
Этот класс назван неудачно, название ничего не говорит о содержании, также, у тебя валидатор зачем-то намертво привязан к массиву POST и не способен проверять данные из других источников.

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

https://github.com/Merkalov/Students/blob/master/models/Url.php
Класс назван неудачно.

https://github.com/Merkalov/Students/blob/master/models/Page.php
Неудачное название, плохо что HTML перемешан с PHP, на пагинатор зачем-то возложена функция подсчета записей в БД, и вообще пагинатор получился неуниверсальный и его нельзя использовать с другими табличными и нетабличными данными. Опять же, ты пока не можешь отделить работу с БД от подсчета страниц и формирование URL ссылки от формирования HTML тега <a>.

У тебя маленькое приложение и вся работа с БД должна быть собрана в 1-2 классах, а не размазана по приложению.

Наверняка, тебе что-то непонятно, задавай вопросы тогда.

Также, просмотри внимательно комментарии к студентам.

Также, если вдруг не делал задачу про Вектор, то советую сделать, чтобы лучше разобраться с ООП.

>>1005452

Надо смотреть на логику.

Если ты хочешь написать функцию, которая может найти, а может не найти пользователя (то есть это ожидаемая ситуация, что он может не найтись) - тогда надо возвращать null. Но тогда ты должен проверять результат функции на этот null всегда.

При этом функция все равно может выбросить исключение - ну например если id не числовой или если не удается соединиться с БД (PDO выбрасывает исключение PDOException в этом случае). То есть мы различаем штатные и нештатные ситуации таким образом.

Если ты уверен что передаваемый id правильный и не найтись пользователь не может - то надо использовать исключение и результат можно не проверять.

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

> if (!isset($file)) {

Проверять на null надо через is_null или === null

>>1005418

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

У тебя есть return, но значение никуда не сохраняется, надо писать $x = func(...); чтобы его сохранить.

Ты же пишешь $a = mt_rand(1, 6), так же надо делать и тут.

>>1005336
>>1005325

Увы, не знаю, готового решения. Можно запилить что-то на основе http://php.net/manual/ru/class.messageformatter.php но если тебе нужен только один язык (русский), то может проще написать кодом.

В JS есть такие библиотеки: https://www.google.ru/search?q=js+time+library&btnG=Поиск&newwindow=1&gbv=1

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

То, что встроено в DateTime - это по сути интерфейс к древней сишной функции http://man7.org/linux/man-pages/man3/strftime.3.html и конечно никаких склонений она делать не умеет.

>>1005335

У него вопрос, какие есть готовые библиотеки или расширения, чтобы не изобретать то, что уже изобретено.

>>1004956

По крону запускать если нужно периодически, если одноразово, то руками в конcоли, можно через nohup, если долгая задача. Если запускать при загрузке сервера, то надо оформить скрипт как сервис в systemd.

>>1005185

Пусть будут спойлеры, что плохого-то.

>>1005145

Спам автоматизирован, боты просто ходят по интернету, ищут все формы, анализируют названия полей, подставляют в них подходящие данные и отправляют. Кроме капчи, можно проверять поддержку JS, а также делать поля-ловушки, которые не видны человеку, но которые бот может охотно заполнить. Особенно если оно называется name или email.

Что касается настройки сервера, советую читать мануалы а не статьи "как скопировать конфиг не поняв ни строчки". Я могу подсказать, если что-то непонятно.

FTP советую не использовать, он небезопасен и передает все в открытую, если есть SSH доступ, то можно использовать SCP и программы, работающие поверх SSH.

>>1005126

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

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

Уже пошли усложнения какие-то. Он монго решил подключить только для хранения частей имен ключа кеша?

То, что описано в статье, в общей форме называется "тегирование ключей кеша" и это попытка решить проблему обновления кеша. Когда значение ключа кеша соответствует какой-то одной сущности (например, пользователю) то все просто - при обновлении записи пользователя в БД мы должны обновить/сбросить соответствующий ключ кеша с тем же id.

Это называется "зависимость", то есть ключ user:123 зависит от записи в таблице пользователей с id=123 и он устаревает когда эта запись меняется в БД.

Но когда запись в кеше формируется на основе нескольких записей из БД, ситуация становится сложнее. Ну например, мы решили хранить в кеше зачем-то 5 последних постов пользователя. Теперь ключ кеша зависит от всех этих постов - если пользователь удалит или переименует пост, мы должны обновить ключ кеша. Для этого мы проставляем ключу теги с id постов, например [post123, post243, post565, post777, post 888]. Теперь, когда пользователь обновляет пост с id 888, мы находим все зависящие от этого поста ключи кеша по тегу post888 и удаляем или обновляем их.

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

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

Лучший способ решения проблем с заивисимостями - избегать их и дублирования данных. Например, в случае с постами, можно хранить в кеше только id последних постов, а сами посты брать из БД - и зависимости исчезают. А еще лучше не использовать кеш, а оптимизировать запросы к БД. Так как кеш это дублирование, создание избыточных данных.

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

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

> Это что реально оптимальный вариант кеширования динамики? Класть ключи в бд и делать класс-наследник от мемкашед?

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

Если ты интересуешься кешированием, начни хотя бы отсюда

- http://lib.custis.ru/Кэширование_в_веб-приложениях_-_что,_где,_когда
- https://www.google.ru/search?q=кеширование+в+веб-приложениях&newwindow=1&gbv=1&sei=o4tAWcHbLsri6ATJtL34Bg

>>1004995

Ручками PHP, а если надо, то и Апач. В Оп посте есть частичная полезная информация.

>>1004895

> А что, например, нужно затачивать для этого?

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

Ну например, одна из проблем баз данных - число транзакций (изменений данных) в секунду. Она упирается в необходимость сбросить данные на диск и дождаться ответа о том, что данные физически записаны на поверхность диска (или в ячейки флеш-памяти, если это SSD), а не находятся где-то в кеше ОС или кеше жесткого диска. Только после получения ответа от ОС, что данные сброшены, СУБД сообщает клиенту (PHP коду) о завершении транзакции. Операция сброса на диск по моему назвыается sync() в Линуксе.

Причин, почему есть такое ограничение, много:

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

Проще говоря, если ты выполняешь COMMIT и база данных ответила что он завершен (и PHP код выполняется дальше) то это значит что данные сохранены на диске надежно, что даже при пропадании питания они никуда не денутся. Если же питание прервется до завершения коммита, то в теории невыполненная транзакция просто должна будет откатиться, когда сервер включат и запустят сервис базы данных, и никакие данные не должны повредиться.

Случайный доступ относительно медленный. В тестах дисков всегда меряют 2 скорости - скорость последовательного чтения или записи большого файла и скорость случайного чтения 4Кб кусочков (соответствуют размеру сектора). И если первая скорость меряется десятками и сотнями мегабайт в секунду, то вторая намного меньше, особенно на магнитных (не SSD) дисках. В магнитных жествикх дисках головка может перемещаться только по радиусу (между дорожками). Магнитный диск крутится, и надо дождаться, пока нужный сектор окажется под головкой, потом перемещаться на другую дорожку, снова ждать. При скорости 15 000 обор/мин, мы имеем 250 оборотов в секунду и это ограничивает число операций случайного доступа, даже если предположить, что головка перемещается мгновенно.

Чтобы меньше ждать, СУБД кешируют сектора с данными в памяти - в MySQL это наызвается innoDB Pool cache. В этом случае нам не надо тратить время на чтение сектора, он уже есть в памяти. Но с записью ждать все равно приходится.

На SSD этой проблемы нет, но там есть свои особенности, замедляющие запись. Там для записи данных необходимо полностью очистить большой блок данных (сохранив данные из него) и записать в него изменнные данные. Контроллер SSD пытается поддерживать резерв пустых блоков и очищать их в фоне, но тут есть свои ограничения.

Информацию об этом можно поискать где-то тут на англ

- https://dev.mysql.com/doc/refman/5.7/en/optimization.html
- https://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html

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

Но например, система, которая бы вместо случайного доступа использовала последовательную запись в файл, могла бы достичь гораздо большей производительности. Проблема с индексами может решаться асинхронным обновлением индексов (при этом они чуть будут отставать от данных, но это иногда допустимо). Еще можно повысить производительность, если отказаться от выполнения sync при каждой вставке, ценой потери данных за последние N секунд при аварии.

Также, разработчики вконтакте выложили код некоторых своих хранилищ, и там есть интересная информация по теме:

- https://github.com/vk-com/kphp-kdb/blob/master/docs/ru/DBMS_Storage_Comparison.wiki
- https://github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Texts.wiki

Вконтакте использует специализированные хранилища на Си, которые оптимизированы на работу с разными типами данных (сообщения, лайки, фото, списки друзей, поиск). И конечно для максимальной скорости чтения они стараются все данные хранить в памяти.

Интересно ваше мнение про передачу параметров в методы классов. Это очень важный вопрос, который сводит меня с ума долгое время, надеюсь на feedback опытных программистов. Прочитайте вдумчиво.
Пока выполнял студентов, столкнулся с тем, что мои классы, связанные с отображением, требуют много разнообразной и слабо связанной между собой информации. Например, на скриншоте под постом отображению страницы требуются:
список студентов $students,
текст для показа режима работы сайта пользователю,
массив (возможно, пустой) текстовых сообщений пользователю,
набор ссылок для перемещения по результатам данного поискового запроса.
Для передачи параметров есть следующие способы:
1) Передавать параметры в виде набора аргументов (так передаются параметры внутреннему методу контроллера на первом пике).
Преимущества: сразу видно, какие данные и какого типа нужны методу извне; легко получить контекстную помощь IDE, меньше грамматических ошибок.
Недостатки: любое изменение параметров метода заставит менять сигнатуры всех его вызовов (добавлять/убирать параметр); невозможно использовать метод при наследовании или объявить в абстрактном классе.
2) Передавать параметры в виде array или arrayObject. В т.ч. рекомендуемый ОПом DependencyContainer.
Преимущества: можно использовать одну сигнатуру для всех вызовов метода даже в случае, если в методе что-то сильно меняется.
Недостатки: полностью отсутствует контекстная помощь IDE; приходится подглядывать а) в справку метода, где нужно описать подробно все необходимые записи в array и их тип, б) в source класса, который я хочу передать в качестве параметра. Если я хочу передать в array объект StudentMapper, то IDE мне не поможет, придётся лезть в StudentMapper и смотреть, какие аргументы требуют его методы; вероятность ошибки возрастает стократно. Если это не дно, то где оно?
3) Передавать параметры в виде объекта класса, в котором отдельными методами захардкодены типы получаемых данных и объектов. То есть, нелюбимый ОПом паттерн Registry.
Преимущества: можно использовать одну сигнатуру; можно использовать контекстную справку IDE внутри метода, которому передан Registry.
Недостатки: если делать Registry один на несколько клиентских классов, то в него придётся пихать данные для всех этих классов, тем самым в Registry будет маловразумительная каша, и класс, который передаёт параметры клиенту через Registry не будет точно знать, какие данные клиент оттуда возьмёт. Следовательно, IDE не сможет подсказать, от каких зависимостей (dependencies) зависит клиент.
Если же писать Registry отдельно для каждого клиентского класса или метода, то нужно написать много дополнительных классов. Помощь IDE станет лучше, но не будет идеальной.

Итак, какой метод вы предпочтёте в такой ситуации и почему? Если можно изменить ситуацию, то как бы вы это сделали?

>>1005668

Идея такая: вот у нас есть страница, или кусок страницы, и мы хотим как-то добавить ему интерактивности с использованием MVC. Модель, понятно, с этим куском страницы никак не связана, с ним работают только контроллеры и вью. И тут уже появляются разные варианты, кто (из пары представление-контроллер) будет ведущим, кто занимается инициализацией, создаем ли мы DOM программно или навешиваемся на уже существующий, если создаем, то кто это делает, и тд.

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

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

class Controller
{
init()
{
// инициализируем представление, задав обработчик для кнопки
$('#some-button').click(this.handleSomeButtonClick.bind(this));
}

handleSomeButtonClick(e)
{
...
$('#some-field').text('Hello');
}
}

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

init()
{
// Вью можно и не создавать, а передавать снаружи, но не очень
// понятно, в чем выгода
this.view = new SomePageView(...);
this.view.findSomeButton().click(this.handleClick.bind(this));
}

handleClick()
{
this.view.findSomeField().text('Hello');
}

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

Можно усилить инкапсуляцию так, чтобы вью не выдавал ссылки на элементы DOM наружу:

init()
{
this.view.setButtonClickHandler(this.handleClick.bind(this));
}

handleClick()
{
this.view.setSomeFieldText('Hello');
}

Это позволит нам например сделать консольный вью, выводящий информацию в консоль, а не на страницу, и подсунуть его контроллеру.

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

class SomeView
{
// Контроллер можно передавать снаружи, а не создавать
init(controller)
{
controller.setView(this);
this.findSomeButton().click(controller.handleClick.bind(controller));
}

setSomeFieldText(...) { ... }
}

Наконец, есть еще варианты, когда контроллер и представление объединяют в один класс (React например предлагает такую возможность).

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

Если добавить модель, то конечно ситуация становится сложнее, можно попытаться прочитать этот большой урок https://github.com/codedokode/pasta/blob/master/js/minesweeper-mvc.md

Хочу предупредить также, что разделение ответсвенности может привести к увеличению объема кода.

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

В твоем простом случае с 3 дивами я бы просто сделал один ВьюКонтроллер.

>>1005631

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

>>1005629

>>Контроллер отвечает за обработку команд пользователя.

> То есть внутри него должны вызываться события?

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

> Ещё я заметил у себя такое переусложнение

У тебя пока там все очень сумбурно, и по моему это пока не MVC. Ты должен сначала определиться, кто за что отвечает, а у тебя там просто код без всякой логики раскидан.

Ну например у тебя перемешан поиск элеиментов с логикой обработки событий и туда же вставлен код отправки аякса-запросов, по всему коду раскиданы конструкции вроде $('.message:first-child'). Это, по моему мнению, плохой стиль. Гораздо удобнее было бы вынести поиск элементов куда-то отдельно, в метод или сохранить ссылки на них в переменные. И вынести взаимодействие с АПИ тоже отдельно. У тебя нет никакого разделения, просто код идет стеной, как у начинающих.

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

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

> хотя можно было просто написать $.get(...).

Не забудь только прочитать мой урок про работу с аяксом.

> Если события должны будут быть вне классов, то если разбить код на компоненты, события относящиеся к этим компонентам должны быть сразу под ними?

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

То есть мы разбиваем интерфейс на компоненты, и делаем их максимально независимыми друг от друга. Это упрощает код, так как мы можем рассматривать компонент отдельно от других. И мы можем его тестировать отдельно от других. А когда разделения нет, нам приходится анализировать большой объем кода и можно запутаться.

Это компоненты еще иногда называют виджеты. В архитектуре MVC у каждого виджета будут свои контроллер, вью и ViewModel (ViewModel - это модель, управляющая не данными и бизнес-логикой приложения, а данными отдельно взятого компонента).

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

Компоненты используются в программировании графических интерфейсов в Windows, на андроид. Ну например, в Андроиде есть готовые компоненты вроде "поле ввода", "выпадающий список", "поле выбора даты", и тд.

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

Уточняй, если что-то непонятно.

>>1005616

Обычно при выводе шаблона используют второй подход (метод вида render($template, array $args)). Так например работает шаблонизатор Twig. Так приходится писать меньше кода. Но вообще, другие подходы тоже имеют право на жизнь.

Ну например, мы бы могли завернуть шаблон в функцию и описать все параметры и их типы:

<?php
function showIndexPage($a, $b, $c, Something $something) {
?>
... код шаблона...

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

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

Можно в этот класс добавить метод render, который будет вызывать шаблон так, что объект будет доступен через $this. Но тогда это будет уже не ViewModel, а View. Что-то похожее было в ZF1, там был объект Zend_View.

Что касается кода с третьей картинки, то в нем все явно смешано в кучу. Я вижу, что ты передаешь Registry в конструктор View, это явно плохая идея, так как в шаблон лучше передавать какие-то конкретные данные, а не все объекты-сервисы. Зачем в шаблоне объект PDO? Он там точно использоваться не должен. И data mapper в шаблоне не нужен. Не забывай, что задача View - отображать переданные ему данные, а не самостоятельно их получать.

> 1) Передавать параметры в виде набора аргументов

Вполне нормальный способ.

> Недостатки: любое изменение параметров метода заставит менять сигнатуры всех его вызовов (добавлять/убирать параметр);

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

> невозможно использовать метод при наследовании или объявить в абстрактном классе.

Не понял, почему. Думаю, что можно.

> Передавать параметры в виде array или arrayObject.

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

> В т.ч. рекомендуемый ОПом DependencyContainer.

Это совсем не то. DI Container используется для получения сервисов (например дата мапперов, валидаторов). В шаблон его передавать незачем, и эти сервисы там не нужны. Ты что-то путаешь.

> 3) Передавать параметры в виде объекта класса, в котором отдельными методами захардкодены типы получаемых данных и объектов. То есть, нелюбимый ОПом паттерн Registry.

Нет, если это класс, который написан специально для данного шаблона, то правильнее это назвать ViewModel.

- http://design-pattern.ru/patterns/registry.html
- http://designpatternsphp.readthedocs.io/ru/latest/Structural/Registry/README.html

Обычно Registry называют глобально доступный реестр (не написанный специально под конкретный шаблон). Хотя иногда Registry может быть расположен внутри какого-то класса и исплоьзоваться только им. Например, в Зенде были всякие реестры плагинов, хелперов, обработчиков и еще чего-то.

Такие понятия как DI container, registry - они относятся не к передаче данных в шаблон, а к поиску сервисов, зависимостей для класса. Конечно, View не должен обращаться ни к DI Container, ни к Registry.

Задавай уточняющие вопросы, если что-то еще непонятно.

>>1005181

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

>>1005169

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

Читай урок https://github.com/codedokode/pasta/blob/master/php/strings-utf8.md

В моем учебнике тоже описаны функции (mb_...), которые надо использовать.

> http://ideone.com/32QpwQ йода

> (\\.)|(\\!)|(\\?)

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

> foreach ($arrayOffers as $key=>$value){

Плохие названия переменных. $key не нужна, а $value надо было назвать $sentence (предложение). array писать в названии переменной не надо, достаточно множественного числа.

> [\s]+

Квадратные скобки не требуются.

Ошибки надо исправить:

> PHP Notice: Undefined variable: editedText in /home/z0nZFe/prog.php on line 14

> PHP Notice: Undefined variable: editedTextFull in /home/z0nZFe/prog.php on line 18

> $editedText = strtolower($editedText);

Этой строчкой ты многократно обрабатываешь уже обработанный текст, это неэффективно.

Названия переменных довольно неудачные.

> http://ideone.com/XnwxXg сумма прописью

> $millions = array(

> 0 => 'миллионов',

> 11 => 'миллионов',

> 1 => 'миллион',

Ну тут одно и то же повторяется. Этот массив не нужен, так как в русском слово может быть в одной из 3 форм в зависимости от 2 последних цифр числа и надо просто написать несколько ифов, выбирающих 1 из 3 вариантов.

Код у тебя написан длинной стеной. Такой код трудно читать и трудно использовать. Надо разбить его на отдельные функции.

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

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

Вдобавок внизу там ошибки:

> PHP Notice: Undefined variable: text in /home/XTUN1t/prog.php on line 118

> PHP Notice: Undefined variable: numberOn in /home/XTUN1t/prog.php on line 139

> http://ideone.com/9fc5tF калькулятор

Не хватает вывода окончательного ответа.

> http://ideone.com/8hUwnm считалка

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

> http://ideone.com/MSiND0 вертикальный текст

$array, $value - неудачные названия переменных.

Определить максимальную длину строки можно с помощью array_map и max.

> $longHigh = ($longHigh>$long)? $longHigh : $long;

Тут стоило использовать max()/min()

> PHP Notice: Undefined variable: longHigh in /home/09pNsX/prog.php on line 13

Ошибка

> ($array as $key => &$value){

Зачем тут & ?

Ну и код отформатирован не по стандарту, смотри второй пост треда.

>>1005145

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

>>1004889

> А как его вызвать на интервале который был вызван до него?

В clearInterval надо передать идентификатор таймера, который вернула функция setInterval. Это уже твоя проблема, куда его сохранить.

> //После клика на другой блок, интервал на первом кликнутом блоке не остановился

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

> А зачем тут setTimeout, который вызывается всего один раз с делеем? Он сбрасывает setInterval?

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

> Мне нравиться вариант с сохранением на сервер, но где именно? Можно сделать отдельную таблицу unsendedmessages в БД.

Можно. Можно назвать ее drafts.

Хотя конечно с точки зрения приватности не очень хорошо сохранять неотправленные сообщения на сервере.

> Тогда нужно сделать чтобы сообщение отправлялось каждый раз как пользователь его меняет. Не будет ли это создавать большую нагрузку на БД, если, например, делать это на добавление\удаление нового символа или хотя бы нового слова\перевода строки?

Конечно, будет создавать и нагрузку и трафик. Но нам наверно и не требуется каждую секунду его сохранять.

> Даже не знаю что лучше, сохранять сообщения локально и подвергать пользователя тому, что его неотправленные сообщения украдут,

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

> Или просто уведомить о том что сообщения сохраняются либо в БД, либо локально (в течении сессии)?

Я думаю, что можно вывести краткое напоминание и/или тут же ссылку на настройки или кнопку. Например так: "История переписки сохраняется в вашем аккаунте на сервере. [Подробнее]"

> А что если один пользователь захочет хранить историю а другой нет? Тогда в любом случае сообщения будут храниться в одном экземпляре (если денормализовать сообщения на inbox и outbox).

Тут возможны варианты. Можно сделать, чтобы у каждого была своя история со своими настройками, можно - чтобы не было.

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

> А можете посоветовать где лучше всего хранить ключ?

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

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

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

> Получается считать величину отступа нужно в отоброжении?

да, а еще лучше попробовать решить проблему средствами CSS.

> А где обычно создаются такие переменные? В самом вверху, перед "классами" MVC?

Логично сделать их свойствами объекта View.

> Как тогда по другому добавить перенос на новую строку по нажатию Ctrl + Enter?

Я имел в виду не копипастить $('textarea[name="message"]') два раза.

> Клиентский роутер это и есть JS-библиотека о которой вы упомянули в начале? Если нет, то что есть JS-библиотека в таком случае?

Я имел в виду библиотеку для управления историей. Вроде history.js https://github.com/browserstate/history.js/

>>Ну и нет обработки ошибок при выполнении запроса.

> А что за обработка ошибок должна быть? Имеется ввиду та которая присходит при неудачном получении JSON?

Ну например, если отсоединиться от Интернета, как будет работать твой код?

Вообще, наивно было бы думать, что ajax-запросв всегда сработает успешно. Вот что может произойти:

- может нарушиться связь с интернетом, или произойти проблема где-то на полпути. Это проявляется в том, что срабатывает обработчик ошибки с кодом 0. Причем в неудачных случаях, если пакет для установления TCP соединения потерялся где-то в сети, он сработает только после таймаута в 30-60 секунд.
- сервер может быть отключен/недоступен
- на сервере может произойти ошибка, это проявляется в HTTP статусе ответа, не равном 200, или в неверном Content-Type ответа
- при попытке раскодировать JSON может произойти ошибка, если он некорректный

Вопрос, как твое приложение будет вести себя в этих случаях? Или в случае поездки в метро, когда интернет появляется и пропадает периодически.