Python-сообщество

zheromo
Есть еще один вариант, основанный на генерации классов по их описанию

Отредактировано (Фев. 19, 2011 16:45:42)

o7412369815963
работает быстрее

o7412369815963
ошибки искать

zheromo

o7412369815963
работает быстрее

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

o7412369815963
ошибки искать

ошибки теоретически в момент генерации и должны выявлятся (или у нас не динамическая типизация? :))

o7412369815963
типизация ни причем

Излагаю свое мнение.

Разработчики trac при создании своей системы плагинов преследовали простую цель: чтобы при выпуске следующей версии trac большая часть плагинов продолжала работать. Естественно, что-то может поломаться. Но если четко прописаны интерфейсы (необязательные в том смысле что их легко обмануть - но очень полезные в документировании ответственности), указаны точки инжекции плагинного кода - есть какая-то уверенность в стабильности системы.
Недостаток, связанный с конечным количеством этих точек инжекции, решается общением с создателями trac и они добавляют новые в следующей версии.

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

Вариант o7412369815963 проще и радикальней. Только он все равно избыточный.
Если при создании системы вопросы взаимодействия плагинов (не только с системой, но и между собой - что будет если два плагина подерутся за одно место?) - забота плагинописателей, то самое простое и гибкое (дальше некуда) решение - импортировать плагин а там пусть он сам крутится как может.
Дополнительных усилий прилагать не нужно.
Если в следующей версии плагины поломаются - это чужая головная боль. Равно как авторам плагинов самим придется заботится о совместной работе с коллегами. Это - цена неимоверной гибкости. Конечно, потом уже в самих плагинах появятся адаптеры, интерфейсы и точки входа - просто потому, что поддерживать такую невероятно гибкую систему в рабочем состоянии стоит очень больших усилий и постоянной головной боли.

Вот собственно и все. Два подхода, и все виденные мной системы так или иначе следовали либо первому либо второму.
И если выбирается строгая спецификация - в дизайне должно быть минимум магии, даже если это приводит к более объемному коду. В таких местах слишком легко ошибиться.

zheromo, если изучали trac не убоявшись интерфейсов - посмотрите еще и на Zope Component Arcitecture.

Андрей Светлов
Если при создании системы вопросы взаимодействия плагинов (не только с системой, но и между собой - что будет если два плагина подерутся за одно место?) - забота плагинописателей, то самое простое и гибкое (дальше некуда) решение - импортировать плагин а там пусть он сам крутится как может.

Список не поможет, mockey patching - трудно формализуемая операция. Думаю, достаточно будет просто списка загруженных плагинов чтобы экспериментально определять, где что и как.

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

С другой стороны, если zheromo будет писать cms и плагины к ней одновременно - у него будет возможность добавить столько точек инжекции сколько потребуется.

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

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

Все хорошо, но возникло два вопроса.

1. Обычно я стараюсь много чего выносить в конфиги. Приведу пример, так роутинг я обычно описываю в отдельном файле (yaml) как-то так:

    index:
        view: views.index.index
        url:
            - /
            - /page/<int:page>
        renderer: actions/index/index.html
        acl: VIEW

        index:
            order: 100
            title: blog_menu_all
            counter: views.new.count_topics_new
            submenu:
                index:
                    order: 100
                    title: blog_menu_all_good
                new:
                    order: 200
                    title: blog_menu_all_new
                    counter: views.new.count_topics_new
                    hide_if_zero: true

        index:
            submenu:
                plugin:
                    order: 150
                    title: blog_menu_plugin

class IRouteProvider(Interface):
    
    def connect():
        """Mount endpoint & routes of view.
        Format: (enpoint, route1, route2, ...)
        """
        
    def handle(context, request):
        """Process the request."""

class INavigationContributor(Interface):
    """Extension point interface for components that contribute items to the
    navigation.
    """

    def get_active_navigation_item(request):
        """This method is only called for the `IRouteProvider` processing the
        request.
        
        It should return the name of the navigation item that should be
        highlighted as active/current.
        """

    def get_navigation_items(request):
        """Should return an iterable object over the list of navigation items to
        add, each being a tuple in the form (category, endpoint, title, counter [optional], 
        hide_if_zero [optional], quotted [optional]).
        """

class IndexModule(Component):
    '''Main page
    '''
    
    required = True
    implements(INavigationContributor, IPermissionRequestor, IRouteProvider)
    
    # INavigationContributor methods

    def get_active_navigation_item(self, request):
        return 'index'

    def get_navigation_items(self, request):
        return [( .... )]

    # IPermissionRequestor methods

    def get_permission_actions(self):
        return ['VIEW']

    # IRouteProvider methods

    def connect(self):
        return ('index', '/', '/page/<int:page>',)
    
    def handle(self, context, request, page=1):
        return 'actions/index/index.html', dict( ... )

class ITemplateProvider(Interface):
    def get_template_loader():
        '''Возвращает загрузчик шаблонов'''
    def get_translations():
        '''Возвращает класс GNUTranslations либо путь к каталогу'''

class BroserView(Component):
    """Web site chrome assembly manager."""
    
    required = True
    implements(IRouteProvider, ITemplateProvider)
    
    navigation_contributors = ExtensionPoint(INavigationContributor)
    template_providers = ExtensionPoint(ITemplateProvider)

    + много буков по имплементации всего этого добра

Эээ. А flask и есть именно - микро. И именно роутинг -это та задача, которую он обязан решать.
Все прочее - полезные, но не обязательные надстройки.
Мне нужно посмотреть на ваш код внимательней прежде чем говорить что-то еще.