Белая маркировка CakePHP: Каков наилучший способ предоставить кастомизирующие хуки/обратные вызовы для разработчиков?

Я разрабатываю приложение CakePHP, которое мы предоставим людям в качестве белой этикетки для реализации в их собственных компаниях, и им потребуются определенные возможности настройки для себя.

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

По сути, возможности настройки, которые я планирую предоставить им, будут довольно простыми, мне просто нужно вызывать «что-то», когда происходят определенные вещи, чтобы они могли делать такие вещи, как обновление внешних систем, отправка электронной почты себе/клиентам, такие вещи.

Мне интересно, как лучше всего это сделать?

Мой план состоит в том, чтобы иметь «файл» (с одним классом) для каждого моего контроллера, чтобы все было разумно организовано. В этом файле будет куча пустых методов, которые будет вызывать мой код, и они смогут добавлять код внутри этих методов, чтобы делать все, что им нужно.

Конкретный вопрос заключается в том, должен ли этот класс, полный пустых методов, быть компонентом? Контролер? Просто обычный класс PHP?

Мне нужно будет вызывать методы в этом классе из моих контроллеров, поэтому я предполагаю, что о том, чтобы сделать его контроллером, не может быть и речи (если, возможно, это не контроллер, который наследуется от моего? или, возможно, мой наследуется от их). Кроме того, мне нужно, чтобы реализатор этих методов имел доступ к моим моделям и компонентам, хотя я согласен заставить их использовать App::Import, мне не нужно, чтобы волшебные элементы $this->ModelName были установлены .

Кроме того, этот файл, который я создаю (компонент или контроллер), должен находиться в папке приложения рядом с другими (моими) контроллерами/компонентами? Или можно куда-то отдельно кинуть типа папки vendors?

Делали ли вы что-то подобное раньше?
Будем рады любым советам/рекомендациям/подводным камням, которых следует избегать.

Я знаю, что это довольно субъективно, я в основном хочу услышать о вашем опыте, если вы делали это раньше.

Спасибо!


person Daniel Magliola    schedule 02.10.2010    source источник


Ответы (2)


Две идеи, которые приходят на ум:

  • создавать шаблоны abstract (контроллеры, модели и т. д.), которые ваши клиенты могут расширять
  • напишите свои контроллеры/компоненты/модели как плагин в их собственном пространстве имен

В конечном счете, вы, кажется, хотите предоставить «расширенную» структуру Cake, в которой ваши клиенты все еще должны писать свой собственный код Cake (хотя я не знаю, как это сочетается с вашей идеей «базовых возможностей настройки»). Таким образом, вы должны писать свой код как можно более «необязательным» образом (плагины с именами, компоненты, AppModel улучшения, дополнительные библиотеки) и предоставлять документацию о том, как их использовать, чтобы помочь вашим клиентам ускорить их работу.

person deceze♦    schedule 03.10.2010
comment
Большое спасибо за ваш ответ. Идея абстрактных контроллеров звучит интересно, мне нужно подробнее изучить ее, чтобы убедиться, что CakePHP не подавится ею. - person Daniel Magliola; 04.10.2010
comment
Что касается вашего другого упоминания, я определенно не буду расширять CakePHP, чтобы мои клиенты писали свой собственный код. Я собираюсь дать им полнофункциональное приложение из коробки, но я знаю, что некоторые из них захотят что-то делать, когда что-то случится. Примерами могут служить такие вещи, как обновление внешней CRM при создании/изменении учетной записи, отправка электронных писем людям, когда происходят определенные события, и тому подобное. Это не серьезные изменения в том, как работает система, это просто некоторые хуки, чтобы они могли делать простые пользовательские вещи, которые им могут понадобиться. - person Daniel Magliola; 04.10.2010
comment
@Daniel Вы только что сказали, что хотели бы ... :) Классы abstract прекрасно работают в Cake (это всего лишь PHP), я сам иногда использовал их. Вы также можете просто предоставить пустые классы с методами, которые вызываются при определенных событиях, которые ваши клиенты могут заполнить кодом, если это необходимо. Это действительно зависит от обстоятельств, какой лучший метод. - person deceze♦; 05.10.2010
comment
Пустые классы с методами: это ТОЧНО моя идея, я спрашиваю, какими должны быть эти классы (компоненты, контроллеры и т. д.), чтобы в этих методах они могли использовать мои модели/компоненты/и т. д. Похоже, что вместо того, что у меня сейчас есть в качестве AccountsController, у меня будет AccountsControllerBase с фактическим кодом, а AccountsController будет иметь пустые методы. Это то, что вы предлагаете, правильно? - person Daniel Magliola; 05.10.2010
comment
@Daniel Ну, это зависит от того, насколько близко вы хотите придерживаться структуры Cake и как к этому отнесутся ваши клиенты. Помните, что это всего лишь PHP, вам не нужно использовать контроллеры или модели. Вы можете создать новый класс EventHooks в каталоге /lib и вызывать в нем методы, передавая соответствующие модели или компоненты в качестве параметров функции. - person deceze♦; 06.10.2010
comment
Прохождение инстансовых моделей, интересно, мне нравится. Хорошо, я посмотрю на все это и немного поэкспериментирую. Большое спасибо за Вашу помощь!!! - person Daniel Magliola; 06.10.2010

Я бы установил общий набор событий и использовал для этого что-то вроде связанной с системой событий.

Это позволяет клиентам управлять классами обработчиков событий (прочитайте файл readme, чтобы понять, что я имею в виду), а также подписываться на события и транслировать их по всему приложению.

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

http://github.com/m3nt0r/eventful-cakephp

person Abba Bryant    schedule 04.10.2010
comment
Эта система событий звучит ОЧЕНЬ интересно! Я изучу его подробнее, он кажется менее разрушительным для моего кода, чем идея абстрактного класса, при условии, что он дает мне всю необходимую мне гибкость, мне придется поэкспериментировать. Что касается упаковки, я собираюсь кодировать большую часть своего кода с помощью ionCube или чего-то подобного. Я знаю, что это не идеально, но это позволяет мне очень четко проводить границы. Если он закодирован, вы не должны его трогать. Спасибо!! - person Daniel Magliola; 05.10.2010