Да и обычно SOAP-интерфейсы понятнее потому что они предоставляют структуру классов. Например, в Authorize.Net не было никаких проблем разобраться с ними. В NVP ты должен знать кучу параметров, правильно их задать, ничего не забыть. Писать самому GET-запрос, запоминать всех внутренние параметры, мне показалось не столь интересным занятием.
Так что я сначала перешел с NVP на SOAP, а потом как увидел, какой там бардак — перешел обратно. Проболема в том, что даже если даются примеры в статьях — о SOAP напрочь забывают.
Наверное вариант 3 лучше всего подходит. Вариант 1 был уже реализован, но вдруг захотелось не только кредитки принимать, а и PayPal аккаунты использовать. Поддерживать 2 системы платежей вряд ли имело смысл. Насчет 2 — тоже вариант.
PayPal это зло. Неделя моей жизни выброшенная на ветер.
— В версии SOAP API для PHP5 используются старые бибюлиотеки PEAR не совместимые с PHP5
— Иерархия классов в SOAP совершенно непонятна, что к чему приаттачить не разберешься.
Я вот не разобрался и потому никому не советую её использовать. NVP проще и лучше документирован.
Но и там есть проблемы… Описания очень пространные, примеры — это гремучая смесь из HTML, PHP, Javascript, да и они не покрывают нужный функционал. Сайт с документацией x.com пестрит ссылками на 404 страницы, некоторые материалы, кроме как в кеше гугла не увидишь. Да и те же recurring payments, которые я добавлял пару дней, как оказались стоят дополнительно 30 баксов в месяц.
И что обидно, интегрировали PayPal только ради PayPal аккаунтов. Знал бы я заранее такие расклады, убедил бы начальство принимать только кредитки через другого процессора и не париться :(
Так что если вам нужен сложный функционал оплаты (повторяющиеся платежи, автоматические платежи по какому-то событию, пр.) — советую избежать прямого контакта с PayPal.
Спасибо. А не подскажете, какой интерфейс стоит использовать для, например, автоматического пополнения баланса со счетов PayPal? В приложении есть внутренний баланс и когда он становится равным 0, то хотелось бы пополнить его на 10 баксов автоматически. В Authorize.Net такая фича есть, в PayPal пока не нашел.
В документации указано ограничение основанное на возможности отключить шорт теги на сервере. Причины делать это там не указаны. Потому даже если ты не пишешь «applications or libraries that are meant for redistribution, or deployment on PHP servers which are not under your control» стоит всё равно не стоит их использовать ибо их возможно придется отключить (даже на своем сервере) из-за проблем с XML.
Да, согласен, но $this подходит мало, ведь хедперы нужно разделять по группам, доопределять (с учетом множественного необходмисоти вгружать туда методы из многих классов), короче, получится костыль над множественным наследованием.
Можно передавать классы helper'ов в переменных и впринципе, это самый правильный вариант. Юзать $routing->url(). Проблема может быть только в случае, если вы хотите передать в шаблон переменную $routing… Короче, опять таки получается проблема отделения данных от представления.
Ну короткие теги для РНР действительно имеют проблемы с XML и есть негласная рекомендация их не использовать из-за этого. Они могут быть как включены так и выключены на продакшне (по той же причине), а потому после нескольких деплоев, где «всё упало» я сам отвык от пратики использовать их. Но сами понимаете, это как раз малосущественно.
А вот момент, когда я почувствовал, что шаблонизаторы нужны. Считается, что шаблонизаторы ограничивают разработчика, чтобы он не натворил всяких гадостей, но ведь и чистый РНР имеет одно важное ограничение: если вы используете helper'ы в виде функций, то они будут вгружены в глобальный контекст, а с этого и проблемы, они становятся доступны там где не должны быть, а самое важное, их становится трудно доопределять и переопределять под конкретные шаблоны. Если ваш код рендерит 3 шаблона и собирает их, то везде будут доступны одни и те же хелперы! Если вы меняете порядок рендеринга, то некоторые просто хелперы отвалятся. Альтернатива — использование хелперов из переменных ($routing->url_to) мне не нравится стилистически. Да и с точки зрения логики этот вариант не очень.
Вообщем, Фабиен, конечно молодец, пацан слово дал, пацан слово забрал. То он сам говорил, что РНР лучший шаблонизатор, а через пару лет, понял, что был не прав.
Интересно, почему?
Да уж, звучит как прям ещё один закон мироздания.Фиттс на равне Ньютоном и Ейнштейном.
Так что я сначала перешел с NVP на SOAP, а потом как увидел, какой там бардак — перешел обратно. Проболема в том, что даже если даются примеры в статьях — о SOAP напрочь забывают.
— В версии SOAP API для PHP5 используются старые бибюлиотеки PEAR не совместимые с PHP5
— Иерархия классов в SOAP совершенно непонятна, что к чему приаттачить не разберешься.
Я вот не разобрался и потому никому не советую её использовать. NVP проще и лучше документирован.
Но и там есть проблемы… Описания очень пространные, примеры — это гремучая смесь из HTML, PHP, Javascript, да и они не покрывают нужный функционал. Сайт с документацией x.com пестрит ссылками на 404 страницы, некоторые материалы, кроме как в кеше гугла не увидишь. Да и те же recurring payments, которые я добавлял пару дней, как оказались стоят дополнительно 30 баксов в месяц.
И что обидно, интегрировали PayPal только ради PayPal аккаунтов. Знал бы я заранее такие расклады, убедил бы начальство принимать только кредитки через другого процессора и не париться :(
Так что если вам нужен сложный функционал оплаты (повторяющиеся платежи, автоматические платежи по какому-то событию, пр.) — советую избежать прямого контакта с PayPal.
Это дейсвтительно принципиальная проблема, а как и проблема глобального контекста, от неё не избавиться никак.
Можно передавать классы helper'ов в переменных и впринципе, это самый правильный вариант. Юзать $routing->url(). Проблема может быть только в случае, если вы хотите передать в шаблон переменную $routing… Короче, опять таки получается проблема отделения данных от представления.
<?php $this->extend('layout') ?>
Hello <?php echo $name ?>
Что не так? «The template engine also support multiple inheritance as explained later on.»
Берем
components.symfony-project.org/templating/documentation
и всё будет )
Имхо, мне кажется, изначальный пример слишком упрощен. На уровне простых циклов и условий шаблонизатор действительно не дает никаких преимуществ.
А вот момент, когда я почувствовал, что шаблонизаторы нужны. Считается, что шаблонизаторы ограничивают разработчика, чтобы он не натворил всяких гадостей, но ведь и чистый РНР имеет одно важное ограничение: если вы используете helper'ы в виде функций, то они будут вгружены в глобальный контекст, а с этого и проблемы, они становятся доступны там где не должны быть, а самое важное, их становится трудно доопределять и переопределять под конкретные шаблоны. Если ваш код рендерит 3 шаблона и собирает их, то везде будут доступны одни и те же хелперы! Если вы меняете порядок рендеринга, то некоторые просто хелперы отвалятся. Альтернатива — использование хелперов из переменных ($routing->url_to) мне не нравится стилистически. Да и с точки зрения логики этот вариант не очень.
Вообщем, Фабиен, конечно молодец, пацан слово дал, пацан слово забрал. То он сам говорил, что РНР лучший шаблонизатор, а через пару лет, понял, что был не прав.
Кстати, интересный эксперимент. Можно ли обладая базой вконтакте вычислить руферов по фоткам?