Как сделать админку ?

[TTT]

Как сделать админку ?
дайте пример как должен быть выглядеть контроллер, модель и вьюха для админки.

это жесть сижу уже битый второй день, что бы сделать несчастную простуб админку в которой всего то и надо создавать и редактировать страницы.
много вложеных проверко, потом еще и циклов что бы получить то что там в $data[] которая во вьюха передалась. говнокод реальный.

задание такое у меня.
в админке грузится табличка со страничками сайта из бд

БД

id | name | text

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

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

Заранее благодарю.

[Viktorius]

Ага, я тоже озадачился над этим вопросом,
действительно гомнокод выходит, может можно несколько массивов во VIEW передавать?

[Tovit]

Если Вы так круты без CI, то почему с ним не можете реализовать AJAX-форму редактирования контента на той же странице?

Или я не правильно понял проблему?

По-моему, вы ищете легкой жизни...
Возможно тогда Вам больше подойдет тяжеловес вроде Symfony. Или Django... но это уже другой язык программирования.

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

[aktuba]

это жесть сижу уже битый второй день ... я без Ci такое задание за пять минут сделаю а в CI получается говнокод с боками

Без CI 5 минут, а с CI 2 дня? Это как? o_O CI язык поменял или что??? Бред какой-то...

[Viktorius]

Лично я не сказал что на CI дольше, просто гомнокодно выходит как то
Взять даже стандартный пример DX_Auth.. Честно говоря лажа, хотя библиотека прикольная

[Tovit]

Взять даже стандартный пример DX_Auth.. Честно говоря лажа, хотя библиотека прикольная

Разъясните последнее предложение...

Лично я не сказал что на CI дольше, просто гомнокодно выходит как то

Я понял Вас. Возвращайтесь обратно к процедурному программингу с php-функционалом в HTML -- это все таки Высший пилотаж. Оставьте CI говнокодерам, с их структурным подходом и MVC-патернами.

[Viktorius]

Я понял Вас. Возвращайтесь обратно к процедурному программингу с php-функционалом в HTML -- это все таки Высший пилотаж. Оставьте CI говнокодерам, с их структурным подходом и MVC-патернами.

Честно говоря я не совсем понимаю сарказма и злорадства г-на(жи) Tovit, но касаемо темы
мне интересно как красиво структурно разделить backend и frontend, может кто то может поделиться примером.

[michail1982]

пример админки

[Big_Shark]

Кстати неплохая статья.
Может кто переведет да выложит на сайт?
P.S. Я использую Sub-directories

[radioheaded]

Давайте я попробую, только помогите с форматированием, пожалуйста. Давно с вики не работал.

[radioheaded]

Вот, весьма вольный перевод — http://code-igniter.ru/wiki/FAQ:%D0%A1% ... D%D0%B0_CI. Поправьте, пожалуйста, если не туда поместил или чего не так оформил.

[Viktorius]

О! Спасибо! Интересная статья!

[snake.nf]

Когда используются два приложения (frontend и backend) часто в них есть общие модели. Возникает вопрос, что делать с этими моделями?
Есть два пути:
1. Просто дублировать модели в обоих приложениях
2. Вынести глобальные модели за пределы моделей приложений?
В связи с некошерностью первого варианта, хотя можно использовать символические ссылки в *nix системах (если есть доступ к консоли), я смотрю в сторону второго варианта.

Получается такая структура каталогов:
ci_application
ci_application/backend
ci_application/frontend
ci_application/models (или global_models)
ci_system

В этом случает, снова появляются две возможности:
1. Исправить в Loader.php две строки с путём к моделям в приложениях на путь к глобальным моделям:
Строка 162:

Код: Выделить всё

if ( ! file_exists(APPPATH.'models/'.$path.$model.EXT)) 

и строка 180:

Код: Выделить всё

require_once(APPPATH.'models/'.$path.$model.EXT) 

Но, тогда мы лишаемся возможности использовать локальные модели для каждого приложения, что не является true way.

2. Создать собственный класс ядра MY_Loader расширяющий Loader.
добавить global_model загружающий глобальные модели (функция global_model дублирует model за исключением двух строк описанных выше). При этом останется возможность использовать и локальные модели (model).
MY_Loader.php придётся закинуть в оба приложения, в libraries.
Считаю такой вариант наиболее оптимальным, т.к. это не вност изменения в ядро системы, легко переноситься в другие приложения, не требует лишних телодвижений при обновлении CodeIgniter'а.

Естественно нельзя использовать локальные и глобальные модели с одинаковыми именами. В контроллерах, за исключеним замены $this->load->model('Model_name'), на $this->load->global_model('Model_name') для глобальных моделей, ничего менять не придётся, т.к. мы только расширим Loader.

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

P.S. Данный способ пока не испробовал, но планирую в ближайшее время этим занятся.

[radioheaded]

