похоже ему просто плохо с document стилем... родной клиент с ним тоже не очень, к слову ;) но обычно решается просто немного другим порядком вложенности объектов подаваемынх на вход... в родном. А в том, что этот клиент нагенерил, тут я хз, с ним не работел

похоже ему просто плохо с document стилем... родной клиент с ним тоже не очень, к слову ;) но обычно решается просто немного другим порядком вложенности объектов подаваемынх на вход... в родном. А в том, что этот клиент нагенерил, тут я хз, с ним не работел

В том то и дело, что если отправить запрос как в первом варианте, то вызов срабатывает на ура. Но на второй запрос он ругается на: <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>Server was unable to process request.</faultstring> <detail> <OTA_ErrorRS ErrorCode="UNHANDLED_EXCEPTION" ErrorMessage="Object reference not set to an instance of an object."/> </detail> </soap:Fault>

похоже ему просто плохо с document стилем... родной клиент с ним тоже не очень, к слову ;) но обычно решается просто немного другим порядком вложенности объектов подаваемынх на вход... в родном. А в том, что этот клиент нагенерил, тут я хз, с ним не работел

Вообще, Ping - это название метода. И как он умудрился указать тип для метода, я не могу разобрать.

в document стиле нет названия метода в теле...

А в качестве параметра он принимает тип OTA_PingRQ

по-этому подавайте на вход Ping у которого внутри OTA_PingRQ

по-этому подавайте на вход Ping у которого внутри OTA_PingRQ

Да, в идеале, так и должен был получить на выходе. Но Я не могу понять почему он так делает. Почему он указывает OTA_PingRQ в качестве атрибута Ping

вот если хотите немного в теме быть https://www.ibm.com/developerworks/library/ws-whichwsdl/ - про стили... в rpc стиле там в body идет имя метода, а у вас скорее всего document стиль (гляньте wsdl)... там в body уже только данные

но в общем хз, нужно смотреть реальный пример ;) скиньте wsdl что ли ;)

вот если хотите немного в теме быть https://www.ibm.com/developerworks/library/ws-whichwsdl/ - про стили... в rpc стиле там в body идет имя метода, а у вас скорее всего document стиль (гляньте wsdl)... там в body уже только данные

Я как раз читаю.

вот если хотите немного в теме быть https://www.ibm.com/developerworks/library/ws-whichwsdl/ - про стили... в rpc стиле там в body идет имя метода, а у вас скорее всего document стиль (гляньте wsdl)... там в body уже только данные

Спасибо

но в общем хз, нужно смотреть реальный пример ;) скиньте wsdl что ли ;)

Я в лс скинул

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

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

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

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

Я мельком пробежался, по статье. Я правильно понимаю, что мне нужно указать где-то стиль генерации xml для soapClient?

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

писать руками проще)

не, стиль указан в wsdl

просто в зависимости от стиля может чуток меняться порядок пораметров, насколько я помню, у soapclient были какие-то проблемы c document стилем

не, стиль указан в wsdl

Просто эта либа, либо сам soapClient генерит xml, который сервак не поддерживает

а если эта либа сама генерит xml... то могут быть проблемы и у нее ;)

Вряд ли, внутри либы: $result = $this->soapClient->__soapCall( $method, $arguments ); /** * @var SoapClient */ protected $soapClient;

Кто-то что-то слышал по поводу того, что сервисы надо именами классов теперь именовать и дескать старый подход планируется убрать? Я вроде на такую статью натыкался, а теперь найти не могу

Кто-то успешно съехал с jms serializer на симфы?

Меня как-то напрягает, что летит 502 пару запросов, пока толком jms не соберёт кеш по объектам

Кто-то что-то слышал по поводу того, что сервисы надо именами классов теперь именовать и дескать старый подход планируется убрать? Я вроде на такую статью натыкался, а теперь найти не могу

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

Я в лс скинул

https://gist.github.com/miksir/adfd03ece9dd92836b8d39170da61d5b

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

https://symfony.com/blog/new-in-symfony-3-3-optional-class-for-named-services

