>>714996

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

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

>А зачем тебе полная таблица? Тебе достаточно знать сколько кофе потребляет конкретно этот сотрудник. Можно ведь просто сделать в нем поле с базовым значением потребления кофе для этой профессии. Тогда будет так:

>$coffee = $ivan->getCoffeeConsumption();

Ну я вообще теперь запутался...
У меня же так и было с самого начала (просто поле было в конструкте с кофе, зарплатой, страницами), а ты посоветовал добавлять это автоматизированно?
Или я снова всё путаю уже в час ночи...
У меня сейчас ближе к тому, что - как мне показалось - ты потом советовал и сейчас говоришь. Только getCoffeeConsumption() называется getCoffeeByProfession(), но там перебор по ассоциативному массиву "профессия" => "количество литров" идёт.

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

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

>Затем можно добавить методы найма/увольнения. И имя департамента надо ведь хранить где-то.

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

>>715328

>в конце описания функции мы return'ем количество прошедших месяцев.

Нет, лучше вернуть $paymentTotal - чтобы сравнить именно по этой величине все банки.

>Но в последний месяц школьник, скорее всего, отдаст не 5000, а меньшую сумму.

Тэкс, тэкс, что тут у нас? Ещё один новичок, который идёт по учебника ОПа не по порядку, перескакивая задачи? Ну наконец-то!
Покажи решение задачи на Айфон. В задаче про Айпад специально второй банк имеет те же параметры, что и в задаче про Айфон, - чтобы проверить правильность работы скрипта.

>получается, что, скажем $homoCreditTotal = $creditSum + ($payOut * ($monthsPassed (4, 500)) - 1) + та сумма, которую школьник отдаст в последний месяц

Переусложнение, вообще не понятно, что здесь что. Пробуй сначала про Айфон решить, по всему видно, что не решал.
>>715331
Можно вернуть массив.
function testReturn()
{
$one = 1;
$two = 2;
$three = 3;

$array = [];

$array[] = $one;
$array[] = $two;
$array[] = $three;

return $array;
}

$array = testReturn();

$one = $array[0];
$two = $array[1];
$three = $array[2];

echo $one;
echo $two;
echo $three;

Либо, как ОП посоветовал, в функции:
$array = [
'one' => $one,
'two' => $two,
'three' => $three
];
А дальше:
$one = $array['one'];
$two = $array['two'];
$three = $array['three'];

>>716401
class queue extends Model
{
protected function checkNodeExist(){
//проверка на существовании ноды в таблицах "очередь" и "ноды"
}
protected function enqueue($nodesArray = []){
//добавить в очередь
}
protected function dequeue(){
//удалить из очереди (первая запись в таблице)
}
protected function processingQueue(){
//проверить нажата ли пауза, пуста ли "очередь", достигнуто ли максимальное количество записей на выборку.
//достать первую запись из таблицы "очередь"
//если очередь не пуста, то
// {
// checkNodeExist()
// если ноды нет, то getLinks::getLinksArray;
// enqueue()
// добавить ноду в таблицу "ноды"
// добавить ребра в таблицу "edges"
// dequeue()
// обновить вид "очередь" (удалить обработанную ноду и добавить из неё новые ноды)
// обновить вид "ноды"
// }
}
public static function getQueue(){
//"очередь" через websockets отправляется в вид.
}
}

https://github.com/someApprentice/Students

>>714627

>Далее, тут https://github.com/someApprentice/Students/blob/master/app/Test/validAllStudents.php#L9 много однотипных строк. Это плохо тем, что когда мы например добавляем с студента новое поле, мы должны найти это место и не забыть добавить сюда еще одну строку. Это нелогично. надо чтобы была функция которой на вход можно дать студента и которая его проверит.

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

class Entity
{
public $name;
public $password

...
}

