Этот вопрос первичный. Этот вопрос когда-то может стать гигантской проблемой. Это очень грубая ошибка. Интересно, а какой вопрос первичный для Вас? Мы еще такого не озвучили, как я заметил. Из наших замечаний и складывается вся система. По поводу архитектуры - сейчас большинство гоняется за MVC. По поводу подключения блоков и модулей ничего не скажу, ибо не моя специфика.
Kreker Вторичным на мой взгляд являются моменты, которые при ближайшем рассмотрении я и сам обнаружу. Вы конечно сделали некоторую работу за меня, поэтому спасибо громадное, но мне важно понять именно такой механизм формирования контента имеет место быть или он ошибочен. Все остальное мелочи, которые я обнаружу и исправлю при детальном рассмотрении всех скриптов. Спасибо. Yii на этом и построена. Возможно кому-то подходит, но мне интересна моя система, до тех пор пока мне не помогут понять ее иррациональность.
2) модуль news - параметр limit нельзя поменять PHP: lass news extends core_api { private $limit = 20; в классе news нет метода установки параметра limit . Как ты установишь значение limit=10?создашь новый класс? 3) в одном и том же классе получение данных и их визуализация Такой подход предполагает, что ничего менять в дизайне и в логике не придется. Ты в этом уверен? Далее- многие атрибуты просто "зашиты" в код. По моему, это тоже не очень удобно 4) ограничения на названия ИМЕНА БЛОКОВ, МОДУЛЕЙ, МЕТОДОВ И ПОЛЕЙ БД - это вообще разные понятия и используются в различных контекстах. Получается так, что если я назвал блок и поле одинаково, то поле будет использоваться в качестве блока?
По молчанию БД заточена именно под UTF-8, что в общем не мешает принудительно указать кодировку таблицы. У самого 1251, на которой работают и зарубежные сайтики без проблем. Нужно только таблицы тоже в 1251 делать. А вот с экспортом цмски в Китай будут проблемы, да-да
runner Я вам ответил на предыдущей странице. Хотя про limit видимо изначально не понял что вы хотите сказать. Откуда вы его хотите поменять? Из админки нельзя его поменять. Меняется он программером ручками, вместо $limit = 20, напишите private $limit = 1. Проблема собственно в чем? В том же модуле news нет HTML непосредственно в коде, есть подключение TPL-ов. Поэтому я уверен в том, что изменить темплейт не проблема и в код заглядывать не нужно. Если где-то встречаются в модулях html вставки, то это только потому, что было лениво использовать местами TPL, со временем все это причешется. Я для себя определил правило, все поля в БД имеют префикс bd_, все методы модулей имеют префикс md_ таким образом проблемы решены. В любом случае главное чтобы были уникальные названия классов (модулей), но это вполне естественно. Если в конкретном модуле имеется метод myfield и в данном модуле используется запрос к таблице в которой есть поле myfield то указав в TPL сепаратор вида {%myfield%} выполнится метод класса и поле из таблицы БД не отобразится. Это частный случай. Чтобы не возникло совпадений желательно использовать префиксы в названиях.
Предположим, что тебе нужно вывести новости на двух разных страницах - на одной по 5 новостей, а на другой 10. В этом случае тебе придется создавать два разных класса. Если в твоем понимании это удобно, то вопрос исчерпан
runner Я с подобными задачами не сталкивался и не уверен что необходима подобная реализация, но и здесь у меня заготовлено нечто. вместо public function news() мы прописываем public function news ($args) и в коде функции прописываем следующее $this->limit = $args[1]; Теперь через админку создаем две страницы на которых вам необходимо вызвать модуль news. На первой странице вы прописываете {%news:5%}, на второй {%news:10%} Задача решена. По-моему удобно.
теперь понятно, вроде бы, должно быть удобно, но больше на шаблонизатор похоже с множеством подшабнов
Мне само утройство всей этой штуки не нравится т.е. CMS система управления контентом нужна возможность 1. добавления 2. удаления 3. редактирования 4. просмотра значит нужно определять роль пользователя по отношению к контенту конечно на каждой странице должно быть меню из ссылок на разные модули текущего компонента и вывод ссылок или результаты работы других зависимых компонентов в разных местах на странице каждый компонент может быть быть подключен к другому и иметь не ограниченное количество зависимых компонентов, нужна возможность выбирать тип подключения, ссылка, результат работы и место расположения дочерний компонент должен запрашивать необходимые для работы переменные из родительского что бы не получилось каши, на вскидку нужны службы определия прав доступа, фабрика для страниц, компоновщик нужно разработать жесткую спецификацию компонента, пусть он работает у себя в песочнице, со своими шаблонами и прочим тогда не нужны будут никакие блоки по типу {%news:5%}, всем будет управлять ничего не понимающий в программировании пользователь это первое что приходит в голову, на самом деле нужно, эксперемениторовать, расмышлять, проектировать, постоянно заниматься рефакторингом, что бы получилось что то гибкое
Padaboo Честно говоря пользователю здесь выделена одна функция - изменение контента, все остальное должно быть скрыто от его глаз. Мы с вами по разному воспринимаем продукт. Изначально не стояла задача наворачивать систему, как это сделано у bitrix. Здесь задача стояла следующая: упростить работу с сайтом программисту и дать возможность администратору вносить изменения в контент, будь-то новости, гостевая книга или полноценный магазин. У пользователя изначально не должно возникнуть желания изменить модуль, шаблон и т. д. А для программиста здесь как раз представлен удобный инструмент. Отредактировать шаблоны, подправить некоторые модули по необходимости и все это выполняется в стандартной для него форме. При этом для программиста не составит труда расширить систему собственным модулем, дополнительных знаний и сложных конструкций это не потребует, модуль создается так, если бы он программировал его отдельно от системы. В этом-то вся прелесть на мой взгляд. В итоге мы имеем: фронтэнд - просто в использовании и расширении бэкэнд - удобная возможность для юзера обновлять контент. А все, что вы выше описали это серьезные системы требующие несколько иного подхода и необходимость в таких системах частная, как правило их используют для простых вещей, что не рационально с точки зрения затрат и обучения тех же юзеров. К примеру взять joomla, есть целый компонент virtue mart (интернет магазин) после его установки мы получаем систему в системе и для его настройки понадобится слишком много времени, не говоря уже о настройке шаблонов, также компонент универсален, а следовательно избыточен. В случае моей системы можно настроить модуль и админку для конкретного случая. В общем как-то так. Что вы имеете в виду? Желательно примеры. Для чего это нужно? В системе нет компонентов, есть модули и каждый модуль независим, определяющим понятием является "страница" на которой был вызван модуль. Модуль определяет поведение страницы. На странице может быть несколько модулей и их взаимодействие между собой определяется программистом. Подключение основных модулей происходит в основном шаблоне. В той же joomla позиция модуля определяется по разметке через id HTML элемента и в админке отображается списком, я не вижу проблемы в том чтобы редактируя шаблон расставить модули руками при верстке, в случае joomla необходимо добавить контейнеры, здесь же необходимо добавить название модулей. Вы видите принципиальную разницу? В любом случае описанное вами можно реализовать без каких либо особых сложностей. Возможно в будущем я это сделаю. Что для вас "дочерний компонент"? У модуля (читать у класса) существуют методы, они отлично взаимодействуют внутри класса и передают любые необходимые переменные. С этим согласен, в будущем это будет реализовано. Это не блоки, это и есть модуль, но в модуль для управления при необходимости можно передать управляющий параметр, это используется в редких случаях, в основном каждый модуль самодостаточен и не требует ввода дополнительных параметров. А давайте зададимся вопросом, чем именно он будет управлять? Мой ответ. Он будет управлять контентом, а для управления контента у него есть все возможности и заглядывать в код ему нет необходимости. Так или иначе если пользователь захочет расширить возможности сайта, а именно подключить к сайту модуль интернет-магазина ему как минимум не избежать редактирования шаблонов, а если он справляется с этим, то он явно не пользователь. Мне бы было проще на конкретных задачах и примерах разбирать недостатки и достоинства. Как я уже говорил на системе отлично работают 4-е интернет-магазина, на мой взгляд это сложная задача для любой CMS и как раз гибкость системы здесь сыграла важную роль. Если есть примеры задач, которые необходимо решить при помощи системы, напишите, обсудим. Спасибо.
Урок, который я вынес из своих 5 лет разработки и поддержки собственных велосипедов, не создавать если за детищем не стоит команда, способная его поддерживать и разрабатывать далее. В процессе возникает столько проблем и постоянная нехватка функционала, что требует половину, если не большую часть времени на доработки, исправление багов и обновление. Я уж не говорю о промахах проектирования и невозможности с кем-то посоветоваться толком. Очень тяжело посмотреть на систему отвлечённо и понять, что половина сделана абы как, лишь бы работало, и назрела острая необходимость всё это переделать. А времени нету, работы куча и просвет не ожидается ещё долго. И так по кругу. В итоге приходишь к одному из двух: Так и работаешь в непонятной атмосфере, с первыми попавшимися проектами, неадекватными клиентами и кучей багов, недоработок. Ругаешь себя, заводишь отдельный рабочий телефон, который не работает вне рабочее время ну и так далее. Градаций много - от "бабло платят, остальное пофиг" до "я ненавижу эту работу, но деваться некуда!". Бросаешь это дело нафиг и уходишь в определённую нишу по специализации, которая лежит к душе. Постепенно проекты растут в размере и серьёзности, суммы тоже растут. Возможно в итоге зарождается собственный бизнес. Делаешь свою работу хорошо, дорого и можешь себе позволить отпуск 2 раза в год где-нить у чёрта на куличках, радуешься жизни и растишь детишек Это общие такие стереотипы, так сказать основные 2 линии. Мир у нас естественно серый, но мой опыт показывает что это близко к правде. Начинал я как и все - 300$ в месяц, график отсутствал, ночёвки на работе. Сейчас у меня есть определённая специализация - только объёмные проекты, только сложные и только те, где есть верстальщик, дизайнер, админ (т.е. нормальные рабочие условия) и есть чёткая планка по оплате - в месяц не должно выходить меньше 2к$. Как ни странно, работы раза в 3 больше предлагают, чем я способен сделать.
Psih У меня как раз 2-й вариант. Во многом с вами согласен, но если ничего не создавать и даже не пытаться, то смыслом жизни станет только рубилово бабла, а в этом есть свои недостатки. Я люблю программинг и свою работу, так уж совпало, что я зарабатываю тем, что бесконечно люблю. Поэтому ничто мне не мешает разрабатывать то, что на мой взгляд имеет смысл ну и практика, которая сама по-себе огромный плюс в деятельности любого специалиста.
Apple Я ж вам даже ссылки дал где вас ждут, а вы все не сообразите и продолжаете гадить в обществе порядочных людей.
lost_cluster Ваш послужной список как раз не говорит от специализации. Вот мой послужной список чётко показывает, что я занимаюсь только несколькими основными вещами и не распыляюсь. Если что, то выглядит это примерно так: Вот так выглядит послужной список профессионала. А не состоит из тонны аббревиатур и метаний от языка к языку. Я уже не говорю о том, что профессионалу не составляет труда в рабочем порядке изучить новые технологии и решения. Работать с другим языком на серьёзном проекте просто не станет, потому что есть понимание того, что за пол года не изучишь. И за 2 года знаний будет не так уж много, как кажется. В команде обязательно должен быть такой-же профессионал своего дела, с которым можно было бы советоваться и спрашивать что и как лучше сделать. Когда я нанимаюсь к кому-то, я чётко ставлю условие, что я не мастер на все руки и мой круг обязанностей это WEB - PHP, MySQL с HTML & JavaScript. И то сразу предупреждаю, что верстальщик я средний. С JavaScript у меня хорошо, но если нужно что-то действительно сложное - нужно поискать соответствующего человека, потому что я не занимаюсь JS так глубоко, но если надо - нет проблем. Только кол-во требуемого времени будет больше. Когда я вижу вот такое: Так и хочется задать что-нить по PHP или MySQL и посмотреть, а что в общем-то человек вообще ещё помнит и сколько он будет лазить по документации и вспоминать. Я уж не говорю о том, что задай относительно простой, но каверзный вопрос - ведь спалится по полной программе, в отличии от человека плотно работающего с PHP и MySQL каждый день и не распыляющегося на другие языки. Полезно знать, полезно их пробовать, но серьёзно заниматься нужно чем-то конкретным, а не вчера делать на Ruby, сегодня на PHP, завтра серверный демон на питоне. Багаж знаний приходит с опытом. Опыт эксперта требует хотя бы 5-10 лет плотной работы с конкретными технологиями, и далеко не накладывание сайтов на CMS с несколькими самописными модулями. Да, если вы вы уже лет 20-25 крутитесь в области, то и хорошо знать вы можете пару языков и сопутствующие им технологии и фреймворки. За 5 лет это нереально. Это вариант - всего по не многу, но толком ничего. Распылённые знания годятся для стартапа - то попробовать, это, третье. О, а это хорошо, давайте углубимся. И углубляются и вобщем-то потом уже не перепрыгивают с одного на другое. Вон фейсбук как начал с PHP, так на нём и работает. Когда развились и стала остро проблема производительности - привлекли инвесторов, наняли людей и они им уже делали бекенды.
Psih Что-то я вас не понял, к чему это все? Я не оспариваю ваши знания, а своими доволен. Я пришел спросить совет, а не на работу кого либо нанимать. Вы слишком узко смотрите на деятельность программиста. Есть такое понятие как "поддержка сайта" и через ваши руки проходят сотни, а то и более написанных на разных системах и разных языках проектов, которые необходимо поддерживать, как технически так и информационно и вы предлагаете мне зациклиться на чем-то одном и посылать в сад тех кто не соответствует моим узким знаниям? Спасибо, но я люблю хлебушек намазанный толстым слоем чёрной икры. Да и Facebook это не программирование, это идея в последствии коммерческая и для того чтобы такие идеи рождались, необходимо глобально мыслить, а не зацикливаться на послужном списке.
Psih растишь велосипеды) а в свободное время чем занимаешься? вообще ты говоришь с позиции рубки бабла, велосипед это для души) что то свое на своем велосипеде (как у тебя трекер)
Бабки можно получать и работая для души, главное правильно процесс поставить А так, играю в волейбол по выходным, катаюсь по прибалтике (в Литве был в пятницу), отдыхаю, гуляю, занимаюсь банно-водными процедурами и в таком духе
Вот это и есть проблема CP1251. При переносе с БД с одного мускуля на другой (зная что на обоих cp1251) предугадать результат можно, но НЕ ВСЕГДА - это и напрягает, по крайней мере меня. Поэтому пользуюсь UTF8 и больше ничем не болею. Но по большей мере Вы правы CP1251 или UTF8 это дело вкуса.
Мне понравилось, читабельный код, легкость масштабирования. Минусы: пользователь только редактор контента, что не есть гуд. По поводу парсинга {}, что мешает использовать прямой вызов класса, методов аля заменить парсер {%распознай_меня%} на прямой вызов $class->method(); ?
Автор тут появляется после такой "теплой" встречи? Поставил, посмотрел бегло код. Думал, что зря критикуют, но оказалось, что часто правильно. Бесконечные ошибки, отсутствие инсталлятора, выбора кодировки, нет документации, подсказки местами есть, но не там, где они реально нужны. А именно в редакторе страниц, модулей и блоков. При кешировании данные о создании файла берутся из системы. Это может занимать много времени, и перед подобными операциями нужно вызывать clearstatcache. Существуют более надежные решения. Используется функция eval("?>".$value."<?"), что считаю неправильным. В случае ошибки, будет трудно понять, как её исправить. Ну везде, куди ни посмотришь, возникает мысль, что этот фрагмент можно было сделать лучше. Там и тут "Undefined variable" и "Undefined index". Вроде бы мелочи. С другой стороны видно, что проделана большая работа. Автору желаю не обращать внимания на вопли импотентов, но учесть замечания, и вывести свою CMS на более удобный для работы уровень. PS. Да, ещё хочется видеть внизу страниц (хотя бы в демо) время генерации/выдачи страницы в обычном режиме и при кешировании.