Все любят Одувана

>внутри второго апа только тег. Не совсем понимаю, при чем тут расширения?
Там логика "от обратного". Ты предлагаешь вливать расширения в текущий Апп.

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

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

threadedcomments_extras - неудачный пример. Более удачный - photos. Там возникла необходимость интегрировать photologue и groups.

И все-таки, непобедимым остается Signal.

Яркий пример самой гибкой и расширяемой системы на РНР, - Друпал, полностью построен на этом принципе. Например, http://api.drupal.org/api/func...

Форма передается по ссылке как аргумент на обработку в нужной точке программы. В случае же, если форма - объект, то она и так передается по ссылке, а не по значению.

Сторонние модули могут расширить набор полей формы. Например, такой функционал как каптча можно вынести в отдельный апп. И в сочетании с адаптерами каптчи, можно гибко и централизовано подменять тип каптчи или степень ее защиты по всему проекту одновременно.

Так же можно вынести категоризатор в отдельный апп. И через Сигналы навешивать поля в форме и сохранять значения.

Сагалаев написал когда-то заметку по сигналам http://softwaremaniacs.org/blo...

Фактически, сигналы, - это то же самое, что ты предлагаешь, только унифицировано.

Если твой случай зависит от соглашения (нужно знать имя расширяемого модуля), - то в той точке можно просто поставить сигнал (вместо предложенного тобой кода), и сторонние приложения смогут получить доступ к модулю в нужное время, и расширить его атрибуты. При этом мы избавляемся от соглашения по именованию расширений. Кому нужно, - тот подпишится, и потом отработает. Таким образом, расширений может быть несколько, а не одно.

Самый хороший способ "прокурить" сигналы, - это покопаться недельку в нутре Друпала. Других "ярких" примеров расширяемости я привести не могу. Ну есть там Симфони, Sympal, - но там уже нет такой яркости.

>Потому что расширяют в обратном порядке. Можно посмотреть на примере Пинакса (threadedcomments_extras, photos, voting_extras ). Там вливают в расширяемый app оригинал.

В настройках пинакса
'threadedcomments',
'threadedcomments_extras',

внутри второго апа только тег. Не совсем понимаю, при чем тут расширения?

@presidentua
> Я в своих проектах очень часто изменяю чужие аппы. Если меняются они то Меркуриал их зачастую нормально мержит если были обновления. Но зачастую сами обновления аппов меня после релиза не сильно волнуют (кроме критических).

По поводу мержа, если я правильно Вас понял, это вы для каждого проекта храните отдельный чекаут всех апов которые вы кцали под конкретный проект? + Чекаут самого проекта, с копиями исходников из тех чекаутов. Как по мне, оно даже звучит не легче, или я Вас не правильно понял.

>Ведь я взял чужой апп и он меня полностью устраивал на момент выбора и встраивания в приложение. И значить все новые изменения мне не нужны )

Ну есть еще такое дело, как поддержка, и некоторые баги, всплывшие во время работы + обновления связаны иногда не только с фиксами но и с оптимизами.

> А предложеная конструкция как-то не очень красиво смотрится ).
я бы сказал, что код смотрится менее прозрачным, но это только для непредусмотренных автором фичей.

>Лучше уж сигналов понаствлять… Да и я незнаю как она будет по скорости работать, будет ли Питон каждый раз проверять наличине того модуля для подключения… Нуно тестить )

Уверен, что по скорости он будет работать быстрее сигналов. А по поводу подключения - я не понял. Да и чесно говоря - я бы сигналы юзал вместе с этим, а не вместо. Но надо смотреть под конкретный проект.

@Cykooz
> - этот способ всё равно не позволяет достаточно гибко подгонять поведение приложения под ваши нужды (если конечно не использовать грязный monkey-patching);

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

> - есть вероятность, что вам может потребоваться некий сторонний пакет, который называется ex_catalog и не имеет ни какого отношения к вашему – catalog;

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

ex.catalog.view

>- для расширения приложения можно будет использовать только один пакет ex_catalog, какие то другие сторонние расширения уже не подключить. Только если скопировать их код полностью в один пакет, а это усложняет автоматическое обновление пакетов.

вот эту мусль я чесно говоря не понял. ex - уже говорит, что это расширение только твое и только для твоего апа. Или вы имеете ввиду, что разне апы захотат по разному расширять другу апу? Я запутался.

Потому что расширяют в обратном порядке. Можно посмотреть на примере Пинакса (threadedcomments_extras, photos, voting_extras ). Там вливают в расширяемый app оригинал.

Что касается monkey-patch, - не знаю, кто и почему его считает грязным (наверное снова модно так говорить), - это вполне нормальная и нужная практика. На Ruby on Rails он вообще вылился в стройную систему кастомизации кода плагинов http://github.com/pivotal/dese... , который используется во многих известных продуктах (Community Engine, TOG...).

А по сути, - для взаимодействия различных приложений существует паттерн Signal (Observer, Events, Hook). Просто в нужных местах подавать объект на обработку, и принимать его.

В самой Джанге расставлено большое количество сигналов, и их, в большинстве случаев, достаточно.