class Validations
{
public function validFields(Entity $entity)
{
$errors = array();

foreach ($entity as $key => $value) {
switch ($key) {
case "name":
//valid name and return error

...

return $errors;
}

Или же сделать тоже самое только обернуть это в функцию? У меня уже есть такая, только она подходит для проверки формы, а не студента

https://github.com/someApprentice/Students/blob/master/app/Model/Validators/Validations.php#L151

Я не хотел переделывать или добавлять функцию для тестов

>>714636

>> Стоит ли переделать класс в универсальный хелпер для всех классов, а не только для регистрации? Например, функция перенаправления подойдет для всех классов.

>Перенаправления там вообещ не дложно быть. Редирект - это выдача HTTP заголовков, а взаимодействием с GET/POST данными и формированием ответа занимается контроллер. Хелпер не должен этим заниматься.

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

Если реализовывать редирект в контроллере а не в хелпере, то получится что хелпер совсем не нужен, потому что даже функцию получения данных из $_POST я перенес в класс формы

https://github.com/someApprentice/Students/blob/master/app/Model/Entity/RegisterStudentForm.php#L13-L85

>>716773

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

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

$errors = $validator->validateStudent($student);

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

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

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

> Или же сделать тоже самое только обернуть это в функцию? У меня уже есть такая, только она подходит для проверки формы, а не студента

> https://github.com/someApprentice/Students/blob/master/app/Model/Validators/Validations.php#L151

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

> Если реализовывать редирект в контроллере а не в хелпере, то получится что хелпер совсем не нужен, потому что даже функцию получения данных из $_POST я перенес в класс формы

И пусть.

> https://github.com/someApprentice/Students/blob/master/app/Model/Entity/RegisterStudentForm.php#L13-L85

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

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

У тебя есть места, где в классе находится код, который должен быть не в нем. Вот что выглядит сомнительно:

- форма обращается к POST, но работать с POST это задача контроллера, а не формы
- RegistrationHelper.php обращается к GET данным в функции redirect. Почему ты сделал функцию которая может работать только с данными в GET['go'] в то время как мог бы передавать адрес для редиректа через аргументы и получиь универсальную функцию, не завязанную на массив GET?
- в модели студента есть метод хеширования пароля, но не лучше ли если бы он был в хелпере отвечающем за авторизацию? Если посмотреть, этот метод вообще к $this не обращается и непонятно что он там делает в классе студента.
- методы генерации соли и токена - не лучше ли разместить в классе авторизации?

Вот еще логическая ошибка:

https://github.com/someApprentice/Students/blob/master/app/Model/Helper/RegistrationHelper.php#L8

> $post = null;

> $post[$key] = is_scalar($value) ? $value : '';

У тебя в переменной null, а ты пытаешься с ней работать как с массивом. Разве можно в null доабвлять элементы? Конечно PHP тут тихонечко преобразует null в пустой массив (и это плохо, это недоработка в пхп, лучше бы он выдавал ошибку), но возникает вопрос: а почему с самого начала не положить туда пустой массив? Почему null?

> https://github.com/someApprentice/Students/blob/master/app/Controller/RegisterAction.php#L28

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

$data = [
'name' => 'Ivan',
'xzzzzzzz' => 123456
];

$form->fillFromArray($data);

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

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

Еще мне не очень нравится это:

> if (!count(array_filter($registerStudentForm->getErrors()))) {

Это длинно и неудобно. Я вызвал функцию вадидации и теперь должен еще писать какой-то громоздкий код, чтобы узнать есть там ошибки или нет. Предлагаю сделать список ошибок объектом ErrorList такого вида:

$errors->hasErrors() - возвращает есть ли ошибки или нет
$errors->getError('name') - возвращает текст ошибки для поля
$errors->hasError('name') - возвращает есть ли ошибка в данном поле

> https://github.com/someApprentice/Students/blob/master/app/Controller/RegisterAction.php#L42

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

Но если задуматься, какой в этом смысл, хранить 2 копии данных? Не проще ли внутри формы хранить сам объект студента с данными? Тогда и валидация упростится. И вообще все упростится.

Вот представь что мы хотим взять модель студента и заполнить форму его данными. Сколько для этого кода надо? А хотелось бы чтобы это делалось в 2-3 строчки:

$form->setStudent($sudent);

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

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

Наконец обрати внимание еще на это место:

> https://github.com/someApprentice/Students/blob/master/app/Controller/LoginAction.php#L42

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

if ($authService->isValidPassword($student, $password)) {
$authService->login($student);
....
}

Простые действия (проверить пароль студента) должны делаться простым кодом.

Для авторизации не стоит исплоьзовать сессию. Она же устаревает и удаляется через 20-30 минут неактивности. Лучше просто использовать куку с id и хешем пароля.

>>717749
Почитал про ранжирование, ничего не понятно.

Даже в подробной статье разработчиков на хабре.
https://habrahabr.ru/company/sphinx/blog/62287/

>BM25 ... зависит от частот ключевых слов в текущем документе с одной стороны и общем наборе документов (коллекции) с другой

Что такое "общий набор документов (коллекции)"? Все записи индекса, или только текущая выборка?
Неважно, в моем случае частота меня не интересует. Мне нужна степень совпадения посимвольно.

>proximity (вес фразы) ... совсем не учитывает частоты, зато учитывает взаимное расположение ключевых слов запросе и документе.

Вроде то что нужно.

Это были поисковые факторы (bm25 и фактор веса). Теперь режимы ранжирования. Могут комбинировать факторы, например

>SPH_RANK_PROXIMITY_BM25 комбинирует вес фразы с BM25

SPH_RANK_PROXIMITY и SPH_RANK_BM25 вычисляют вес только в зависимости от одного фактора. Тут главное в терминах не запутаться: "proximity" это фактор веса, а конечный вес, или ранг, вычисляется по заданному алгоритму (режиму).

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

Стоп, так значит этот вариант скорее вернет вначале выдачи полное совпадение? Единица это же максимальный ранг?
Как тогда будет вычисляться ранг фразы по SPH_RANK_PROXIMITY?
Вот у меня слово 'world' и два документа 'hello world' и 'world'. Какой из них будет выше рангом?

Походу результат будет одинаковый. Вот они приводят пример
1) query = one two three, field = one and two three
field_phrase_weight = 2 (совпала подфраза "two three", длиной 2 ключевых слова)

2) query = one two three, field = one and two and three
field_phrase_weight = 1 (отдельные слова совпадают, но подфразы нет)

Значит 'world' даст один и тот же результат (единицу) и при полном совпадении, и частичном. Или нет? Совпала подфраза "world", длиной одно ключевое слово. Даст единицу? В случае 'hello world' совпадет одно отдельное слово, тоже единица. Значит меня это не устраивает.
Это мы говорим про SPH_RANK_PROXIMITY.
SPH_RANK_BM25 вроде бы колеблется от 0 до 1, и при полном совпадении дает единицу.

Про комбинированный SPH_RANK_PROXIMITY_BM25 ничего не известно. Используется по умолчанию.

Есть еще всякие SPH_RANK_WORDCOUNT, SPH_RANK_MATCHANY, но эти более специфические.

Ладно, с такой документацией придется императивно (методом тыка) выяснять, какой из режимов необходим.
И все вот это ради того чтобы прописать одну несчастную опцию, здорово, да?

>>717846

Про BM25 можно прочесть например в википедии:

сначала https://ru.wikipedia.org/wiki/TF-IDF
потом https://ru.wikipedia.org/wiki/Okapi_BM25

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

- того, как часто искомые слова встречаются в одном найденном документе
- какая доля всех документов содержит эти искомые слова
- отношения длины данного документа к средней длине документов

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

> Мне нужна степень совпадения посимвольно.

сфинкс ищет по словам, а не по символам. А BM25 учитывает частоту появления слова и длину документа. Документ состоящий только из искомого слова, будет иметь высокий BM, а если слово редкое то - очень высокий. Удели время гуглению и изчению особенностей этого индекса.

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

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

О! Чтобы лучше понять, как это работает, могу дать такую задачу. Попробуй написать как должен выглядеть поисковый индекс, чтобы по нему можно было считать BM25 и PROXIMITY, не запрашивая из базы полный текст документа (сам понимаешь, запрос тысяч документов из огромной БД быстро работать не будет). В поисковых системах обычно используется индекс такого вида:

слово1: ... информация по этому слову ...
слово2: ....

Там ключом является слово. Это позволяет шардить индекс на много серверов, выделяя каждому серверу определенный диапазон слов (типа сервер 1 = от А до В, сервер 2 = от Г до З и так далее.)

Вот, подумай, как должен выглядеть индекс, что в нем должно храниться, чтобы по нему можно было получить ид документов, где есть все искомые слова, и их рейтинги BM25 и PROXIMITY.

>>proximity (вес фразы) ... совсем не учитывает частоты, зато учитывает взаимное расположение ключевых слов запросе и документе.

> Вроде то что нужно.

Это другое. Это фактор который показывает как близко слова в документе, то есть если ты ищешь hello world то

- для фразы a well known hello world program - коэффициент большой
- а для фразы hello is a word you can say to the world - маленький так как слова далеко друг от друга

Потому он и называется "фактор близости".

> Вот у меня слово 'world' и два документа 'hello world' и 'world'. Какой из них будет выше рангом?

proximity тут не применим так как запрос состоит из одного слова.

> Ладно, с такой документацией придется императивно (методом тыка) выяснять, какой из режимов необходим.

> И все вот это ради того чтобы прописать одну несчастную опцию, здорово, да?

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

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

>>717903

Тут такая штука. К сфинксу нельзя делать мультизапрос (или можно?), когда тебе надо найти не одно слово, а много. А вот к mysql можно, через in.

Потому можно конечно и в mysql попробовать сделать таблицы

words <--> dictionary

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

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

> Но я не в курсе возможностей и производительности этого поиска,

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

>>717972

на руби и ноде говорят, то же самое.

>>717992

как писать код без тайп хинтов?

>>717993

В Друпале все сделано через так называемые ноды, и страница - это наследник этой ноды. И есть АПИ которое позволяет их создавать и вставлять в базу. Вот с ними и надо разобраться. Учти, что это небыстро и не одну страницу длкументации придется прочесть. Я когда-то давно что-то такое делал.

>>717994

Там есть АПИ для вставки нод в базу, надо его исопльзовать. Оно позволяет вставить страницу программно.

>>718036

Надо проверить телефон на правильность. если неправильный - так и пиши. Если правильный - убираешь минусы, скобки, пробелы, а +7 в начале заменяешь на 8 и выводишь. То есть надо привести номер к единому формату вроде 81234567890, если он правильный.

> Ну и как мне это заменять?

echo preg_replace('регулярка ищущая минусы, скобки, пробелы в любом числе', '', $number);

>>718066

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

>>718073

Можно массив сделать.

>>718079

Зависть?

>>715010 (OP)
Прохожу собеседование

Есть класс, который умножает 2 числа.
Как сделать так, чтоб он умножал модули чисел, при этом не изменяя код класса, интерфейса и строки с выводом результата.
Т.е. вызов echo $multiplier->multiply(2, -5);
должен вывести 10.

[code]
// Не менять
interface MultiplierInterface
{
// Не менять
public function multiply($x, $y);
}

// Не менять
final class Multiplier implements MultiplierInterface
{
// Не менять
public function multiply($x, $y)
{
return $x * $y;
}
}

$multiplier = new Multiplier();

// Не менять
echo $multiplier->multiply(2, -5);
[/code]

Как изменить метод multiply ? Класс же final там ничего нельзя сделать, наверное?

>>718142

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

> Придется править xml, позаменять все <tr> на что-то более приличное и залить обратно.

> Исходник 150 мб, десктопный редактор такое еле открывает, а тут еще поиск с заменой.

> Надо попробовать что-то консольное, типа sed.

Во-первых для работы с XML есть DOM. загружаешь дерево и обходишь узлы, генерируя новое HTML-дерево. Какой sed? Во-вторых, конвертировать можно и в процессе вывода, а можно и заранее, добавив колонку с html-версией статьи. В-третьих ты не должен был изначально выводить XML в HTML код. tr в словаре и в HTML значат совсем разные вещи. В четвертых, еще есть XSLT для конвертирования XML в XML/HTML по заданным правилам.

>>718145

> $dbuser = 'root';

Ты задумывался, что значит эта строчка? Никто тебе не даст на бесплатном хостинге доступ из под рута, да еще и без пароля.

Алсо ты используешь mysqli, ты не забываешь после каждого действия с базой ставить if и проверять результат, не вернул ли он false?

>>718152

Это не при чем.

>>718167

Тебе - (пока) нельзя. Пропускать можно только тем кто хорошо разбирается в спецификации HTML и знает правила подстановки тегов.

> Если их разрешается не использовать, зачем они нужны?

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

> , т.к. доктайп хтмл5 выглядит как открывающий хтмл тег

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

>>718887

Можно использовать Entity References. Это по сути прокси-модель - та же самая штука, что заменяет реальные связанные сущности когда ты находишь одну запись по id. Я советую разобраться в концепции прокси-объектов, как они делаются. Прокси нужны, так как объекты связаны друг с другом и если грузить все связанные объекты, то мы в итоге можем загрузить в память половину базы. Однако реализровать их не так просто. Смотри, какие условия должны соблюдаться:

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

То есть все эти трансформации должны происходить прозрачно для кода. ORM должен создавать для кода видимость что граф объектов находится в памяти и абстрагироваться от наличия БД.

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

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

Ну и есть еще второй вариант. Доктрина оптимизирована на упрощение написания кода и абстрагирование от БД, а не на операции над огромным числом объектов. Вполне возможно что в твоей ситуации проще в репозиторий добавить метод который бы обновлял данные в БД напрямую, через SQL запрос. Не забудь что после этого данные в памяти могут устареть и хорошим тоном было бы как-то найти в Entity Map сущность для которой обновлены связи, и как-то ей об этом сказать. Например заменить коллекцию старых связей на новую, ленивую (ленивую чтобы не грузить только что вставленные данные). И большими буквами написать про это в комментарии к методу. Ну подумай в общем, как избежать расхождения в данных .А то если ты сохранишь свой объект потом, вполне возможно что старые данные перезапишут те что в базе. Может конечно и нет. Погугли, там есть методы вроде refresh которые говорят обновить модель данными из БД. Подойдут ли они тут?

>>719439

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

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

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

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

Вот в помощь мануал по оптимизациям:

http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/improving-performance.html
http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/batch-processing.html (это хороший вариант для кли скриптов где удобство важнее скорости)
http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/change-tracking-policies.html

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

> CREATE TABLE `shortdict`

> CREATE TABLE `fulldict`

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

https://github.com/nsdvw/Memtext/blob/master/web/index.php
Тут становится много текста. более того, так как определения сервисов прописаны в индексе, мы не можем например писать консольные скрипты. Пора подумать, а не вынести ли всю инициализацию (начиная с автозагрузки и заканчивая заполнением контейнера) в отдельный bootstrap скрипт?

Насчет этого: https://github.com/nsdvw/Memtext/blob/master/config/yaml/Memtext.Model.ShortDict.dcm.yml - на мой вкус, отдельный конфиг это полная ерунда. Ты правишь класс и надо искать этот конфиг и проверять все ли там поля соответствуют друг другу. Мне кажется гораздо удобнее использовать аннотации (заодно узнаешь что это такое, это взяли из Явы, правда там они аж на уровне языка поддерживаются).

Может YAML это вариант для тех случаев когда ты не можешь править классы? Я вообще не очень понимаю, где он мог бы пригодиться?

https://github.com/nsdvw/Memtext/blob/master/app/Form/LoginForm.php
По идее наверно проверка логина должна быть в сервисе залогинивания, а не в форме, нет?

У Симфони кстати есть модуль валидации (в том числе через аннотации на модели) и модуль форм, но не знаю, не сложноваты ли они. Вот валидацию я бы советовал тебе посмореть, может что пригодится http://symfony.com/doc/current/book/validation.html

Не советую в форме делать так:

public function __construct(Request $request)

лучше сделать отдельный метод parse/processRequest.

В качестве хранилища данных в форме не уместнее ли использовать саму модель? Хотя это сложный вопрос, например Симфони Формс позволяют привязать модель к форме, но там каждый виджет хранит свои данные в себе, а в нужный момент они копируются из/в модель.

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

В сфинксе, ты ищешь по словам только id статей словаря? Тогда нет смысла его использовтаь, быстрее будет наверно сразу искать слова в mysql. сфинкс еще бы имел смысл как кеш, если бы сразу возвращал статьи или если бы ты использовал функции вроде стемминга.

https://github.com/nsdvw/Memtext/blob/master/app/Service/LoginManager.php#L35

> public function validateLoginForm(LoginForm $form)

Это явно ошибка в архитектуре. Почему сервис должен что-то знать о форме (которая тесно связана с view и controller)? А если будет еще одна форма, ты еще метод допишешь?

Должна быть либо валидация вынесена из формы и форма вызвает сервис валидации, либо валидация сделана в форме и форма сама лезет в репозиторий.

Вместо setcookie лучше ставить их через Слим, используя Response/Request (а лучше не их, а только коллекции кук из них). Не знаю как лучше внедрять его - сервиси по идее не должен зависеть от реквеста, так что может надо сделать его не синглтоном в контейнере, а сделать так, чтобы он создавался в начале обработки запроса. нe представь что мы например захотим поменять модель работы приложения и сделать чтобы приложение было консольным, само слушало порт, принимало HTTP запросы, посылало ответы. Тогда setcookie не будет работать, и твой сервис тоже. И сервис не может тогда зависеть от реквеста так как при каждом запросе у нас новый объект реквеста.

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

>>719439

> $this->repo->findOneBy( ['email'=>

можно писать findOneByEmail(...)

> https://github.com/nsdvw/Memtext/blob/master/app/Service/LoginManager.php#L15

> public function __construct(EntityRepository $repo, $token) {

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

Также, заведи привычку перед каждым классом (сервисы, модели) писать доккомеент с кратким описанием зачем он нужен и за что отвечает, хотя бы одно предложение. Для контроллеров конечно это не надо , там обычно и так очевидно.

> $entity = '\Memtext\Model\ShortDict';

> $repo = $this->entityManager->getRepository($entity)

надо бы сделать алиас вместо неймспейса

> https://github.com/nsdvw/Memtext/blob/master/app/Helper/HashGenerator.php#L27

> return sha1($salt . $password);

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

$signature = hash($password . $orderId . $sum . $comment . $accountNumber)

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

https://github.com/nsdvw/Memtext/tree/master/templates
делай подпапки по именам контроллеров (разделов сайта) например. Старайся чтобы вещи относящиеся к одной странице (контроллер, шаблон, скрипты, стили, префиксы ксс классов) формировались по единой системе и не надо было задумываться как тот или иной файл называется.

https://github.com/nsdvw/Memtext/blob/master/templates/csrf_inputs.twig
Нельзя имя сделать фиксированным? Что то я не вижу в чем смысл передавать 2 параметра.

https://github.com/nsdvw/Memtext/blob/master/templates/register_page.twig
Если будет время, прикрути клиентскую HTML5 валидацию. Подумай, как решить проблему с тем что правила валиадции хранятся в 2 разных местах.

>>719477
Спасибо за наводку, буду разбираться.

>>719481
Для этого нужно выучить xml+xlst (+ потом еще что-нибудь как всегда всплывет по цепочке), оцениваю в 3-4 недели.
Я не экономлю время, а выстраиваю приоритеты. Не могу (сейчас) бросать все и садиться учить xml ради того, чтобы заменить один тег.
Гораздо приоритетнее сейчас разобраться с доктриной, некоторыми компонентами симфони (а может и со всеми? я так понял, что симфони это модульная штука, ее можно собирать из пакетов как линукс).

>>719490

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

Мне не пришло в голову. Когда встал вопрос о поиске по слову, сразу вспомнился сфинкс, поэтому быстро и решительно впихнул его. Тем более в сфинксе есть морфология (стемминг), в mysql насколько я знаю только в полнотекстовых индексах (и те работают или в негодном myisam, или новейших innodb; у меня до сих пор 5.5 стоит)

Что дает твой вариант с новой таблицей:
+ не использовать сторонние движки типа сфинкса
(других преимуществ не вижу)
- таблицу со словами придется заполнять, писать скрипт который будет брать каждую запись из большого словаря и бить на слова, сохранять связи; ну это не сложно, но все же лишнее телодвижение
- дополнительные джойны
- (скорее всего) невозможность морфологии; я имею ввиду что мне нужно находить "say" по запросу "said" или "saying"

Что дает сфинкс:
+ прост)))
- нужен сфинкс

>Сейчас уже наверно смысла менять нет

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

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

Кстати, как правильно работать с ветками в гите? Вот у меня есть допустим рабочий проект. Я им доволен, но решаю попробовать кардинально поменять логику (например сменить технологию). Старую версию гробить не хочется. Пока создаю новую ветку для фиксации состояния, а потом переключаюсь обратно на мастер-бранч и делаю что хочу.
Проблема в том, как одновременно внести изменения в то место кода, которое общее у обеих веток? Допустим, я работаю в главной ветке, тут обнаружил баг, который есть и в старой ветке. В главной я его пофикшу, а во второй ветке? Переключаться на нее и дублировать изменения не вариант, наверняка есть хорошее решение. Может быть для кого-то "очевидное".

>>719534

>почему сделано 2 таблицы, а не одна?

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

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

>модуль форм, модуль валидации

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

>если бы ты использовал функции вроде стемминга

Использую, это важно.

>>719545

>$signature = hash($password . $orderId . $sum . $comment . $accountNumber)

>Можешь ли ты найти тут уязвимость?

Прям заинтриговал. Профессионалы годами не догадывались об этой уязвимости, а я должен знать?
Ну что, тут строка от пользователя ($comment) подставляется прямо в формулу. Мне лично это напомнило sql-инъекцию, когда хакер внедряет код в запрос.
Возможно здесь что-то подобное? Не знаю. Я не разбираюсь в технологиях шифрования.
Есть ли у пользователя возможность "подсунуть" в формулу пустые строки вместо $orderId, $sum, $comment, $accountNumber?
Если есть, он получит хеш этого "закрытого ключа". Из хеша наверное легко получить ключ перебором или из радужных таблиц.

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

>Если будет время, прикрути клиентскую HTML5 валидацию.

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

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

Вынести куда-то в конфиг. Подставлять в html
<input type="email" pattern="{{ pattern|raw }}"> // для имейла впрочем браузер самостоятельно проверяет наличие @, но нам бы еще точку
В js
<script>var rules = {{ rules|json_encode|raw }}</script>

>Нельзя имя сделать фиксированным? Что то я не вижу в чем смысл передавать 2 параметра.

Этот файл уже нигде не используется, забыл удалить этот мусор, остался от странного пакета, который в слиме предлагают использовать для защиты от csrf
https://github.com/slimphp/Slim-Csrf
Там какая-то петрушка с сессиями, куча параметров для инпутов, решил дропнуть этот пакет и написать свой класс (пока не разберусь с хорошей библиотекой).

>>719668

> Да, по-дурацки получается, но ничего не могу поделать. Не могу придумать качественную архитектуру, но очень хочу писать код.

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

А вообще, ты знаешь 3 паттерна реализации наследования таблиц в SQL? Если нет, нагугли и изучи Class Table Inheritance, Concrete TI и Single TI.

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

Ну ладно

> И в симфони я глянул, там тоже используется, например для описания роутов, так что в будущем пригодится.

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

> я так понял, что симфони это модульная штука, ее можно собирать из пакетов как линукс).

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

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

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

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

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

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

Советую поизучать их, в том числе код посмотреть, может что интересного подчерпнешь.

> Есть ли у пользователя возможность "подсунуть" в формулу пустые строки вместо $orderId, $sum, $comment, $accountNumber?

Есть. Там такой сценарий:

- пользователь на сайте магазина оформляет заказ
- магазин подсчитывает все и создает форму оплаты, в скрытые поля которой записывает все эти параметры заказа + подпись. В качестве action указывается обработчик на сайте платежной системы.
- пользователь в браузере отправляет форму на сайт платежной системы, и кончено он может менять содержимое полей. Но подпись как раз и предназначена для защиты от этого.

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

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

> Если я угадал

нет

> то в моем случае уязвимости нет, соль не общая для всех пользователей,

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

> <input type="email" pattern="{{ pattern|raw }}

Для емайл наверно все таки не надо писать паттерн.

> pattern="{{ pattern|raw }}"

raw кстати это неправильно. Значения атрибутов экранируются.

>>719724

Можно сделать 2 джойна на answers. Или сджойнить, сгруппировать и проверить через HAVING.

>>719739

> Дет пример видел, там в комментариях перед классом пишут @inject и перечисляют названия классов.

> Потом, при создании объекта, какая-та хуета читает ту строку комментариев перед классом и впрыскивает в указанные в @inject классы. Это типа круто, это DI.

Нет. Это autowiring для DI или что -то вроде этого. Это просто вспомогательный синтаксис.

> Сервис локатор это тот самый контейнер с набором классов, типа pimple, который передается в конструктор класса с зависимостями. Если он тоже DI, то что такое локатор в таком случае?

Сервис локатор это когда ты передаешь контейнер в конструктор и это плохо (разве что в контроллерах так делают). Читай мой урок https://gist.github.com/codedokode/e1d31a31b37d5f635057

Ты по моему все усложняешь. DI это когда зависимости передаются в класс снаружи. Вот и все. Для DI не требуются контейнеры или аннотации. У тебя каша в голове.