| esclkm |
|
|---|---|
|
Прашла большая часть времени, с того момента как я начал изучать сед, но пока не все так явно открыто и понятно.
Суть: понадобилось создание своего модуля, который бы использовал бы категории от страниц, а остальные аспекты от форумов. Смысл всего этого совершенно третий. итак с самого начала начались проблемы. 1. главный файл кидай в корень 2. админка. это вообще набор проблем. ибо ее нельзя с модулем в один папка. да и в целом админка не подцепит ничего - только долгие маневры раскидывания по папкам и редактиврования шаблонов. в итоге пришло решение делать через тулзы. на практике это просто не рационально, либо юзай плагины для полновесного модуля. опять не хорошо. Для этого юзал последнюю стабильную версию В общем интересны ваши идеи и решения Добавлено 11 Минут спустя: 3 еще не совсем додумал как сделать чтобы в оном модуле разные его разделы были доступны разным людям Добавлено 2 часа 46 Минут спустя: спустя часть работы - понял: что в 07-09 надо делать общий стартер - например индекс ПХП, админку раскидывать в модули, и даже неудаляемые модули тоже вынести ко всем (вдруг ктото решит сделать альтернативных пользователей) по русски просто модуль и плагин привести общему знаменателю littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
|
| This post was edited by esclkm (2010-04-24 21:37, 14 years ago) |
| Alex300 |
|
|---|---|
|
На текущий момент есть только вариант: делать через tools. В ней делать настроойку и админ часть большого плагина. Пользовательскую часть через standalone - часть.
Насчет нерациональности такого решения: я не вижу особой разницы между существующими плагинами и планируемыми модулями. Она скорее логическая (Модуль по сути - это большой, глобальный плагин - такое, вроде планируется). К примеру в тоже же джумле - есть четкое разделение на компоненты, модули, и плагины, а внутри них четкое деление на бэкенд и фронтэнд части. Это очень правильно на мой взгляд. CMS лекго "подхватывает" админчасть дополнений без лишних доп. настроек и правки шаблонов. И это правильно и хочется это видеть в коте. > 3 еще не совсем додумал как сделать чтобы в одном модуле разные его разделы были доступны разным людям Можно через встроенную систему прав для групп. Добавлять соответствующие записи в БД можно тоже через tools часть плагина. > надо делать общий стартер - например индекс ПХП. Это решение необязательно. Главное - это нужна система управления модулями. Чтобы админка могла "подхватывать" админ. часть модуля без хаков, лишней правки шаблонов и т.п. ненужных телодвижений. Есть миры, не здесь, там, где небеса горят, и моря засыпают, и реки дремлют; люди сделаны из дыма, а города – из песен. Где-то опасность, где-то несправедливость, даже где-то остыл чай. Идем Эйс, у нас много работы!...
...Sorry for my english... Бесплатные расширения для Cotonti: https://lily-software.com/free-scripts/ |
| Sergeich |
|
|---|---|
|
По поводу подхвата админки модуля, - в папке админского скина сделать подпапку, в которую скиндывать все админ-tpl модулей (также как в папке простого скина для плагинов сделано). Всё остальное я не понял, поэтому ничего не говорю
 |
| Kort |
|
|---|---|
|
Админовский скин формально еще не существует. Есть только набор tpl'ов.
http://www.cotonti.com/forums.php?m=posts&p=24223 Я бы предложил подхват шаблонов модуля делать аналогично связке скин - шаблон плагина. Т.е. модули идут в комплекте с родными шаблонами. Кому надо перенесет в "свою" админку и доработает под свой стиль и требования. SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| Sergeich |
|
|---|---|
|
Kort, это перебор, как мне кажется. вполне достаточно иметь один скин админки, плюс возможность его менять по желанию заказчика ручками, для этого не нужны никакие мультискины. По поводу нести базовые шаблоны на борту модуля в принципе согласен, но всё же лучше сразу кидать их в папку админ-скина, главное чётко разработать правила создание этих самых шаблонов, с точностью до вёрстки и названия CSS-классов.
|
| Kort |
|
|---|---|
|
Эталонный скин не должен меняться по желанию заказчика. Чем больше будет "ручных" манипуляций - перекинь то, замени это - тем больше будет ошибок.
Применительно к шаблонам: Если я обновляю плагин, я переписываю заново весь его каталог (включая проверенный рабочий шаблон), а после -- модернизирую tpl из комплекта своего скина. Если я обновляю систему, я переписываю поверх пакет обновлений (который может содержать и обновления в шаблоне админки), а потом, имея возможность "аварийного" переключения на этот самый эталонный шаблон или скин, довожу до ума собственный шаблон / скин админки. А иначе будет балаган: тут меняли, тут не меняли, тут ручками перенесли, а тут случайно поверх записали. А соглашение по оформлению шаблонов -- вещь нереальная даже в обозримом будущем. SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| esclkm |
|
|---|---|
|
ребят не оффтопте.
смысл этого топика сделать общий (!) удобный механизм создаения больших модулей. я считаю что наиболее рационально для этого использовать общий стартер - так для standalone плагинов. И сделать чтобы админка была настраиваема автоматически. то есть установил БОЛЬШУЩИЙ МОДУЛЬ а он через систему хуков добавил на себя иконку в меню админки. чтобы все было маскамильно удобно littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Dayver |
|
|---|---|
| Trustmaster |
|
|---|---|
|
Ну с админкой дело ясное. Во-первых, у модулей будут setup-файлы, данные из которых при установке заносятся в БД, так что движок знает, что у него установлено. Во-вторых, у модулей будут admin-файлы, реализующие тот самый backend и подцепляемые собственно админкой. В-третьих, про скины Kort уже все объяснил.
С правами: да, для модулей надо добавить возможность добавлять вложенные объекты, на которые права задаются так же, как это сделано в Страницах и Форумах. Больше сильно усложнять не надо. Насчет превращения index.php в лоадер есть очевидный плюс и очевидный минус. Плюс: меньше копипасты. Минус: отвалятся старые ссылки без mod_rewrite. Другие хотелось бы услышать. May the Source be with you!
|
| esclkm |
|
|---|---|
|
тут не доконца соглашусь что все отвалится)
ведь можно сделать все хитро) 1. mod_rewrite 2. кто мешает сдать библиотечку небольшенькую - для совместимости стаых ссылок. то есть просто кидаемые в корень page.php forum.php и тд в которых заточка под старые форматы имен? 3 у нас итак к 09 слишком большое улет...обртаная совместимость моментально нарушится... без плагинов и всего прочего littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Kort |
|
|---|---|
|
Mod_rewrite -- это немного вещь в себе. "Совместизатор" было бы надежнее. Модули должны быть легко и удобно создаваемы -- Котонти все-таки фреймворк для создания сайтов, и развитие ему могут дать только разработчики, а не слабенькое коммьюнити. Но конечно, и так и так будет снова безумное негодование как в ветке про HTML-парсинг и аргументы типа "не меняйте ничего: у меня 100000 страниц набрано, и если я не переберусь с Генуи на Сиену, моему супер-порталу будет крышка". Очевидно кроме логики и аргументов нужна еще и дипломатия
SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