Тут сложно не услышать - ведь при новой установке СФ по этой схеме описаны сервисы по умолчанию в service.yml...

The traditional service definition will keep working as always (and it's even mandatory to use it in cases like decorating services). However, this new feature together with other optional features such as autowiring and defining default service options per file, will enable RAD ("rapid application development") for those projects and developers that need it:

Тут сложно не услышать - ведь при новой установке СФ по этой схеме описаны сервисы по умолчанию в service.yml...

https://gist.github.com/miksir/adfd03ece9dd92836b8d39170da61d5b

да капец!!!!! Кто бля придумал отправлять экземпляр класса Ping, в метод Ping? Кастрировать его нужно и сжечь его тело. А мне глаза выколоть за невнимательность!!!

АААААААААААААААААААААА!!!!!!!!!!!!!!!!!!!!!!!!!!!!

https://gist.github.com/miksir/adfd03ece9dd92836b8d39170da61d5b

А так спасибо чувак, реально выручил. Уже сутки проебал на эту хуйню

ну так а как... SoapClient::__getFunctions делаем и видим ;) [0] => PingResponse Ping(Ping $parameters)

ну так а как... SoapClient::__getFunctions делаем и видим ;) [0] => PingResponse Ping(Ping $parameters)

даа, чувак. Спасибо большое!!! Жму руку

Может кто скинуть норм статеек/практик по подходам к организации валидации? Для меня например непонятны и интересны моменты по типу: 1) Сущность всегда должна быть валидна => хочется добавить проверку на валидность изменяемых в сущности свойств в саму сущность (например changeEmail), но в это же время сущность не в состоянии проверить этот email на уникальность. Что делать в таком случае? 2) Что делать если ранее сущность была валидна и уже сохранена, а сейчас при получении из базы - не валидна (например возраст не было обязательным полем, а теперь является обязательным)

Есть ли по доктрине какие то статьи с лучшими практиками? Стоит ли использовать ленивую загрузку и если да то всегда ли?

Есть доклад: https://www.youtube.com/watch?v=WW2qPKukoZY

Ещё Марко периодически пишет в блог: http://ocramius.github.io/blog/doctrine-orm-optimization-hydration/

На сколько нужно быть погруженным в профессию, чтобы еще и блоги успевать писать?

На сколько нужно быть погруженным в профессию, чтобы еще и блоги успевать писать?

достаточно посмотреть на количество постов)

и прикинуть что на один пост уходит пару часов

(это намек что у Марко нет времени на блоги)

На сколько нужно быть погруженным в профессию, чтобы еще и блоги успевать писать?

он просто не гребет в море форм

http://ocramius.github.io/doctrine-best-practices/#/44 В сущности используется репозиторий. Это норм?

На сколько нужно быть погруженным в профессию, чтобы еще и блоги успевать писать?

чтоб работать ))

Может кто скинуть норм статеек/практик по подходам к организации валидации? Для меня например непонятны и интересны моменты по типу: 1) Сущность всегда должна быть валидна => хочется добавить проверку на валидность изменяемых в сущности свойств в саму сущность (например changeEmail), но в это же время сущность не в состоянии проверить этот email на уникальность. Что делать в таком случае? 2) Что делать если ранее сущность была валидна и уже сохранена, а сейчас при получении из базы - не валидна (например возраст не было обязательным полем, а теперь является обязательным)

1. "уникальный email" не является бизнес ограничением на саму сущность, скорее на коллекцию сущностей 2. этот вопрос тебе надо было с бизнесом решить. Что делать с пользлователями которые не указали ранее возраст

http://ocramius.github.io/doctrine-best-practices/#/44 В сущности используется репозиторий. Это норм?

откуда инфа что это сущность?

там же он разделил даже две картинки

http://ocramius.github.io/doctrine-best-practices/#/44 В сущности используется репозиторий. Это норм?

не норм и это не сущность. Это просто какой-то метод

ну и судя по всему это пример "как делать не надо".

