Бяло етикетиране на CakePHP: Кой е най-добрият начин за предоставяне на куки за персонализиране/обратни извиквания на изпълнителите?

Разработвам CakePHP приложение, което ще предоставим като бял етикет за хората, които да внедрят за собствените си компании, и те ще трябва да имат определени възможности за персонализиране за себе си.

Като за начало, те ще могат да правят всичко, което искат с изгледите, и могат да добавят свои собствени контролери/модели, ако трябва да добавят напълно нови неща. Все пак бих посъветвал да не докосвате моите контролери и модели, за да улесните надграждането на версията.

По същество възможностите за персонализиране, които планирам да им дам, ще бъдат доста основни, просто трябва да извикам „нещо“, когато се случат определени неща, така че те да могат да правят неща като актуализиране на външни системи, електронна поща на себе си/клиентите, такива неща.

Чудя се кой е най-добрият начин да направя това?

Моят план е да имам "файл" (с един клас) за всеки мой контролер, за да поддържам нещата разумно организирани. Този файл ще има куп празни методи, които моят код ще извика, и те ще могат да добавят код в тези методи, за да направят каквото трябва.

Конкретният въпрос е дали този клас, пълен с празни методи, трябва да бъде компонент? Контролер? Просто обикновен обикновен PHP клас?

Ще трябва да извикам методи в този клас от моите контролери, така че предполагам, че да го направя контролер е изключено (освен ако може би не е контролер, който наследява от моя? или моят наследява от техния, вероятно). Освен това ще имам нужда от внедряващия тези методи да има достъп до моите модели и компоненти, въпреки че не съм съгласен да ги накарам да използват App::Import, не е необходимо да имам набор от магически $this->ModelName членове .

Освен това този файл, който създавам (компонент или контролер), трябва ли да живее в папката на приложението до другите (моите) контролери/компоненти? Или мога да го хвърля някъде отделно като папката на доставчиците?

Правили ли сте нещо подобно преди?
Всякакви съвети/клопки, които да избягвате, са повече от добре дошли.

Знам, че това е субективно, очаквам да чуя най-вече от вашия опит, ако сте правили това преди.

Благодаря!


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