Если не сложно, подскажите, удобно ли использовать phing совместно с Eclipse?
Сам выбрал ant только потому, что в Eclipse позволяет удобно запускать нужные действия. Для запуска PHP скриптов используется отдельный скрипт, которому передается название команды (по сути, имя класса) и её аргументы. В ant-е запускается через макрос. Единственная сложность была с кодировкой ввода/вывода, но и её удалось решить.
1. Может, у них есть xml интерфейс — можно узнать список валют, курсы обмена и состояние текущего платежа. Примеры есть у них в документации (ссылку автор приводил)
2. По-моему нет, но возможно ошибаюсь.
3. В админке можно указать: пароль 1, пароль2, как считается crc автор написал. НО не написал он о том, что на Success URL и Fail URL передаются те же параметры, что и на Result URL, а crc считается с «пароль 1».
P.S. Вместо этой заметки лучше почитать офф сайт — там намного подробнее (здесь, например, описания как передавать свои параметры) + примеры кода (Perl, ASP — Jscript, ASP.NET).
С этим не поспоришь… Но ничего удивительного, по-моему, в этом нет, т.к. самому разобраться как оплатить очень тяжело… Девушки там, кстати, очень спокойные и вежливые, похоже уже привыкли к недовольным пользователям)))
Чуть выше писал про
> Еще не забываем про процент обмена «WM => RBK Money»
Сейчас посмотрел: за 100WMR дают 96 RBK Money (http://www.roboxchange.com/, может где дешевле есть) это 4% + 0,8% комиссия WM + неудобство пользователям WM.
Отдать робокасcе 5% (2% из которых могут заплатить пользователи WM — им это все равно выгоднее) мне кажется лучше.
+ в копилку робокассы — на вопрос по API (т.е. по взаимодействию с их системой из своих скриптов) ответили в течение получаса (отправил, пошел пить чай, прихожу — письмо уже пришло).
> Да, Вы можете принимать платежи на свой электронный кошелек в системе от пользователей, не имеющих кошелька в системе RBK Money. Оплатить товары и услуги в магазинах, подключенных к нашей системе, можно с помощью банковского перевода, prepaid-картами RBK Money, через платежные терминалы, системы денежных переводов и электронные платежные системы.
Да, но чтобы оплатить товар WM нужно создать у них кошелек и платить с него, т.е.: «WM* => Продавец» нельзя, но можно «WM* => новый кошелек RBK Money => Продавец» (хотя, в этом WM виновата, но меня как пользователя и покупателя не должны волновать проблемы взаимодействия платежных систем между собой). Зачем мне еще один кошелек? Я хочу просто заплатить. (меня полностью устраивают WM и ЯД, лишний кошелек мне совершенно не нужен, тем более пользоваться им не собираюсь второй раз).
Еще не забываем про процент обмена «WM => RBK Money»…
IMHO, очень, очеееень зря. Почему? Потому, что для того чтобы заплатить WM через РБКмани, нужно сначала завести у них аккаунт (т.к. напрямую оплатить нельзя), потом найти обменник который меняет WM* (из первых 4 ни один не менял...) на РБКмани, и только потом можно завершить платеж (с кошелька РБКмани). Так было пару месяцев назад, но сомневаюсь что что-то изменилось.
Еще один важный момент (у меня он окончательно отбил желание второй раз пользоваться РБКмани) — при подтверждении платежа, нужен код, который будет отправлен на почту… Маразм… Я хочу заплатить *сейчас*, а не ждать неизвестно сколько времени пока придет какой то непонятный код.
Так что не удивляйтесь что всего 1 платеж — слишком это сложно, человек хочет отдать свои деньги, а вместо этого получает только проблемы…
После этого понимаешь как на самом деле удобно работать с WM (или с ЯД).
P.S.: Чтобы 1 оплатить через РБКмани пришлось 3(!) раза писать в их службу поддержки (может, я тупой просто?)). 1 — как оплатить (прямого платежа нет). 2 — почему половина рекомендованных обменников не меняет? 3 — требует код, что за ...?! Понятно что найти можно было и самому, но «Я хочу заплатить *сейчас*, а не ...»
> Русская версия вообще стала раритетом, так как её более полугода назад убрали с php.net. В мануале же она присутствует.
И правильно сделали что убрали — последнее время она вообще не обновлялась, в итоге от неё было больше вреда чем пользы (чего только стоят отсутствующие аргументы у функций)…
> непонятно зачем? на стадии создания итак известен товар. getItem нужен прежде всего при дальнейшей обработке, когда надо по номеру покупки, узнать что за товар был продан. При этом getItem() переопределённый для каждого типа, избавляет от ещё одного switch
Хотя бы за тем, чтобы разделить классы CPurchaseItem и CPurchase. В вашем случае, возможно, действительно удобнее использовать текущую реализацию, но у себя я бы разделил эти 2 класса (CPurchase скорее всего реализовал бы в качестве фабрики, как это написано чуть ниже, в этом случае, получение CPurchaseItem в самой фабрике точно лишнее — не должна она знать о способе получения item-а).
> непонятно зачем? на стадии создания итак известен товар. getItem нужен прежде всего при дальнейшей обработке, когда надо по номеру покупки, узнать что за товар был продан. При этом getItem() переопределённый для каждого типа, избавляет от ещё одного switch
У Вас:
Хотя бы за тем, чтобы разделить 2 класса CPurchaseItem и
По CBilling (к CPurchase тоже можно отнести), возможно, лучшим решением будет сделать отдельную фабрику (не обязательно, но это облегчит понимание кода) для создания биллингов — BillingFactory — все методы этого класса будут статичными (BillingFactory::createBillingByType, BillingFactory::getBillingTypeByRequest и т.д.), в нем же можно реализовать метод для добавления новых биллингов, тогда отпадет необходимость при добавлении новых типов модифицировать код. Будет примерно так — pastebin.ru/308746
Интересен 3 вариант, т.к. можно будет упростить реализацию.
> Сразу оговорюсь, в другом языке, можно было обойтись абстрактным классом и его наследниками, но поскольку в PHP нельзя переопределить статическую функцию, предков разделили на интерфейс + базовый класс.
В Вашем варианте можно сделать «class CPurchase implements InterfacePurchase» что позволит переложить проверку сигнатур методов на PHP.
Я один заметил, что при выполнении этот блок
> case self::PURCHASE_SHOP:$purchase = new CPurchaseShop();
> case PURCHASE_ACCOUNT: $purchase = new CPurchaseAccount();
> case PURCHASE_RAIT: $purchase = new CPurchaseRait();
> //…
> default: throw new ExceptionUnknownPurchaseType (__CLASS__);
> Кроме того, какая вероятность того, что автор согласится за деньги что-то допилить?
Ничего не мешает спросить об этом самого автора, и даже если откажется, всегда можно найти программиста который сможет это сделать (не бесплатно естественно).
Если фича полезная можно найти единомышленников и скинуться на её реализацию.
Можно самому помочь.
Вариантов на самом деле очень много.
> Тогда теряется весь смысл open source.
Выложите купленный код в общий доступ, тем самым Вы поможете проекту и поддержите идеологию open source.
> Потому что платить за опен сорс не вижу смысла
Так не платите, никто не заставляет. Но в таком случае — как можно чего то требовать от автора? Он Вам ничего не должен.
Включите в настройках «Ситуация по задачам» -> «Разрешить пересечение задач по проектам». После этого можно будет задачи как угодно связывать. (Redmine 0.9)
Я с Вами согласен, разве что забыли добавить пометку активной страницы.
Но почему-то мне кажется, что большинство напишет как в первом примере (если приложения не только для себя это рано или поздно случится, т.к. проверять всех кто правит шаблоны не будешь). Разбираться в подобных шаблонах у меня желания нет, т.е. для себя я сделал вывод: в тех приложениях где нельзя гарантировать определенный уровень XSLT верстальщика (а они есть?) предпочтительнее обычный шаблонизатор.
Я не говорил что XSLT плохой, преимущества у него есть и их глупо отрицать. Но вот синтаксис удобным назвать нельзя и в больших шаблонах получается действительно мешанина.
Работал с XSLT немного (верстка для HostCMS), по-моему главный его недостаток в том, что неудобно читать шаблоны — мешанина из тэгов (разные пространства имен не спасают).
Если не ошибаюсь, это не проблема, по крайней мере, в 5.2.* это, похоже, сознательно убрано. Нашел bugs.php.net/bug.php?id=45691, возможно, как раз из-за него.
WinCacheGrind — пробовал с последним xdebug ни один лог не открыла, после чего была выкинута.
Поставил CachegrindVisualizer — удобно и главное работает, но кроме Adobe AIR понадобиться graphviz и zgrviewer.
Работа происходит следующим образом:
1) Запускаем скрипт, получаем лог
2) Открываем его в CachegrindVisualizer (если файл большой может зависнуть)
3) После того как CachegrindVisualizer отработал, в той же директории, находим *.dot, который открываем в zgrviewer
4) Смотрим.
Если *.dot большой ждать нужно долго или может не хватить памяти. В последнем случае узнать об этом проблематично, т.к. выброшенное исключение отобразиться в консоле (т.к. zgrviewer запускается через bat файл), которая закрыта окном.
Сам выбрал ant только потому, что в Eclipse позволяет удобно запускать нужные действия. Для запуска PHP скриптов используется отдельный скрипт, которому передается название команды (по сути, имя класса) и её аргументы. В ant-е запускается через макрос. Единственная сложность была с кодировкой ввода/вывода, но и её удалось решить.
2. По-моему нет, но возможно ошибаюсь.
3. В админке можно указать: пароль 1, пароль2, как считается crc автор написал. НО не написал он о том, что на Success URL и Fail URL передаются те же параметры, что и на Result URL, а crc считается с «пароль 1».
P.S. Вместо этой заметки лучше почитать офф сайт — там намного подробнее (здесь, например, описания как передавать свои параметры) + примеры кода (Perl, ASP — Jscript, ASP.NET).
Чуть выше писал про
> Еще не забываем про процент обмена «WM => RBK Money»
Сейчас посмотрел: за 100WMR дают 96 RBK Money (http://www.roboxchange.com/, может где дешевле есть) это 4% + 0,8% комиссия WM + неудобство пользователям WM.
Отдать робокасcе 5% (2% из которых могут заплатить пользователи WM — им это все равно выгоднее) мне кажется лучше.
Да, но чтобы оплатить товар WM нужно создать у них кошелек и платить с него, т.е.: «WM* => Продавец» нельзя, но можно «WM* => новый кошелек RBK Money => Продавец» (хотя, в этом WM виновата, но меня как пользователя и покупателя не должны волновать проблемы взаимодействия платежных систем между собой). Зачем мне еще один кошелек? Я хочу просто заплатить. (меня полностью устраивают WM и ЯД, лишний кошелек мне совершенно не нужен, тем более пользоваться им не собираюсь второй раз).
Еще не забываем про процент обмена «WM => RBK Money»…
> выбрали РБКмани
IMHO, очень, очеееень зря. Почему? Потому, что для того чтобы заплатить WM через РБКмани, нужно сначала завести у них аккаунт (т.к. напрямую оплатить нельзя), потом найти обменник который меняет WM* (из первых 4 ни один не менял...) на РБКмани, и только потом можно завершить платеж (с кошелька РБКмани). Так было пару месяцев назад, но сомневаюсь что что-то изменилось.
Еще один важный момент (у меня он окончательно отбил желание второй раз пользоваться РБКмани) — при подтверждении платежа, нужен код, который будет отправлен на почту… Маразм… Я хочу заплатить *сейчас*, а не ждать неизвестно сколько времени пока придет какой то непонятный код.
Так что не удивляйтесь что всего 1 платеж — слишком это сложно, человек хочет отдать свои деньги, а вместо этого получает только проблемы…
После этого понимаешь как на самом деле удобно работать с WM (или с ЯД).
P.S.: Чтобы 1 оплатить через РБКмани пришлось 3(!) раза писать в их службу поддержки (может, я тупой просто?)). 1 — как оплатить (прямого платежа нет). 2 — почему половина рекомендованных обменников не меняет? 3 — требует код, что за ...?! Понятно что найти можно было и самому, но «Я хочу заплатить *сейчас*, а не ...»
> Проголосовало человек: 18695
Печально…
И правильно сделали что убрали — последнее время она вообще не обновлялась, в итоге от неё было больше вреда чем пользы (чего только стоят отсутствующие аргументы у функций)…
Предыдущий комментарий следует читать так:
> непонятно зачем? на стадии создания итак известен товар. getItem нужен прежде всего при дальнейшей обработке, когда надо по номеру покупки, узнать что за товар был продан. При этом getItem() переопределённый для каждого типа, избавляет от ещё одного switch
Хотя бы за тем, чтобы разделить классы CPurchaseItem и CPurchase. В вашем случае, возможно, действительно удобнее использовать текущую реализацию, но у себя я бы разделил эти 2 класса (CPurchase скорее всего реализовал бы в качестве фабрики, как это написано чуть ниже, в этом случае, получение CPurchaseItem в самой фабрике точно лишнее — не должна она знать о способе получения item-а).
У Вас:
Хотя бы за тем, чтобы разделить 2 класса CPurchaseItem и
Сейчас
Интересен 3 вариант, т.к. можно будет упростить реализацию.
Это и сейчас можно, вот так, например, pastebin.ru/308744
В Вашем варианте можно сделать «class CPurchase implements InterfacePurchase» что позволит переложить проверку сигнатур методов на PHP.
Я один заметил, что при выполнении этот блок
> case self::PURCHASE_SHOP:$purchase = new CPurchaseShop();
> case PURCHASE_ACCOUNT: $purchase = new CPurchaseAccount();
> case PURCHASE_RAIT: $purchase = new CPurchaseRait();
> //…
> default: throw new ExceptionUnknownPurchaseType (__CLASS__);
работает совсем не так, как ожидается?
Ничего не мешает спросить об этом самого автора, и даже если откажется, всегда можно найти программиста который сможет это сделать (не бесплатно естественно).
Если фича полезная можно найти единомышленников и скинуться на её реализацию.
Можно самому помочь.
Вариантов на самом деле очень много.
> Тогда теряется весь смысл open source.
Выложите купленный код в общий доступ, тем самым Вы поможете проекту и поддержите идеологию open source.
> Потому что платить за опен сорс не вижу смысла
Так не платите, никто не заставляет. Но в таком случае — как можно чего то требовать от автора? Он Вам ничего не должен.
Все IMHO, естественно.
Включите в настройках «Ситуация по задачам» -> «Разрешить пересечение задач по проектам». После этого можно будет задачи как угодно связывать. (Redmine 0.9)
Но почему-то мне кажется, что большинство напишет как в первом примере (если приложения не только для себя это рано или поздно случится, т.к. проверять всех кто правит шаблоны не будешь). Разбираться в подобных шаблонах у меня желания нет, т.е. для себя я сделал вывод: в тех приложениях где нельзя гарантировать определенный уровень XSLT верстальщика (а они есть?) предпочтительнее обычный шаблонизатор.
Для примера, часть реального шаблона: pastebin.org/55704
Удобно? Понятно? Мне — нет.
Поставил CachegrindVisualizer — удобно и главное работает, но кроме Adobe AIR понадобиться graphviz и zgrviewer.
Работа происходит следующим образом:
1) Запускаем скрипт, получаем лог
2) Открываем его в CachegrindVisualizer (если файл большой может зависнуть)
3) После того как CachegrindVisualizer отработал, в той же директории, находим *.dot, который открываем в zgrviewer
4) Смотрим.
Если *.dot большой ждать нужно долго или может не хватить памяти. В последнем случае узнать об этом проблематично, т.к. выброшенное исключение отобразиться в консоле (т.к. zgrviewer запускается через bat файл), которая закрыта окном.
Если нужно просмотреть много логов — надоедает.