там на 46-ом слайде лучше

Ааа

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

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

+

Sergey т.е. на 46 слайде норм решение? Есть метод ban у сущности пользователя. Находим в репертуаре пользователя и и его сущность умеет делать бан?

Может кто скинуть норм статеек/практик по подходам к организации валидации? Для меня например непонятны и интересны моменты по типу: 1) Сущность всегда должна быть валидна => хочется добавить проверку на валидность изменяемых в сущности свойств в саму сущность (например changeEmail), но в это же время сущность не в состоянии проверить этот email на уникальность. Что делать в таком случае? 2) Что делать если ранее сущность была валидна и уже сохранена, а сейчас при получении из базы - не валидна (например возраст не было обязательным полем, а теперь является обязательным)

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

Репозитории *

Sergey т.е. на 46 слайде норм решение? Есть метод ban у сущности пользователя. Находим в репертуаре пользователя и и его сущность умеет делать бан?

- находим юзера в репозитории (коллекция пользователей по сути) - баним юзера)

Ну то есть метод ban именно в классе User

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

Ну то есть метод ban именно в классе User

да

А не в отдельном классе сервисе BanService

А не в отдельном классе сервисе BanService

ну вот ты можешь в нем забирать пользователя и дергать метод)

если хочешь)

в моем случае например смысла в таких сервисах почти нет

ERROR: S client not available

Entities are not typed arrays. Entities have behavior

Entities are not typed arrays. Entities have behavior

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

ну или "данные должны обрабатываться там где они есть")

Видимо я перекупил принцип Single responsibility

Видимо я перекупил принцип Single responsibility

скорее всего ты понимаешь этот принцип неверно)

Типа на каждый чих свой класс. А то щас в ларавел крупные классы

Типа на каждый чих свой класс. А то щас в ларавел крупные классы

суть SRP в том что бы ложить рядом то что меняется вместе, и разделять то что меняется по совсем разным причинам

а не в том "сколько методов у класса"

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

ну и в целом проблема в том что "размер" надо мерять не кодом а поведением

а это уже слишком неформальная метрика

Ну т.е. в том же ларавел нет смысла плодить класс OrderService, OrderManager, когда есть сущность Order, и она сама способна с собой работать? Пока симфони изучаю

Ну т.е. в том же ларавел нет смысла плодить класс OrderService, OrderManager, когда есть сущность Order, и она сама способна с собой работать? Пока симфони изучаю

зависит от того что делают эти объекты

в Laravel с eloquent у тебя как бы active record что уже нарушение SRP

в Doctrine сущность - это просто объект, у нее нет других "поведений" кроме как то что тебе от нее надо. А потому с SRP будет все хорошо (если сделать)

Ну я пока пытаюсь понимать как вообще правильно его использовать

Ну я пока пытаюсь понимать как вообще правильно его использовать

кого "его"?

Принцип SRP

Пойду почитаю ещё этого чувака с докладами.

Принцип SRP

слишком сложно на данном этапе. Это надо обсуждать "контексты", разные источники изменений требований и т.д. Я бы рекомендовал сосредоточиться на Coupling/Coheasion + information expert + information hiding

наверное в обратном порядке

@fes0r а ты репетиторством не занимаешься ли? Я бы готов был заплатить за обучение

@fes0r а ты репетиторством не занимаешься ли? Я бы готов был заплатить за обучение

принципиально нет

подсказать помочь могу, специально заниматься не буду

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

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

сложнее блога?)

как раз таки хорошо, на простых штуках это все взлетает не хуже (не сложнее) но понимать чуть проще

да, профит от соблюдения сложнее прочувствовать но можно научиться определять насколько чего надо дробить что бы "все еще было удобно"

это ж не абсолютные принципы)

Ну нет уж. E-commerce проект есть на ларавел. Но внутренний перфекционизм подсказывает что можно лучше

Ну нет уж. E-commerce проект есть на ларавел. Но внутренний перфекционизм подсказывает что можно лучше

всегда можно лучше

идеал недостижим и всегда разный