а как же другие протоколы которые поддерживают браузеры?)))

а как же другие протоколы которые поддерживают браузеры?)))

веб сокеты?)

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form

но браузеры не поддерживают всех методов http verbs, как же так?

https://softwareengineering.stackexchange.com/questions/114156/why-are-there-are-no-put-and-delete-methods-on-html-forms

и?

а как же другие протоколы которые поддерживают браузеры?)))

ну браузер теперь умеет больше чем WEB был на момент 98-ого года, логично ж

термину REST уже лет 17-18

и описывал он не то "как надо" а "почему мы сделали так"

не стоит зацикливаться на этих 4-ех буквах

это стопорит прогресс

rest всего лишь лежит поверх http, который используется далеко не только в браузерах

где ты в браузере rest видишь я хз

rest всего лишь лежит поверх http, который используется далеко не только в браузерах

https://en.wikipedia.org/wiki/Representational_state_transfer#History

миру показали MVC, спустя n лет - "вы не так его поняли и используете!" та же ситуация с rest, oop и тд

миру показали MVC, спустя n лет - "вы не так его поняли и используете!" та же ситуация с rest, oop и тд

ну тип того, SOA и микросервисы еще вспомни

это бесконечный цикл "размазывания понятия" и "ребрендинга"

где ты в браузере rest видишь я хз

ищи первоисточники и будет понятно)

сейчас REST воспринимается людьми как http based rpc

и это нормально, просто люди начинают спорить о том что правильно или нет. Есть персонажи которые говорят "ну у rest спецификация же есть"

а можно не тратить на это время и развивать технологии. Вон чуваки из фэйсбука плюнули на этот самый "rest" и замутили graphql. Что-то координально новое? нет. Просто новый формат для rpc

есть gRPC еще)

да, вполне годная штука

но graphql проще

flux - что-то координально новое? нет. Просто ребрендинг MVC 79-ого года

микросервисы - что-то координально новое? actor model существует уже лет 50

flux - что-то координально новое? нет. Просто ребрендинг MVC 79-ого года

flux - это скорее не про MVC, а про CQRS

flux - это скорее не про MVC, а про CQRS

нет

да

да

нет)

да))

короч обоснуй свою мысль)

где ты видишь паралели с CQRS а я напишу где есть паралели с MVC

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

как представлена модель - это просто объект который работает со стэйтом, это ивент стрим и редьюсеры и т.д. - это не важно

это больше похоже на CQS нежели на CQRS

а CQS похоже на MVC)

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

а CQRS это чуть более глобалььная штука, это архитектурный стиль

MVC на фоне CQRS мелкий паттерн

как и flux

так идея flux не в том, что мы делим на слои или вроде того, а идея в однонаправленом потоке данных

так идея flux не в том, что мы делим на слои или вроде того, а идея в однонаправленом потоке данных

а как ты думаешь сколько направлений данных было у smalltalk mvc 1979-го года?)

подсказка, меньше двух и больше нуля

один в один flux

вот тут неплохо разобраны именно что отличия от mvc http://fluxxor.com/what-is-flux.html

http://fluxxor.com/images/mvc-simple.png

ну типа так и есть, только стрелочка notifies в другую сторону - там же направление зависимости

> As an MVC application grows and controllers, models, and views are added, the dependencies become more complex. а вот это легкий булшит

не, ты не понял ;) то, что flux похож на mvc не значит. что это mvc. Этак любую трехслойную архитектуру можно назвать "похоже на mvc".

не, ты не понял ;) то, что flux похож на mvc не значит. что это mvc. Этак любую трехслойную архитектуру можно назвать "похоже на mvc".

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

а то что при масшиабировании можно "сделать плохо" - ну да. как буд-то бы с flux так же сделать нельзя (я если что видал те проблемы которые приписывают к mvc для приложений с flux)

а ну и еще - "controller updates model" - категорически не правильно

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

он просит модель что-то сделать, но напрямую ничего не меняет

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

да причем тут многослойность? MVC это один слой

это презентационная логика

"модель" в контексте MVC это лишь точка соприкосновения приложения и UI

вершина айсберга

> Но и различаютя отсуствием роли контроллера, там за него две другие роли типа диспатчер?)

модель это модель ;) бизнес-логика

то есть я беру mvc, вместо вызова методов из "контроллеров" диспачку команду (типа событие), которое ловит стор и редьюсит в стэйт... и у меня выходит flux, так?

модель это модель ;) бизнес-логика

почитай Тургве

твое определение слишком размытое что бы быть полезным

а фаулера можно почитать заместо? ;)

у него вводится Presentation Model

так что можно)

https://martinfowler.com/eaaDev/uiArchs.html

если что - в оригинале у MVC были еще editors

она вводится как альтернатива, как расширение mvc

это по сути штуки которые инициировали действия

так что флоу данных был такой: model -> view -> editors -> controller -> model ....

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

Сергей, так много англицизма =)

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

как бы не то, что бы какие-то глобальные или инновационные отличия, но они есть, имхо, достаточные, что бы не называть flux === mvc

как бы не то, что бы какие-то глобальные или инновационные отличия, но они есть, имхо, достаточные, что бы не называть flux === mvc

flux ~= mvc

но никак не cqrs)

ну про cqrs я махнул, да... скорее что-то близкое просто к command bus

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

вот типа flux их и учит делать все через одну трубу

Ребят, помогите плз - не могу понять суть ошибки... Делаю загрузку нескольких тысяч записей. Сохраняю (flush + clear) по 500.

A new entity was found through the relationship 'AppBundle\Entity\Reference\DeliveryService\Region#deliveryService' that was not configured to cascade persist operations for entity: MaxiPost (code: MaxiPost, id: 2). To solve this issue: Either explicitly call EntityManager#persist() on this unknown entity or configure cascade persist thi s association in the mapping for example @ManyToOne(..,cascade={"persist"}).

Вылезает на 2-й итерации - когда счетчик покаызвает 1000

В таблице есть одно поле - которое одинаково для всех заполнено

почему часть отрабатывает тогда а потом падает с ошибкой?!

поле это с заранее записанным значением - 100% подставляется во все создаваемые элементы в коллекции

ну иначе бы вылетело на 1-й строчке еще

MaxiPost сохраняется не внутри цикла случайно?

Ребят, помогите плз - не могу понять суть ошибки... Делаю загрузку нескольких тысяч записей. Сохраняю (flush + clear) по 500.

после clear() entity manager уже не знает никаких сущностей. Чтобы с ними работать, нужно их подгружать заново (ну или merge)

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

MaxiPost сохраняется не внутри цикла случайно?

да - это в цикле

по коллекции которая заранее подготовлена

и в элементы которой уже вставлена ссылка на другой объект

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

Всем привет. Есть env переменная: root@0b57e0151649:/app# printenv |grep REDIS_HOST REDIS_HOST=pmcache Пытаюсь ее получить $this->getParameter('env(redis_host)') Результат null. в parameters.yml parameters: env(REDIS_HOST): null Что не так?