о! уже вопросы по существу пошли радует! 1) для начала надо создать модуль голосований (допустим он будет называться Vote). модуль вписывается в табличку engine_modules. далее определяемся с местом куда будет выводиться этот модуль, допустим это будет правая область, допустим этот конетейнер будет называться right-block. допустим голосовалка будет прицеплена на главной страничке и отображаться на всех страничках, для этого создаём ноду где указываем ИД папки (в нашем случае корневая), ИД контейнера right-block и ИД самого модуля (а нашем случае Vote). но чтобы эта нода наследовалась вглубь находясь к корневой папке надо указать флажок для корневой папки engine_folders.transmit_nodes = 1, а еще добавить в табличку engine_containers_inherit связочку указав ИД нашей корневой папочки и ИД нашего контейнера right-block. вот собсна и всё ))) 2) в JEngine (кстати это не конечное название, пока думаю как его назвать ) блоками можно назвать механизм контейнеров т.е. такой объект, который содержит в себе определённые ноды. для того чтобы контейнер был только в определённой одной папке надо создать этот контейнер, а затем добавить ноды которые будут подвязаны к этому контейнеру, и требуемой папки. 3) скрипты модулей сейчас хранятся в \includes\Modules\[module_name] каждый модуль находится в своей папке, для написания модуля есть свои некоторые тревабония, можно сказать API. чтобы модуль стал доступен для работы в системе, надо прописать его в табличку engine_modules. На счет админки, там сейчас работает только добавление модуля Текстера, а все остальные будут вываливаться с ошибками. также бак-енд адмика сейчас далека от идела даже по своей концепции... но до ней как-то меньше всего руки доходят... т.е. у меня сейчас задачи довести двиган до уровня когда уже можно делать хотябы простые сайты, а бак-енд админка в этих случаях не всегда нужна...
в демке сейчас мягко говоря ничего серьёзного нету, в инет я её не выкладываю по причине отсутствия вообще какой-либо секурности... да и по внешнему виду о движке вообще ничего нельзя сказать... самое главное это сама концепция, если кому-то она приглянётся, то буду очень рад сотрудничеству но концепцию надо смотреть внутри т.е. сам исходних и БД. оффтоп: а что значит ТС?
Мысли кстати у человека в правильную сторону направлены. Потом он ткнется проблемы конфликтов нод, тыкающихся в один и тот же контейнер, появятся приоритеты, потом ткнется проблему взаимодействия модулей и расширения модулей другими модулями... в общем, еще будет весело! //offtop «Jчеготототам» обычно называются программы, написаные на яве ))
контейнеры это логическое объединение нод ,в контейнере может быть столько нод, сколько нужно для выполения задачи. естесвенно у всех нод есть свой порядковый номер укаывающий порядок их подключения в контейнере. (в JEngine нода - это точка подключения модуля с определёнными параметрами). для взаимодейсвия модулей есть идеи, но они пока только в голове... (пока думаю назвать этот механизм NodeBridge и он будет ессно в ядре), как дойдет дело до модуля каталога, тогда же и реализую например чтобы для модуля менюшки отдавать категории каталога. на счет расширения функционала тоже есть идеи, но думаю, что это будут уже не модули, а компоненты, например компонент wysiwyg, сам по себе он не представляет интереса, зато его могут цеплять другие модули. есть еще идея сделать некий базовый механизм каталога (например в виде компонента), а на нём уже делать надстроечки в виде модулей, например фотогалерея или просто обычный каталог продукции.
флоппик Ну насчёт register_globals ты не прав, ИМХО. Работать то оно и при нём будет, но давно доказано, что это огромная дыра в безопастности и признана идиотской вещью разработчиками, так же как и magic_quotes и safe_mode. Всё это принудительно выкидывается и более не существует. Так что правильно зарание такие вещи отключать и не использовать.
Я готов согласится с любым аргументированным мнением. Покажите мне пример кода, который перекроет запрограммированое значение переменной в случае ее принудительной инициализации в скрипте при включенном регистер_глобалс.
флоппик PHP: <?php while(что-то тут где $i++) { if($i > чего-то тут){ $q = true; } } if(isset($q)){} Так вот, а если $q в цикле не определилась? А через гет я её определил? То что? Условие выполниться!
PHP: <?php $q = false; while(что-то тут где $i++) { if($i > чего-то тут){ $q = true; } } if($q){} Приведенный тобой код не является корректным, т.к. допускает неопределенное поведение. Я уже писал, для меня вопрос состоит в том, что мешает писать корректный код, вместо того что бы падать с die() в конвульсиях, изза РГ ?
Олег, смотри, отличительной особенностью ПХП является то, что переменные не обязательно объявлять заранее перед использованием. Это удобно. Это часто применяют многие разработчики. Называть данный код некорректным нельзя. Потому что некорректным кодом называется код который не решает поставленную задачу. Если код не решает задачу по причине ошибок разработчиков пхп, это не означает, что он некорректный. ИМХО, разработчики пхп сильно наипались с регистр глобалс и тем, что переменные не надо объявлять заранее.
При инициализированной переменной проблем не будет, но в глобальном плане может возникнуть ситуация, когда из GET/POST/Cookies пришло значение и при register_globals On оно превратилось в глобальную переменную. В конце концов мы же не можем уследить за всем всем всем и нечайно не оставить какое-то место, где такое поведение превратиться в баг? А ещё из-за variables_order могут случатся и не такие казусы. Откуда знаем что на хостинге настроено. Ты полагаешься что в случае чего там будет данные из POST, а на другом хостинге может оказаться что последним инициализируется вообще GET. Т.е. тут нужно думать не о том, что ты всё знаешь и зарание продумал. Некоторые вещи от нас не зависят вообще и могут быть сделаны обсурдным путём кем-то другим, а нам потом мучайся. И не раз мы сталкивались с абсурдными действиями других людей, а для них это нормально. Неинициализированная правильно переменная это только часть проблемы, а проблема не только техническая, но и идейная. К тому же ещё есть и рекомендации разработчиков и другие документы об обратной и будущей совместимости. Механизм depricated по сути уже 6-й год, поетому чисто идейно с его использованием работать не должно. Таковы требования будущей совместимости.
Где я предлагаю пользоватся регистер_глобалсом??? Я полагаюсь на то, что данные из POST будут в $_POST, а данные из GET будут $_GET. А теперь представим, что PHP6 уже вышел. Что произойдет на строчке PHP: <?php if(ini_get('register_globals')!='off') die ('register globals must be off!'); ? В общем, мне ясна ваша точка зрения. Предлагаю тогда добавить строки PHP: <?php if(ini_get('register_long_arrays')!='off') die ('long arrays must be off!'); Discuss.
вот подумалось, что если народ сам начнёт задавать самые каверзные вопросы как сделать то-то и то-то на движке, а я это буду расписывать, то ускорится понимание сути движка, да и сам лучше пойму как доходчиво написать документацию т.к. будет ясно, что нужно знать людям открыл темку тут http://digi.org.ru/engine_forum/index.php?topic=4.0