Объединение Angularjs и CodeIgniter

Похоже, вы пытаетесь постепенно использовать маршрутизацию Code Igniter (CI) по мере роста вашего углового приложения. Это не сложно, но требует много деталей. Какой метод будет работать, зависит от структуры вашего проекта. Примечание. Я удалил index.php из URL-адресов Ignit Code, поэтому приведенные ниже пути могут отличаться от значений по умолчанию.

1) Кодовый Зажигатель установлен в корне

Если CI установлен в корневом каталоге вашего сервера, вы можете создать папку внутри CI (например, у меня есть папка «ng»). Ваш проект будет выглядеть так:

/controllers /models /ng (etc) /index.php (code igniter index file) 

поместите файл .htaccess в /ng со следующим:

  Order allow, deny Allow from all 

Это позволяет напрямую обращаться к файлам внутри /ng , а не отправлять эти запросы обратно через систему маршрутизации CI. Например, вы можете загрузить это прямо сейчас: example.com/ng/partials/angular-view.html

Основная веб-страница по-прежнему будет создана Code Igniter, но теперь она может включать в себя функции Угловые, такие как частичные представления и т. Д. В конце концов вы можете заменить большую часть того, что делает Code Igniter, просто вернув простую страницу и имея частичную нагрузку views from /ng как это предназначено для.

Этот метод хорош, потому что Code Igniter может контролировать, загружается ли эта начальная страница вообще (через некоторый код аутентификации пользователя в вашем контроллере CI). Если пользователь не вошел в систему, они перенаправляются и никогда не видят приложение «Угловое».

2) Зажигатель кода в каталоге

Если CI установлен в каталоге, например, example.com/myapp/(code igniter) вы можете просто создать каталог рядом с ним, example.com/myappNg/

  /myapp/ /myapp/controllers/ /myapp/models/ /myapp/(etc) /myapp/index.php (code igniter index file) /myappNg/ /myappNg/partials/ /myappNg/js/ /myappNg/(etc) и  /myapp/ /myapp/controllers/ /myapp/models/ /myapp/(etc) /myapp/index.php (code igniter index file) /myappNg/ /myappNg/partials/ /myappNg/js/ /myappNg/(etc) 

Теперь в вашем приложении «Угловое» вы можете запрашивать ресурсы у CI, создавая пути относительно корня домена, а не относительно приложения «Угловое». Например, в Angular вы больше не будете запрашивать частичный вид из partials/angular-view.html угловой папки partials/angular-view.html , скорее вы захотите запросить представления из CI /myapp/someResource . Обратите внимание на ведущий / . «someResource» может вернуть html-документ, или JSON, или что-то еще, что вы делаете с Code Igniter. В конце концов вы можете заменить количество путей, которые ссылаются /myapp/ . Как только вы больше не используете CI для чего-либо, вы можете просто поместить свой Angular index.html в /myapp/ и он будет продолжать ссылаться на ваши пути в /myappNg/ .

TL; DR Сделайте свое угловое приложение полностью доступным и отделите его от Code Igniter. Постепенно переходите к использованию угловых частичных представлений и других источников JSON вместо привязки к страницам Code Igniter. В конце концов замените конечную точку Code Igniter файлом HTML, который загружает Angular.

Изменить: исправлено правописание

Я никогда не использовал Угловое – тем не менее это может помочь.

Поэтому я нажимаю ссылку, управляемую угловым маршрутизатором, и обрабатывается javascript

Этот JavaScript делает запрос Ajax одному из ваших контроллеров CI? Если это так, у CI теперь есть метод is_ajax_request() , который позволяет вам проверить, поступает ли запрос (POST или GET) через ajax. Вы можете действовать по-другому на основе запроса, поступающего от Ajax по сравнению с обычным запросом.

Руководство пользователя ( внизу страницы ): http://ellislab.com/codeigniter/user-guide/libraries/input.html

Надеюсь, поможет!

Я унаследовал приложение CI, и я использую Angular с CI в основном для запросов на маршрутизацию. В моем случае я не использую угловые шаблоны, поэтому я использую «пустой», но с параметром пробела для опции шаблона в моей конфигурации $ routeProvider. Это позволяет мне выполнять обычные запросы ajax CI без особого изменения исходного кода на стороне сервера.

 angular.module('my_app', []). config(['$routeProvider', function($routeProvider) { $routeProvider. when('/', { template: " ", controller: my_routes.mainpage}). when('/design/:designId/:action', {template: " ", controller: my_routes.show_design}). when('/vote_design/:designId', {template: " ", controller: my_routes.vote_design}). otherwise({redirectTo: '/'}); }]); 

Лучше всего сохранить код бэкэнд отдельно от углового кода и использовать код codeInginter как API

/ Codeigniter Code / Угловой код

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

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

Все, что зависит от стандартной структуры CI, – это несколько папок: js\angular\controllers и js\angular\modules в папке приложения CI, чтобы хранить все угловые модели и файлы контроллеров. Затем загрузите угловые документы в папку с базой приложений.

В дополнение к ответу, предоставленному Аароном Мартином, его можно также использовать как клиент-серверный подход.

Допустим, мы создали две папки в корне нашего проекта:

1. клиент

2. сервер

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

Будут фабрики или службы, которые будут выступать в качестве поставщиков для угловых на стороне клиента. Этот файл будет содержать код отправки запроса и получения ответа со стороны сервера.

Папка сервера будет иметь код Laravel или CodeIgniter или любую другую фреймворк PHP. Вы создадите все API-запросы и соответствующим образом разработаете функциональные возможности. Следовательно, раздел PHP (Server Directory) в целом будет хранить все файлы мультимедиа и файлы базы данных. Кроме того, он также будет иметь любые получающие ссылки для RSS-каналов и так далее.

Клиент должен получить весь ответ в формате JSON или XML, когда он запрашивает какой-либо API на своем сервере.

Это, по моему мнению, является одной из лучших практик разработки Webapps.