С хэлперами, библиотеками и плагинами вы так же собираетесь поступить? По-моему, какой-то левый костыль. Может быть, для такого подхода вам стоит подыскать другой фрэймворк? С другой организацией каталогов.

[Big_Shark]

Когда используются два приложения (frontend и backend) часто в них есть общие модели. Возникает вопрос, что делать с этими моделями?
....

А как же библиотеки? а конфиги?
Слишком нагруженный вариант получиться.

[snake.nf]

С хэлперами, библиотеками и плагинами вы так же собираетесь поступить? По-моему, какой-то левый костыль. Может быть, для такого подхода вам стоит подыскать другой фрэймворк? С другой организацией каталогов.

По поводу плагинов всё сказано в документации:

Plugins should be saved to your system/plugins directory or you can create a folder called plugins inside your application folder and store them there. CodeIgniter will look first in your system/application/plugins directory. If the directory does not exist or the specified plugin is not located there CI will instead look in your global system/plugins folder.

Как не странно, но про хэлперы там тоже написано:

Helpers are typically stored in your system/helpers, or system/application/helpers directory. CodeIgniter will look first in your system/application/helpers directory. If the directory does not exist or the specified helper is not located there CI will instead look in your global system/helpers folder

Теперь про библиотеки:
Если вы не заметили, то я предложил сохранить расширение библиотеки в приложениях. Но, если библиотека используется всеми приложениями и не является расширением библиотеки ядра, то почему бы её не хранить с библиотеками ядра?

Можно указать где разработчики CodeIgniter'а рекомендуют с "таким подходом" обратить свой взор на другие фреймворки. Или это исключительно Ваши умозаключения?

[snake.nf]

Когда используются два приложения (frontend и backend) часто в них есть общие модели. Возникает вопрос, что делать с этими моделями?
....

А как же библиотеки? а конфиги?
Слишком нагруженный вариант получиться.

Количество конфигов пропорционально количеству приложений.

Библиотеки то же разные бывают. Библиотеки расширяющие библиотеки ядра в libraries приложений. Библиотеки которые дополняют ядро, к системным libraries.
Например если у вас свой template engine, который используется в нескольких приложениях на базе одной системы, то хранить в каждом приложении по копии библиотеки довольно глупо, особенно в плане поддержки сайта. При внесении изменений/обновлении template engine проще изменить/заменить один файл, чем несколько его копий. А если поддержкой занимется несколько человек и каждый занимается своим приложением?

[radioheaded]

С хэлперами, библиотеками и плагинами вы так же собираетесь поступить? По-моему, какой-то левый костыль. Может быть, для такого подхода вам стоит подыскать другой фрэймворк? С другой организацией каталогов.

По поводу плагинов всё сказано в документации:
Как не странно, но про хэлперы там тоже написано:

Можно указать где разработчики CodeIgniter'а рекомендуют с "таким подходом" обратить свой взор на другие фреймворки. Или это исключительно Ваши умозаключения?

Ну там и про модели еще написано, и про контроллеры, и еще много про что. Я о том, что вы слишком многое пытаетесь переделать в дефолтной установке CI. Можно же вообще переписать и лоадер, и файл index.php для своих удобств, и вообще половину системных классов, но не проще ли подыскать фрэймворк, который сразу будет подходить под ваши требования, чем ломать и затем строить из обломков? Конечно, это мое мнение, я где-то написал иначе?

[snake.nf]

Ну там и про модели еще написано, и про контроллеры, и еще много про что. Я о том, что вы слишком многое пытаетесь переделать в дефолтной установке CI. Можно же вообще переписать и лоадер, и файл index.php для своих удобств, и вообще половину системных классов, но не проще ли подыскать фрэймворк, который сразу будет подходить под ваши требования, чем ломать и затем строить из обломков? Конечно, это мое мнение, я где-то написал иначе?

Расширение модуля ядра - это не переделка дефолтной установки.
Какие обомки? Где было что-то сломано? Наоборот я не хочу использовать костыли в виде HMVC и Matchbox. Ну не поддерживает CodeIgniter модульность, следовательно в "дефолтной установке" остаются отдельные приложения и вложенные каталоги.
Мне удобнее использовать отдельные приложения, чем и являются сайт и его административная часть, тем более, что backend'ов может быть несколько...
Я в отличае от Вас не навязываю другим свою точку зрения, а предлогаю конкретный вариант решения конкретной проблемы.
В ваших же, словах я не вижу каких либо конструктивных предложений, только абстрактные, ничем не обоснованные реплики о поисках друго-го фреймворка, каких-то поломках, собираниях из обломков...

Ещё раз прошу указать где разработчики CodeIgniter'а рекомендуют с "таким подходом" обратить свой взор на другие фреймворки.

[radioheaded]

Ок, видимо, неверно вас понял. Как что-то получится — отпишитесь, если не трудно.

Еще раз прошу указать, где я сказал, что это мнение разработчиков, а не мое личное?