Apple_ins: тут даже я вас не понял. Во первых, я бы не называл это "Отправка данных в фоновом режиме?", так-как можно спутать действительно с фоновой отправкой данных через консольные утилиты.
Тоесть ajax запрос у нас должен происходить по нажатию на кнопку. Используя дидукцию и логическое мышление с помощью гугла попробуйте для начала просто сделать так, чтобы alert('Hello') или console.log('Hello') срабатывали при нажатии на вашу кнопку.
Второе, это то что нужно понимать, вы делаете самый обычный запрос на URL. Не соединение, не коннект на файл, а просто запрос на URL, который в свою очередь может быть чем угодно (по теме).
Поэтому вначале заставьте работать ваше событие и отпишитесь.
Максим Тимофеев: Скажу сразу, я на него пересел не по своему желанию, а потому, что так решило руководство из-за его дикой популярности за рубежом. По с равнению с Yii2, почти все такое-же, разница может быть в том, что laravel5 чуть более грамотнее спроектирован, возможно в целом сообщество чуть сильнее, в целом с Yii2 на Laravel5 и обратно вполне легко мигрировать. Работая с laravel5 я открыл для себя несколько новых подходов, возможно еще несколько фитч, которые не знал как применить в yii2, но в целом можно сказать, что инструменты из одной серии.
Могу сразу сказать несколько небольших минусов Laravel5:
- Фасады. Это весьма раздражающий паттерно, вроде можно и подменить все туда и сюда, но без доп. плагинов у вас не будет автокомплита в ide
- Дока. В этом плане Laravel5 по сравнению с Yii2 отдыхает.
- Еще заметил такую штуку, что в Yii2 куча джунов, они сидят не парятся и пишут лапшекод. В ларавеле сидят, такие как я, которые типа "горе-архитекторы" и выдумывают реализации всяких там паттернов. В результате можно наблюдать весьма большое разнообразие в подходах.
- AR все-же мне больше нравится в Yii2, хотя по большому счету, по возможностям она почти одинаковые. Но опять таки даже с ide плагином автокомплита в laravel5 AR нет.
В общем мне кажется любые фраэмворки, где есть AR, почти одинаковые. Что cake, что yii, что laravel. Будет 80% всего одинакового, пару ответвлений в какой-то паттерн типа Фасада, дока где лучше, где хуже а в остальном только к синтаксису привыкать.
Я щас посматриваю в более глубокие дебри ооп, а то, что в Yii2, что в Laravel5 сидит AR, а эта штука мне весьма приелась.
Согласен, но тут вопрос изоляции и подмены репозитория в случае чего. А часто этот случай появляется, когда нужно оптимизировать запросы к базе. Вы наверно намекаете, на то, что 99% проектов не стреляют и не получают посещаемость, при которой уже нужна оптимизация.
В любом случае мне даже с точки зрения обучения интересно как это можно разрулить. В случае с симфони не совсем вас понял, там же по проекту гуляют сущности, а не модели. Сущности как правило не несут в себе логику. Но в любом случае нужна обертка по верх доктриновских репозиториев, на случай той-же оптимизации и получания данных с помощью чистого SQL.
GavriKos: это понятно. У меня скорее всего есть беспокойство на счет скорости работы. например не сильно ли 10 - 100 итераций рекурсии замедлит выполнения скрипта? А что если 100 - 1000 ?
Не знаю как бредовое, но например ходили слухи. что некоторые языки программирования весьма плохо переваривают рекурсии. Когда-то натыкался на статью про node.js, что там обычным выражением с не очень большой глубиной ложили скрипт секунд на 10. Было что-то такое:
Сергей Протько: поразмыслил над вашим предложением хранить в поле jsonb. Во первых, я не уверен, что mysql его поддерживает, возможно в версии 5.7 что-то там упоминалось за json. Во вторых, я вспомнил, как когда-то давно в детстве хранил картинки в json и это весьма не очень хорошая практика.
Давайте предположим, что у меня есть картинки к товару, которые имею еще некоторые свойства, например картинка по умолчанию, а еще есть ALT и TITLE для сео, а если еще и мультиязычность, то тут потребуется приличная логика, для гарантии целостности данных и их сохранения. Тянет на парочку отдельных сервисов.
Что касается управления бд, тут иногда возникают задачи, которые нужно весьма быстро выполнить через консоль или скажем через navicat, минув приложение. Поэтому я бы не пологался только на доктирину в плане целостности данных.
Интересная штука, то что я пытаюсь реализовать. Как-то читал про это, но не понял, что имеется ввиду. Щас более понятно, после небольшого больного опыта. Вот только фаулер как обычно упомянул вскользь в 2 словах. Есть где-то более-менее "ровная" реализация сего паттерана ?
Поэтому внушительную часть логики можно вынести на сервер баз данных. Я не сторонник этого, но я сторонник того, чтобы все было максимально по понятиям и устойчиво как к потере данных, так и к структуре.
Поэтому я не могу свыкнуться с мыслью, что можно запить на базу, на ключи и тп. Как минимум ключи проставляют индексы. что способствует ускорению работы бд.
Если вернуться к теме вопроса, по поводу связанности ассоциаций, я всеравно не совсем понимаю ход ваших мыслей. Если обратиться к доке: docs.doctrine-project.org/projects/doctrine-orm/en...
можно заметить, что они делают так-же.
И тут есть момент, что допустим products_images бесполезны сами по себе и используются только в контексте товаров, что касается связанности товара к products_images, то он уже связан методом:
public function addImage(\AppBundle\Entity\Image $image)
{
$this->images[] = $image;
return $this;
}
Но тогда, для изображений не проставляется id автоматически, для этого я добавляю:
public function addImage(\AppBundle\Entity\Image $image)
{
$this->images[] = $image;
$image->setProduct($this);
return $this;
}
В другом случае, я просто не могу понять, как вписать id товара в запись к изображению ?
Сергей Протько: ну не знаю, вроде в доках написано, что можно не беспокоиться о связанности в пределах бандла. Плюс, база - это хранилище, куда может иметь доступ не только проект с доктриной, и если нужно будет оставить базу, а все остальное выкинуть и переехать на другие технологии, тут весьма проблематичный вопрос выйдет.
Я придерживаю позиции, что база это отдельная сущность, которая должна быть спроектирована отдельно от технологий, который с ней работают. К проектированию баз есть свои подходы, нормальные формы и тп.
Проектировать сущности это куда удобнее чем актив рекорд, но это не должно ломать базу, обходя ключи, делая данные более неустойчивыми к целостности.
Сергей Протько: В json у меня был уже печальный опыт хранения. Честно, я больше в это дело не мокнусь. Что касается ключей, это еще одна гарантия целостности бд. По поводу many2many, тут тоже не могу вас понять, почему, так как требуется 3 таблицы и запросов больше, следовательно и нагрузка выше. И это ради того, чтобы уйти от связанности изображений товара, который вне его контекста бесполезны. Что-то тут не то, мы точно понимаем друг друга ?
Тут картинки, которые строго принадлежат к продуктам. Они не могут о них не знать, ибо у нас внешний ключ и еще несколько моментов. Разве, продукт не будет aggregate root для картинок (его картинок) и прочих вещей, которые относятся непосредственно к нему.
Да я в процессе чтения, там не всегда все раскрываете, и не все моменты мне нравятся. Например была мне нужна такая штука, как полиморфические связи, но они подразумевают отсутствие ключа, а мне это не нравится, поэтому отказался и не использовал.
Сергей Протько: спасибо, попробую разобраться. Я только учу английский, попробую разобрать видос детально. А что вы скажете по zf3 ? Или вообще что, посоветуете для рест апи ?
Сергей Протько: По поводу смены инструмента это я образно. Скорее речь и дет о подмене различных реализаций. Вот например я "горе-архитектор" не правильно понял суть и весьма плохо спроектировал архитектуру на laravel5. Я хотел завернуть весь актив рекорд в репозитории и построить поверх всего свои обертки, но не совсем получилось, так как модели (под моделями в данном контексте подразумеваю АР класс.) как гуляли, так и гуляют по проекту.
Вообще меня AR расстраивает, что это "Божественный класс", который может творить адские вещи, например в виде можно сделать что-то типа такого: $product->save(). Да в любом месте можно так сделать, где есть "модель", а они везде.
Сегодня я весь день крутил доктрину, и скажу, что зря я не делал этого раньше. Тоесть пришло много понимания и включился свет, освещающий темные стороны.
Сейчас думаю провести рефакторинг своих наработок, но не уверен, что laravel5 + doctrina это хорошая идея. Это будет напоминать пересаженную почку, и в команде, кроме устного регламента не использовать AR ничего не будет действовать.
Смутил Ваш комментарий относительно развития симфони, можно блее подробнее ? И за одно что думаете про zend3 ?
"Вы должны понимать что в доктрине вы оперируете не табличками в базе, а объектами. " - я понимаю, как раз именно по этому начал смотреть уже более детально в симфони, по дальше от всяких там актив рекордов.
"А коллекция сама выполнит persist новой сущности. Таким образом количество репозиториев уменьшается до количества корней агрегатов сущностей. " - это тоже понятно, так-как я тоже оборачивал актив рекорд в репозитории (не совсем удачно, но это за темой).
"Не используйте напрямую доктриновские репозитории. Пишите свои, а в них уже юзайте доктриновские. Не стоит размазывать доктрину по всему проекту, потом это будет нереально поддерживать." - вот, вы ответили на мой следующий вопрос. Спасибо.
Теперь собственно вопрос, из-за чего меня напрягли коллекции. К примеру, я все обернул в обертки все хорошо. И вот я хочу сменить фраемворк. Например как сейчас, я хочу мигрировать наработки с laravel5 на symfony3. У меня не получится сделать контрл ц + контрл в, так как я не много напил и модели по всему проекту у меня все-же гуляют.
Но если взять ситуацию с симфони, и я захочу мигрировать скажем на зенд. Мне нужно будет переписать репозитории. НО к примеру у меня репозитроий возвращает сущность, в которой реляции, которые используют коллекции доктрины. А мигрировать я буду на зенд или на чистый пхп, который знать не знает о коллекциях доктрины. Соответственно, если я внутри проекта буду использовать методы коллекций, я автоматом привязываю свое приложение к доктрине. Как собственно этого избежать ?
Во вторых, я так подозреваю, что вы вообще понятия не имеете, как это должно работать. Поэтому первое, что вам нужно сделать, это понять тему событий jquery.page2page.ru/index.php5/%D0%A1%D0%BE%D0%B1%...
Тоесть ajax запрос у нас должен происходить по нажатию на кнопку. Используя дидукцию и логическое мышление с помощью гугла попробуйте для начала просто сделать так, чтобы alert('Hello') или console.log('Hello') срабатывали при нажатии на вашу кнопку.
Второе, это то что нужно понимать, вы делаете самый обычный запрос на URL. Не соединение, не коннект на файл, а просто запрос на URL, который в свою очередь может быть чем угодно (по теме).
Поэтому вначале заставьте работать ваше событие и отпишитесь.