Xpoint
   [напомнить пароль]

Пишу CMS (мысли вслух, концепции, идеи, решения)

Метки: анализ и проектирование, cms
2004-11-28 03:48:51 [обр] lance10t[досье]

Задравствуйте уважаемые старожилы форума.
прошу заранее прошения за мой "русский язык".я просто не умеею подругому.


я делаю сайты, много разных сайтов(начиная от простеньких и заканчивая большушими порталами) и приходится делать их довольно быстро.
поэтому вначале я решил поискать готовые решения
и уставил штук 6-8 разных CMS
и стал их тестировать
это были

zope
drupal
mambo
typo3
и прочие не достойные упоминания тут.

выбирал я их довольно тщательно..
и потом всетаки выбрал mambo

почему?...

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

да ведь и само количество плагинов это очень важный показатель.(вспомните far)
ведь разные програмеры не будут писать столько плагинов под дурацкую систему.
плагинов для мамбо сотни.. действительно стони.. на все случаи жызни больше 500
даже несколько разных форумов... которые интрегрируюстя в эту CMS.
в то время как для других CMS cчет плагинов шел только на десятки.

итак я начал работать с мамбо.
и все было хорошо..

система темплейтов позволяла созать оформление сайта из готрвой графики буквально за пару часов
, поставить гостевую? - 5 минут
форум - 15 минут
галерею?.. -10 минут.
и в томже духе..

все быоло хорошо до поры до времени...
пока не начиналась работа с клиентами...

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

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

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

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

потом пришло 2 больших проекта. и я опять сделал их на мамбо..
и опять выявилсь новые глубокие проблемы мамбы..
(если вы вдруг подумали.. "ну чего он зациклился мамбо и мамбо")..
я не зациклился .. просто реально мамбо это лучшее что я видел.
не даром они получили награду в 2004 году в лондоне
http://www.itsecurity.com/tecsnews/apr2004/apr174.htm
соревнуясь с маститыми соперниками типа
- KDE
- Firebird SQL
- eGroupware

Best Linux or Open Source Software
Mambo Open Source – Mambo Open Source Project
да и сайт посвещенный обзорам CMS http://opensourcecms.com/
сам работет на мамбо. =).

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

если когото интересует я конечно напишу почему мне надо написать свою CMS.
а сейчас примите просто что это НАДО.

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

надеюсь этот отчет-дневник о написании CMS будет вам интетесен а комуто полезен.
также надеюсь что если я буду ошибаться вы меня поправите.

итак продолжение следует.. =).

спустя 30 минут [обр] lance10t[досье]
  1. КЛИЕНТ-СЕРВЕР(КС)?

изучая внутренности разных CMS я все время обрашал внимание на то что 60-70% кода - это не само ядро сайта которое занимаетя выводом странички а именно административный интерфейс и все что с ним связанно.
и эта админка портит всю красоту и архетектуру ядер.
и усложняят модификацю и расширение ярдра новыми функциями.
и я подума а почемубы не сделаьть KC?
пусть в ядре вобще не будет никакой админки!..
пусть ядро просто обрабатывает команды как консоль...
например.. для того чтобы переименовать например какойто заголовок.
пусть php-админка(на сервере) не занимается рисованием интрфейса в тольео сидит и ждет команды
типа


ID-команды "12345"
кому "модуль-контент"
действие "переиминовать"
ID "123"
name "новое название"


обработать такой запрос совершенно не трудно
если все что надо "вернуть" админке так это только


ID-команды "12345"
статус "выполненно успешно"


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

выгоды в виде упрощения серверной части очевидны?..
помоему да.

а чтоже по поводу клиента?..
что это будет?
...
это будет приложение написпнное на JS которое запускается в браузере, поддерживает постоянную связь с серверном и не презагружаетя а только динамически докачивает необходимые данные..
на келиентскиц комп.
посылая на сервер запросы типа


ID-команды "12346"
кому "модуль-контент"
действие "получить данные"
ID "123"
name


админка прочсто вернет одну строчку с давными...
а JS уже отрендерит все как надо.

и предоставит пользователю интерфейс внешне похожий на windows на простой explorer
это чтобы пользователю нидайбох не пришлось чегото нового учит и привыкать.


у этого решения есть большой минус.
этор трудно сделать на JS ... трудно но можно!..
и я это сделаю. =).


в следующих главах..

  1. модульная архитектура php-ядра
  2. особенности кроссбраузерного JS
  3. проблемы с реализацией JS клиента
  4. СSS на грани возможностей.
спустя 8 часов [обр] Антон Иконников(0/30)[досье]
Вы знаете, на этом форуме принято использовать русский язык. Может быть в следующих главах попробовать уделить внимание именно ему?
спустя 54 минуты [обр] Алексей В. Иванов(0/2861)[досье]

Антон Иконников[досье] Не понятен Ваш сарказм по поводу русского языка. Во-первых, автор сразу извинился, во-вторых, русский язык у него хороший (синтаксические ошибки у всех есть), ну а в-третьих, не все участники форума живут в России.

lance10t[досье] По тексту комментариев пока дать не могу, но отдать должное за проделанный труд надо. Начало хорошее, но, есть один вопрос - почему Вы решили, что сделаете все лучше? CMS - довольно большая система. Неужели все, что Вы видели, написано настолько неграмотно и нерасширяемо? Вы собираетесь брать какую либо базу или framework?

спустя 2 часа 12 минут [обр] lance10t[досье]

Антон Иконников[досье]
вы знаете у меня ведь даже букв нету русских на клавиатуре...
итак в слепую печатаю.
Алексей В. Иванов[досье]
"почему Вы решили, что сделаете все лучше?"
я ждал подобного вопроса и у меня есть ответ.

  1. у меня есть опыт использования.. в реальных условиях.

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

во многих случаях CMS пишут просто програмеры-писатели.
а не webdesign компания которая массово использует CMS.

вот несколько примеров.

  1. webGui - очень мощная CMS . НО... её тяжело устанавливать и настраивать...

и это не недоработка!.. а просто та компания что выпускает эту opensource CMS cпециально так сделали
они просто деньги зарабатывают на оказывая поддержку.

  1. очень распространенный магазин oscommerce

(второй после phpshop'a , которому ещё достанется критики )
отлично написано в плане инфраструктуры.
но готов поспорить что авторы АБСЛЮТНО не шарят в верстке.
потому что этот магазин паталогически не преспособлен к смене дизайна.(это говорит о том что програмеры просто не используют его сами)
а мы всеравно его используем потому что лучше(для некоторых случаев) нет.

3.(плавно касаясь Intranet)
есть такая очень извесная по рейтингу sourceforge
project mangement system называется PHProject
тоже тупиковая ветвь .. при всем своем богатстве функций...
он практически не поддается модификации.


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

потому что я знаю не только PHP как некоторые разработчики... а ещё и JS(в полном обьеме,а не азы).


"Неужели все, что Вы видели, написано настолько неграмотно и нерасширяемо?"

видетели в чем проблема ...ну например тогоже мамбо.
проблема фундамента... просто когдато в далеком 2000 году собралось 4-6 програмера.. и написали простенькую CMS с поддержкой модулей. и написали несколько модулей.
эта CMS напоминала тогда детский велосипед.
потом они добавили туда новых возможностей переписали ядро..
и мамбо стало похоже уже на "мопед"...
но направление развитя оставалось прежним... и скольеко не развивай мопед... никогда не получть самолет. =))..

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

а проблема то в стратегическом планировании!..
ведь сейчас уже не свернуть.. потому что они низачто не откажутся от тех 500 плагинов.


а те которые CMS расширяемы...
например XOOPS сделаны ПОЛНОСТЬЮ на ООП...
а нафига???... зачем?..
зачем вся эта городьба?...
я конечно понимаю что можно держать например 5-6 обьектов в системе.. но зачем плодить их десятки?..
я просто не хочу тратить время на изучение этих интерфейсов.
вобщем я считаю что ООП это не панацея.. не надо пихать ООП там где в нем нет реальной необходимости.

и в своей CMS постараюсь не применять ооп(в его привычной форме). =). а только выдрав из него несколько идей.
=======================

"Вы собираетесь брать какую либо базу или framework?"
нет в программе не будет ни одной чужой строчки..
по юридическим причинам..
просто тогда я не смогу продавать этот CMS как продукт.
если там будет пару стрк взятых по GPL то и вся CMS должна быть GPL.


"CMS - довольно большая система"
да я знаю что CMS большая штуковина.
но уверен много вопросов разрешится после того когда.. я напишу про модульную структуру ядра..
(а если народ будет интересоваться то и работающие куски продемонстрирую)

спустя 4 часа 18 минут [обр] Антон Иконников(0/30)[досье]
Алексей В. Иванов[досье]
Ну, простите, shift у человека на клавиатуре есть? Есть.
Пусть в начале предложения нажимает...
спустя 3 часа 58 минут [обр] Алексей В. Иванов(0/2861)[досье]
нет в программе не будет ни одной чужой строчки..

Это чести никак не делает. Есть же свободные фреймворки, библиотеки PEAR и пр. Так же неприязнь к ООП есть зло.
Мне пока кажется, простите, что Вы не слишком трезво оцениваете свои возможности (это всего лишь IMHO, конечно). Какие сроки Вы ставите перед собой?

но уверен много вопросов разрешится после того когда.. я напишу про модульную структуру ядра..

Хорошо. Тогда я, пожалуй, попридержу критику.

спустя 59 минут [обр] lance10t[досье]

Алексей В. Иванов[досье]
"Это чести никак не делает. Есть же свободные фреймворки, библиотеки PEAR и пр."
Вы же знаете какие обязательства накладывает GPL?..
Если вы хотите иметь возможность продать свою разработку как конечный продукт а не как сервис то нельзя прользоваться GPL,,, Я же писал что это юридический вопрос.
Вы просто не представляете какая огромная разница.
Написав используя GLP я смогу продавать лиш сайты с использованием этой CMS,
а написав сам смогу продавать продукт "lance10t-CMS"(r)
произведенный компанией "lance10t inc." (С)
продавать можно саму программу!...

"Так же неприязнь к ООП есть зло."
Это вовсе не неприязнь, я же просто говорю о применении там где это и правда нужно..
Неприязнь к неоправданному применению ООП во всех ситуациях.

Вот например JS клиент он целиком на ООП.
Например интерфейс из повторяющихся элементов так и просится стать обьектно ориентированным.

спустя 1 час 23 минуты [обр] lance10t[досье]
по поводу
"Есть же свободные фреймворки, библиотеки PEAR и пр"
и это хорошо.. потому что у них можно "воровать" архитектуру и идеи и всякие решения... только это должно быть сделано более менее аккуратно.
и не пропадет их скорбный труд =)
спустя 9 часов [обр] Андрей Иванов(0/3)[досье]

lance10t[досье]
Интересно было бы услышать, каким образом будет реализована обработка ошибок =)
Это большая часть работы, которую очень редко видно.

> Вы же знаете какие обязательства накладывает GPL?..
> если там будет пару стрк взятых по GPL то и вся CMS должна быть GPL.

Наверное имеет смысл почитать сначала по-поводу лицензирования.
Потому что видно явное непонимание или вообще незнание вопроса.

По-поводу КС скажу пока только, что X в униксах был реализован по такому вот здоровскому принципу.
И сейчас они сидят курят, потому что это накладывает кучу ограничений.
А предложенная реализация КС ещё хуже.

спустя 22 минуты [обр] Алексей Севрюков(2/1280)[досье]
lance10t[досье]Андрей Иванов[досье] Офф. На форуме есть очень милое и удобное форматирование. Синтаксис описан под иконкой над окошком добавления сообщения. Изучите пожалуйста и посты будет читать намного проще.
спустя 5 часов [обр] Закиров Руслан(0/341)[досье]

Алексей Севрюков[досье]Антон Иконников[досье] Оставте критику по форматированию и языку, нам не задают вопросов, с нами делятся знаниями и опытом. Мне лично не сложно потратить чуть больше времени на чтение интересного материала, к тому же уверен, что автор тратит все равно больше времени чем я на его публикацию.

lance10t[досье]

  • Bricolage? Не рассматривали?
  • Мне кажется вы слабо подкованы в вопросах лицензий. ИМХО Вы можете использовать GPL библиотеки и при продаже продукта под другой лицензией, вы либо ставите эти библиотеки в список зависимостей. Или же делаете bundle в который включен ваш продукт под одной лицензией и библиотеки под GPL с указанием этого факта. Главное ограничение ваша работа не должна быть derrived work от GPL.
  • Только PHP?
  • Читая про интерфейс общения между клиентом и сервером, угадываю аналогии с XML-RPC. Не стоит ли использовать стандартные интерфейсы?

Жду новой части.

спустя 2 часа 38 минут [обр] lance10t[досье]

седня напишу продолжение а пока для затравки обратимся к первосточнику.
и обмусолим GPL

http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
цитирую

If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means that linking the GPL-covered plug-in with the main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your program's license which gives permission to link it with the non-free main program.

итак из вышесказанного я делаю вывод что
если в какомто классе или модуле специально не указано то ..их нельзя использовать в тесной связи с системой.

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

спустя 1 час 6 минут [обр] Закиров Руслан(0/341)[досье]

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

Перчитал FAQ с GPL полный G...PL выходит. Пошел пересматривать код и лицензии :)

спустя 10 часов [обр] lance10t[досье]

Алексей В. Иванов[досье]

 Какие сроки Вы ставите перед собой?

ну ... На то чтобы реализовать все что планирую...
полтора - 2 года..
а запустить чтото работающее конечно.. раньше.

Андрей Иванов[досье]

Интересно было бы услышать, каким образом будет реализована обработка ошибок =)
Это большая часть работы, которую очень редко видно.

По поводу ошибок я уже набил себе шишек... и пришел к выводу что должна быть центральная система сбора ошибок.

Что под этм подрузамевается?.
ну это значит что все системные хендлеры ошибок должны быть переписаны.. на свои.

  1. все ошибки php
  2. обязательно ошибки SQL
  3. и даже JS

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

/!\ однажды попущенная ошибка в SQL может привести
к тяжелым последствиям...

По-поводу КС скажу пока только, что X в униксах был реализован по такому вот здоровскому принципу.
И сейчас они сидят курят, потому что это накладывает кучу ограничений.
А предложенная реализация КС ещё хуже.

X ... это шелл?..
ну вы нашли что сравнивать!.. шелл операционки и админку CMS. y нихже требования разные совсем!
если ктото гдето использовал мотоциклетный двигатель там где должен быть промышеленный дизель.. и эта система плохо работает, это ещё не значит что мотоциклетный движок плохой..

улавливаете мою мысль?.

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

А предложенная реализация КС ещё хуже.@

Это ещё не реализация а только концепция.

Закиров Руслан[досье]

Bricolage? Не рассматривали?

никогда раньше о нем не слышал.
Как вы думаете почему эта система не широкоизвестна?
=)

Мне кажется вы слабо подкованы в вопросах лицензий.

все может быть. =) можете подкинуть ссылок?
где этот провал можно восполнить... а то я помню читал GPL и никакой радости от этого не испытывал..

скоро допишу ответ...

спустя 3 часа 25 минут [обр] Евгений Бондарев aka Eugene Bond(3/1600)[досье]
lance10t[досье]
думаю, что реализация чего-нибудь долгосрочного (1,5-2 года - это долгосрочный проект) используя столь быстроразвивающюся (читай быстроменяющуюся) технологию, как PHP - заранее обреченный на провал проект
спустя 7 минут [обр] Алексей В. Иванов(0/2861)[досье]
Согласен с Евгений Бондарев aka Eugene Bond[досье]. И дело не только в PHP. 2 года для ИТ очень большой срок.
спустя 50 минут [обр] Андрей Иванов(0/3)[досье]
сообщение промодерировано

Алексей Севрюков[досье]
Ага, спасибо =)

lance10t[досье]

и обмусолим GPL

А чего его мусолить-то?

  1. На GPL свет не сошёлся, есть и другие лицензии. Например, есть существенная разница между Opensource и Free software. И есть две несвязанные друг с другом организации, представляющие один и другой лагерь.
  2. Тебе предлагают использовать библиотеки или фреймворки, а не модифицировать их, а это очень разные вещи, если ты собираешься продавать свой софт.
  3. Прочитай по-русски, чего хотят в GPL, там не всё так страшно.
По поводу ошибок я уже набил себе шишек... и пришел к выводу что должна быть центральная система сбора ошибок.

Системные ошибки это слишком просто =)
Лучше рассмотреть вариант, когда пользователь по шагам делает что-то и у него в середине этого процесса происходит ошибка.

X ... это шелл?..

Нет, Х это Х. Например, сейчас обычно на линуксах стоит Х11 в виде X.org или XFree.

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

Эти аналогии тут не подходят, так как КС очень хорошо подходил для мейнфреймов, а не для рабочих станций.

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

Обработка ошибок. Этого достаточно. Для наколенных приложений она и вовсе не нужна, а вот когда хотя бы уровня professional, а то и enterprise её нет хорошей, то это будет крестом на могиле данного решения.

Это ещё не реализация а только концепция.

Есть несколько уровней абстракции. Пусть будет концепция.
Как я понял предложенную концепцию обработки ошибок, она никак не взаимодействует с пользователем. Такая система ошибок имеет смысл при отладке, а не при работе пользователей.

Как вы думаете почему эта система не широкоизвестна?

Думаю, точно потому же, почему "не широкоизвестна" LIMB.
Наверное, не просто так ты её у себя не указал? А она, тем не менее, лучшая на сегодняшний день...

Забей на GPL.
Приведу простой пример: тебе надо будет использовать шифрование, БД, какие-то другие компоненты. Ты же не будешь сам их писать? Вот потому-то и не парься насчёт того, чтобы всё писать самому. Быстрее будет сделать, если внимательно поискать наличие чего-нить готового (имеются в виду компоненты, раз уж ты систему сам задумал писать).

2 года для ИТ очень большой срок.

И на это советую забить =)
Потому что данную CMS не допишешь. Это не для одного человека работа. Когда начнёшь писать третью больее-менее работающую CMS и у тебя будет команда, ты её напишешь =) А пока тебе надо набирать опыт, вот и набирай его.

спустя 7 минут [обр] Евгений Бондарев aka Eugene Bond(3/1600)[досье]
Алексей В. Иванов[досье], ну для устоявшихся технологий (типа Delphi, C++, Python, возможно .NET) - 1,5 года вполне приемлемо..
Хотя сложно представить себе такой проект..
спустя 4 минуты [обр] Алексей Севрюков(2/1280)[досье]

lance10t[досье] Поддерживаю. Единственно что могу посоветовать - всю логику и структуру продумывать сразу. Но это и так ясно.

Андрей Иванов[досье]

И на это советую забить =)
Потому что данную CMS не допишешь. Это не для одного человека работа. Когда начнёшь писать третью больее-менее работающую CMS и у тебя будет команда, ты её напишешь =) А пока тебе надо набирать опыт, вот и набирай его.

В корне не согласен. Сам сделал и прекрасно применяю аналогичный с нуля и очень долго в одиночку писанный продукт. И этот продукт полностью меня удовлетворяет и продолжает дорабатываться. Кстати, как раз уже около двух лет.

Евгений Бондарев aka Eugene Bond[досье]

думаю, что реализация чего-нибудь долгосрочного (1,5-2 года - это долгосрочный проект) используя столь быстроразвивающюся (читай быстроменяющуюся) технологию, как PHP - заранее обреченный на провал проект

Автор сообщил полный и окончательный срок разработки проекта. Запустится он намного раньше и не сразу в окончательной версии. Так что я с этим не соглашусь.

спустя 1 день 16 часов [обр] lance10t[досье]

Закиров Руслан[досье]

# Только PHP?

я об этом уже думал.. и решил что не буду упираться в PHP, но первая версия будет на PHP ...
Иммено изза того что административыный интрефейс полностью на JS ему будет глубоко безразлично что крутится на сервере.
как я уже говорил ... предпологается что сам код ядра будет на 60-70% меньше чем у аналогичных систем ..
и поэтому его будет не так болезненно переписывать (я знаю что это неизбежно) ...
и переписать ядро(даже на другой язык) и исправить его ошибки будет вполне реально.

как альтернативные языки для ядра рассматривал только JSP и
последнюю .NET'овскую Delphi.

на перле врядли буду писать.

# Читая про интерфейс общения между клиентом и сервером, угадываю аналогии с XML-RPC. Не стоит ли использовать стандартные интерфейсы?

Хорошая идея.
я поискал и нашел библиотечку которая маленькая и делает что нужно в плане отправки. ..
http://www.scottandrew.com/xml-rpc/
Если решусь на использование то просто перепишу эту библиотеку всю до единой стрчки (благо она такая крохотная). =)).
чтобы не парится с лицензированием...
ведь всеравно надо дописать приемник-декодер RPC ... а автор разрешает только использовать и распространять его библиотеку.

а ещё я нашел вот это
Javascript Remote Scripting (JSRS)

с отличной лецензией... там автор открытым текстом пишет что можно применять в коммерческих целях и делать изменения.

но сейчас меня смущает только один вопрос по поводу XML-RPC... как файлы передавать?..
например с POST все очевидно и понятно.
или придется делать 2 "канала связи"?..
один просто для управления а другой для файлов?
это не хорошо..


Андрей Иванов[досье]

  1. Тебе предлагают использовать библиотеки или фреймворки, а не модифицировать их, а это очень разные вещи, если ты собираешься продавать свой софт.

насколько я понимаю Открытое лицензионное соглашение GNU
то можно использовать GPL без последствий если GPL модули не являютя неотьемлимой чатью программы ... Так что со многиоми системными штучками может облом выйти...
а напримет WSYWIG HTML редактор .. будет опционален и система от него не зависит вовсе.. так что я его GPL'овский возьму.

Системные ошибки это слишком просто =)
Лучше рассмотреть вариант, когда пользователь по шагам делает что-то и у него в середине этого процесса происходит ошибка.

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

а по поводу сложных многошаговых действий
..
чтобы рассмотреть этот вариант надо разбить ошибки на 2 категории..
1 ошибки программы
2 логические ошибки алгаритма.

  1. при ошбках программы ошибка может быть исправлена только програмером.

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

  1. логические ошибки.

например.

  1. 2 редактора одновеменно полезли редактировать одно и тоже.
  2. ктото удалил то что сейчас редактируется
  3. ктото физически не может(не хочет) закончить многоступенчатый процесс (регистрация, заказ... итп )
  4. ктото начал процесс основываясь на одних данных а данные в это время изменились.

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

как конкретно с этим бороться я не знаю но есть идеи.

  1. самое распрастранненое

установка блокировок. и перед каждым действием смотреть не заблокированно ли?.

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

2 . идея которая мне больше нравится но она ещё не обдумана.

идея в глобальном версионинге всего сайта.
версионинге которые позоволит вобще возврщать сайт в любое "прошлое".

вот представте что все команды из админки записываются в журнал.
кто ктогда и что сделал..абсолютно ВСЕ.
и помимо этого переодически ну например каждые 1000 команд будет происходить дамп сайта.
при этом можно будет например "проигрывать" эти журналы как сценарии ..
и например дать комманду ... откатить сайт на предыдуший дамп .. и выполнить все команды..
за исключением команд васи пупкина за последние 10 минут.
...
эатем внести поправку
...
и выполнить все команды..
васи пупкина за последние 10 минут.

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

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

спустя 5 часов [обр] Andrey Nedbalski(1/30)[досье]

lance10t[досье]

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

Эта проблема очень просто решается выбором БД, которая поддерживает транзакции. Все запросы изменений делать в одной транзакции и выполнять commit только если все запросы прошли удачно.

спустя 32 минуты [обр] Евгений Бондарев aka Eugene Bond(3/1600)[досье]
но сейчас меня смущает только один вопрос по поводу XML-RPC... как файлы передавать?..

в base64

у XMLRPC есть специальный тип данных, который так и называется

спустя 20 минут [обр] Закиров Руслан(0/341)[досье]
Andrey Nedbalski[досье] Не решается :/ Ибо при работе с вебой в стандартном режиме, вы не можете заблокировать записи, когда пользователь взял их и возможно будет редактировать, так как не известно будут ли от него еще запросы вообще.
Итого, когда пришел запрос с обновлением, необходимо проверить не изменились данные со времени их получения, а только потом обновлять и одной транзакцией.
спустя 6 часов [обр] lance10t[досье]

Евгений Бондарев aka Eugene Bond[досье]

в base64
у XMLRPC есть специальный тип данных, который так и называется

вопрос надо рассматривать в контексте.. я же говорю про JS клиента котрый в браузере работает.
как из него достучаться до файла чтобы взять сдержимое и пропустить через base64 ? ...

спустя 15 минут [обр] Алексей В. Иванов(0/2861)[досье]
я же говорю про JS клиента котрый в браузере работает.
как из него достучаться до файла чтобы взять сдержимое
Никто Вам файлы не даст с машины пользователя читать.
Разве что славный этим IE ;)
http://xpoint.ru/forums/programming/javascript/misc/thread/28689.xhtml
спустя 18 минут [обр] Евгений Бондарев aka Eugene Bond(3/1600)[досье]

пользователь добровольно может разрешить выполнение небезопасных WindowsScripts и ActiveX

на WS можно и до файлов достучаться и в base64 покодировать чего надо

спустя 5 часов [обр] lance10t[досье]

Евгений Бондарев aka Eugene Bond[досье]

WindowsScripts и ActiveX

те кроссбраузерности не будет?.. админка привязывается только к IE?

спустя 4 часа 56 минут [обр] lance10t[досье]
вот ... проаплоадил заготовку на которой я отрабатываю способы создания JS клиента.
код матом не кройте пожалуста..
это просто для тестирования способов работы.и поэтому гряэи много.
http://apps.webtrox.com/ryo-ohki/
спустя 4 часа 45 минут [обр] Евгений Бондарев aka Eugene Bond(3/1600)[досье]
lance10t[досье]
да. привязывается.. вроде как FireFox тоже умеет, но не увере
спустя 5 часов [обр] lance10t[досье]
Евгений Бондарев aka Eugene Bond[досье]
firefox умеет но надо предварительно поставить специальный плагин.
а вот насчет привязывания..
хм...даже и не знаю.
боюсь что не получится... потому что в связи с постоянными проблемам с ИЕ народ активно переходит на FF .. и меня все больше и больше просят адаптировать скрипты для FF.
а также один из первых вопросов что я получаю от IT людей говоря что
- "клиент работает на JS"
- "а в каких браузерах это работает?"
кроссбраузерность зто всетаки важно.
спустя 3 часа 5 минут [обр] Андрей Иванов(0/3)[досье]
кроссбраузерность зто всетаки важно.
Смотря для чего.
Для публичной системы да. Для внутрикорпоративной можно пожертвовать ею в угоду скорости разработки.
Но у нас такой проблемы нет, потому что наш верстальщик знает JS и без всяких замедлений разработки пишет кроссбраузерный JS. Но могут возникнуть другие, не связанные с JS вопросы кроссбраузерности, которые тоже решаются, но не так быстро и просто, как JS.
спустя 30 минут [обр] lance10t[досье]

Андрей Иванов[досье]

пишет кроссбраузерный JS.

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

я думаю что всетаки буду писать на xml-rpc и проблему файлов придется решать
"хаком" ... один хрен xml-rpc запрос идет через POST и к этому посту и приаттачу файл.
а в самом запросе будет указано откуда брать контент файла... и хак будет исправлять xml уже на сервере. приводя его в нормальный вид.
и логика системы связи будет подразумевать что файлы должны быть в base64.

спустя 1 час 53 минуты [обр] lance10t[досье]

Толькочто меня посетила мысль!.
а все от того что сидел и ковырялся с XML-RPC.
подумалось следующее.
"а вот нафига вобще делать эту админку в браузере?"
может действительно ну её нафиг!?..
написать админку в Delphi будет в 20 раз проще.
и пускай она с сервером по xml-rpc общается напрямую без всяких JS->XMP-RPC proxy.
админку всеравно положенно использовать ограниченному кругу людей..
вот пусть они и скачают себе exe.!

читающие! пожалуйста прокомментируйте это идею.
может я просто не вижу какихто "подводных камней"?.. в такой системе?..

спустя 1 день 4 часа [обр] lance10t[досье]

 итак .
я решил провести "разведку боем"
установил Делфи 2005 и попробовал найти для него компоненты xml-rpc
нашелся .net компонент с хорошей лицензией.
но сам Делфи был какото медлительный и странный.. потом я нашел статью с критикой и о том что делфи 2005 сырой и что борланд поспешил.

тога я нашел компоненты для Делфи 7 (тоже с хорошей лицензией)
и всё о радость!..
буквально через 10-15 минут разберательств..
программа с моего компа начала общаться с сервером находящимся в пиндосстане ... да так, какбудто php скрипт ТАМ.. это чать программы ТУТ.

    RpcCaller.EndPoint := '/ryo-ohki/xmlrpctest.php';
    RpcCaller.HostName := 'apps.webtrox.com';
    RpcCaller.HostPort := 80;

    RpcFunction := TRpcFunction.Create;
    RpcFunction.ObjectMethod := 'cycle';
    RpcFunction.AddItem('egg');

    RpcResult := RpcCaller.Execute(RpcFunction);
    if RpcResult.IsError then
      ShowMessageFmt('Error: (%d) %s', [RpcResult.ErrorCode,
          RpcResult.ErrorMsg])
    else
      ShowMessage('Success: ' + RpcResult.AsString);
  finally
    RpcCaller.Free;
  end;

вот как все оказалось просто!
ну чтож попробую сделать так называемый Smart Client
 
который будет ... просто вместо браузера рисовать соответствующие кнопочки и дерева... и поля ввода.. основываясь на данных выцепленных с сервера.

спустя 5 часов [обр] lance10t[досье]

работая с делфи я ук сожелению обаружил что ддаже простенькое приложение ...
занимает 500К или около того... что было довольно странно
ведь там ещё ничего нет а уже такой размер...
и всебы нечего!.. но ведь эту админку должны будут скачивать из сети.. и размер при этом очень важен.
я стал изучать способы уменьшить размер.
и нашел очень интересный проект KOL
http://bonanzas.rinet.ru/r_docs.htm

не вдаваясь в подробности лишь сообщю чего удалось добиться используя KOL+MCK
получил маленький exe которому потом отрезал шапку спомошью StripReloc.exe
и потом сжел UPXом
в итоге получил независимую от всяких сторонних длл прогу с поддержкой XML-RPC и визуальными компонентами!.
которая знимает всего 110 кило.

спустя 1 день 3 часа [обр] lance10t[досье]

ЯДРО

итак
у сформировавшихся ядер самая большая проблема это их
усовершенствование.
и чем больше становится ядро тем труднее там чтото изменить.
изменить както принципиально.

помимо этого разрабатывая ядро водиночку нечего даже и мечтать о том чтобы "сеть и написать" ... совершенно очевидно что процесс растянется на месяцы.

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

ядро с самого начала должо быть посорено так чтобы в далеком будущем моглобы в себя принять без какихбыто переделок.
любые сложности и усовершенствования.

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

  1. многосайтовость.

(это типа один и тотже скрипт но на него заведены разные домены и выдает он разные сайты ессесно.)

  1. многоязычность

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

  1. темплейты

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

  1. модули сайта.

(совмесный вызов одного или нескольких модулей в зависимости от ветви сайта... тоже гибкий как и в пердыдущих примерах)

  1. полный аудит деятельности администрации

(об этом я уже говорил)

  1. система конторля действий

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

  1. аутентификация юзеров.

(разными спсобами)

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

  1. тестовый режим работы.

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

  1. контороль сессий .. и сам механизм сесий.

(кто что делает, делал,и где смотрит.... с возможностью пнуть человека =)

  1. SSL странички

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

  1. версионинг!.. ну кудаж без него?.. =)
  1. Drag-N-Drop интерфейс...

(О ДА!... делфи выступет во всей красе...
интерфейс админки будет несравнимо лучше и удобнее чем любая страничка!..
куда уж тягаться DHTML супротив VCL? ... =). )

  1. обязательно должны быть красивые урлы...

только! только! только! правильный урлы!!!...
никаких "\?id=123&from=1&to=100&func=view"
такие урлы только в помойку!...
должно быть так и не иначе...
/section-name/items-listing-1-to-100.html
или
/guestbook/page_3.html

  1. должен быть WYSIWYG редактор...

ну этотоже теперь не проблема.. делфи рулит.

  1. система отката действий.
  1. группы юзеров с уровнями доступа юзеров.

(все должно быть редактируемое...ничего прошитого намертво.! )

  1. контороль сопутствующих файлов.

(недолжно быть бесхозных JPG, PDF , ... и прочей медии.. если файл есть на жеском диске ... это значит что CMS знает какому документу принадлежит этот файл.... иначе будет хламовник!. )

  1. вывод контента по расписанию

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

20 возможность онлайн администрирования.
(несмотря на клиента-exe всеравно можно будет вносить исправления прямо онлайн. если хозяин сайта увидел опечатку в контенте.то он обязательно сможет войти в администратиывный режим прямо в браузере... ну проще говоря будет типа WIKI(с возможностью отката по версиям.. а то вдруг он нечайно запорит))

  1. "мусорная корзина" ...

ну вобщем .. чтобы ничто не проподало безвозвратно...
я думаю система версионинга прекрасно выполнит эту функцию.

  1. статистика полюбому должна быть встроена.
  1. когданибуть в свободное время надо будет прикрутить RSS
  1. CMS должна быть расчитана на применение любых кодировок.

(ну ту главый запор с UTF и не UTF )

  1. маштабируемость

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

  1. ссылки на контент

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

  1. расширяемость свойст

(очень интересная тема!... например она охватывает такие проблемы как свойства пользователей.. нунапример их данные... бывет что надо только логин и пароль с емайлом .. а иногда надо держать кучу полей.. с данными на каждого пользователя...
и так со многими вещами.. напримр статьи.. на одном сайте нужно хранить свединия кто автор.. а на другом надо хранить дату публикаци....
всех вареантов не учтешь... а создавать огромные мнгополевые таблицы- не выход...
НО ЕСТЬ ОЧЕНЬ КРАСИВОЕ И МОЩНОЕ РЕШЕНИЕ..
я ещё расскажу про то как "убить" проблему расширяемых свойст на корню. )

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

29 проблемы распределения нагрузки на разные БД и на разные WEB серверы
(в этой версии CMS я не буду касаться этих проблем.)

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


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

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

вот например.. эти проблемы по своей сути однотипны..
и я нашел общий универсальный механизм для их решения.!.

  1. многосайтовость.
  2. многоязычность
  3. темплейты*
  4. модули сайта.

*(это система выбора загрузки темплетов, а не сам механизм формирования HTML ... про формирование HTML ещё будет повествование )

обратите внимание ... я пишу именно "нашел" а не "придумал" !..

потом что этот чудесный механизм.. он бы уже давно сделан и отработан...
ГДЕ?... =))),. кто скажет ... ?
кто уже догадался?..

я устал писать и пойду спать...
завтра или после завта я напишу "где".
если ктонибуть не поленится написать правильный ответ. =)..

продолжение следует...

спустя 23 минуты [обр] Андрей Иванов(0/3)[досье]

Маленькая ложка дёгтя:
Drag&Drop можно реализовать и в DHTML.

ядро с самого начала должо быть посорено так чтобы в далеком будущем моглобы в себя принять без какихбыто переделок.
любые сложности и усовершенствования.

Нерационально. Скорее всего, застрянешь, пока будешь писать это ядро.
Советую определиться с функционалом ядра, а то непонятно, где "навесок" на ядро, а где само ядро. Например, шаблоны прошиты в ядро? Если да, то как быть с обащанной бесконечной расширяемостью?

спустя 8 часов [обр] lance10t[досье]

Андрей Иванов[досье]

Drag&Drop можно реализовать и в DHTML

да знаю уж... даже в той заготовке на JS что я тут показывал там уже был Drag&Drop
только сравнивать exe против dhtml всеравно бесполезно - разные весовые категории.

Скорее всего, застрянешь, пока будешь писать это ядро.

хе хе хе... =).. ядро уже написано!...
и код ядра помещаетя на один экран..
потому что ядро не знанимаетвся вобще ничем ктроме вызова плагинов и сопутствующих функций.
конкретнее об этом напишу в следующий раз.

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

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

спустя 1 день 17 часов [обр] SHillA(0/-1)[досье]
ну ... На то чтобы реализовать все что планирую...
полтора - 2 года..
а запустить что-то работающее конечно.. раньше.

Я так понял, вы один разрабатываете этот проект? Причем в свободное от основной работы время?
Если так, то, IMHO, не стоит затевать проект на столь долгий период времени. Причин для этого много:

  1. энтузиазм постепенно стремится к нулю, когда нет конкретных результатов,
  2. за это время появятся новые технологии, новые версии ПО, перейти же на них в процессе разработки довольно сложно
  3. еще сотня причин, почему не стоит разрабатывать ПО со столь долгим периодом разработки, НЕ ИМЕЯ на то очень веских причин.

Я бы посоветовал ориентироваться на период 6-12 месяцев, это для первого stable(возможно даже production)-релиза.

Посему из всего список будет такой:

  1. многосайтовость.
  2. многоязычность
  3. темплейты
  4. модули сайта.
  5. полный аудит деятельности администрации
  6. система конторля действий
  7. аутентификация юзеров.
  8. система безопаснсти
  9. тестовый режим работы.
  1. контороль сессий .. и сам механизм сесий.
  2. SSL странички
  3. версионинг!.. ну кудаж без него?.. =)

x 13. Drag-N-Drop интерфейс...

  1. обязательно должны быть красивые урлы...
  2. должен быть WYSIWYG редактор...

x 16. система отката действий.

  1. группы юзеров с уровнями доступа юзеров.

x 18. контороль сопутствующих файлов.
x 19. вывод контента по расписанию

  1. возможность онлайн администрирования.

x 21. "мусорная корзина" ...

  1. статистика полюбому должна быть встроена.

x 23. когданибуть в свободное время надо будет прикрутить RSS

  1. CMS должна быть расчитана на применение любых кодировок.
  2. маштабируемость
  3. ссылки на контент
  4. расширяемость свойст
  5. улучшенное кеширование(помимо простого)
  6. проблемы распределения нагрузки на разные БД и на разные WEB серверы

Значком х помечено то, что от чего стоит отказаться(пока).
Так из всех фич надо выделить основные(базовые) - те, что влияют на архитектуру ядра, остальное разделить на несколько очередей - в порядке реализции, например WYSIWYG в первой очереди, статистика во второй и т.д.

Еще не мешало бы сделать несколько тестовых прототипов - т.к. неизвестно, какая реализация будет лучше.

ООП vs. функции
Вам не зря советуют реализовывать проект с помощью ООП, кстати, идеальный выбор для этого - PHP5 на данный момент.
Плюсы ООП по сравнению с функциональным подходом: наследование классов, инкапсуляция данных(очень актуально для PHP, с ее специфическим variable scope).

К месту скажу, что проекты, реализованные без ООП я считаю устаревшими и неконкурентноспособными, а также практически не подлежащими расширениям без серьезных переделок и изменения архитектуры проекта.
Что касается Клиент-Сервера - возможно стоит предусмотреть в ядре эту возможность, но отдельный, не www-клиент стоит поместить где-нибудь во вторую очередь фич.

Все вышесказанное есть IMHO, основанно на личном опыте.

спустя 58 минут [обр] Евгений Бондарев aka Eugene Bond(3/1600)[досье]
Добавьте в список "свой вебсервер", измените язык на Python и получите Zope :-)
спустя 2 часа 32 минуты [обр] SHillA(0/-1)[досье]
Евгений Бондарев aka Eugene Bond[досье] Хорошая шутка :)
спустя 4 дня [обр] lance10t[досье]

SHillA[досье]

  1. энтузиазм постепенно стремится к нулю, когда нет конкретных результатов,
  2. за это время появятся новые технологии, новые версии ПО, перейти же на них в процессе разработки довольно сложно
  3. еще сотня причин, почему не стоит разрабатывать ПО со столь долгим периодом разработки, НЕ ИМЕЯ на то очень веских причин.
  1. это надо для работы а не просто так.
  2. тотльная модульность справится с новыми технологиями
  3. не забывайте этот срок это ПОЛНЫЙ цикл... яже написал что отвожу это время на реализацию всех наворотов которые могут понадобится в работе.

понятия "релизов" не будет как таковых...
проект живет и развивется каждую неделю...
и скоро будет в эксплуатации уже на тех стайтах где раньше применялась статика...
на сайтах их 5 страниц я поставлю этот движок... в том сыром виде в каком он есть ...
без адмники... а просто голое ядро.. и буду вносить изменения вручную.. как и положено на статике.

и этот список ... он ничего не значит кроме списка..
то не план это просто то что будет запланированно...
а реализовано будет тогда когда назреет необходимость.

ООП vs. функции
Вам не зря советуют реализовывать проект с помощью ООП, кстати, идеальный выбор для этого - PHP5 на данный момент.

я не отказываюсь от ООП.. и уже сейчас в ядре есть обьект "модуль" и все модули являются его потомками...
я не против ООП вбще... а против неумесного его применения...
и если чтото можно разумно сделать без ооп - я делаю без ооп.

Что касается Клиент-Сервера - возможно стоит предусмотреть в ядре эту возможность, но отдельный, не www-клиент стоит поместить где-нибудь во вторую очередь фич.

нормальный КС - это будет самый главный способ.. управления. я уже решил.
и WWW-клиент не нужен и пока не планируется вовсе.


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

спустя 26 минут [обр] lance10t[досье]
сообщение промодерировано

я писал ранее

вот например.. эти проблемы по своей сути однотипны..
и я нашел общий универсальный механизм для их решения.!.

  1. многосайтовость.
  2. многоязычность
  3. темплейты*
  4. модули сайта.

*(это система выбора загрузки темплетов, а не сам механизм формирования HTML ... про формирование HTML ещё будет повествование )

обратите внимание ... я пишу именно "нашел" а не "придумал" !..

потом что этот чудесный механизм.. он бы уже давно сделан и отработан...
ГДЕ?... =))),. кто скажет ... ?
кто уже догадался?..

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

вот фрагмент (я полностю передрал синтаксис(да и не только синтаксис) апача)

#####################################################################
## Ryo-Ohki server config file
#####################################################################

## "ServerRoot" Ryo-Ohki server root folder
//ServerRoot /home/web4trox/public_html/test/ryo-ohki

## for Windows
ServerRoot w:/home/ryo-ohki.net/www/
//LogLevel info
ServerAdmin pro@server.com           

ServerName server.com
DocumentRoot /

AddModule mod_io
AddModule mod_modloader
AddModule mod_locations
AddModule array_dump
 
loadModule staticcontent
loadModule staticcontent1
loadModule staticcontent2
loadModule staticcontent3
loadModule staticcontent4

//<VirtualSite server.com>
//ServerAdmin pro@server.com
//ServerName server.com
//DocumentRoot /
//</VirtualSite>

<module mod_modloader>

-loadModule staticcontent2
-loadModule staticcontent
-loadModule staticcontent1


loadModule staticcontent5
loadModule staticcontent6
loadModule staticcontent7


test1 "original config value"
test2 "original config value"
test3 "original config value"

//AllowOverride None
//AllowOverride !ServerAdmin
ServerName server.com

ServerAdmin pro_of_modloader@server.com


ErrorDocument 404 errors__/my404.php

    <Directory "/usr/local/apache/icons">
        Order deny,allow
    </Directory>

</module>

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

  [TemplatesFolder] => templates
    [template] => default
    [LModulesFolder] => lmod
    [loadModule] => Array
        (
            [3] => staticcontent3
            [4] => staticcontent4
            [2] => staticcontent2
            [0] => staticcontent
            [1] => staticcontent1
        )

    [test1] => original root value
    [test2] => original root value
    [module] => Array
        (
            [database] => Array
                (
                    [dbname] => my_ryo-ohki_base
                )

            [mod_modloader] => Array
                (
                    [-loadModule] => Array
                        (
                            [0] => staticcontent2
                            [1] => staticcontent
                            [2] => staticcontent1
                        )

                    [loadModule] => Array
                        (
                            [0] => staticcontent5
                            [1] => staticcontent6
                            [2] => staticcontent7
                        )

                    [test1] => original config value
                    [test2] => original config value
                    [test3] => original config value
                    [ServerName] => server.com
                    [ServerAdmin] => pro_of_modloader@server.com
                    [ErrorDocument] => Array
                        (
                            [404] => errors__/my404.php
                            [405] => /errors__/405.php
                            [403] => /errors__/403.php
                            [500] => /errors__/500.php
                        )

и по мере вызова модулей.. ядро изменяет внутреннюю среду "окружение" в которм выполняется модуль..

вот например ради теста.

я меняю [ServerAdmin] => pro_of_modloader@server.com
и теперь если сучится какаято ошибка...
то сработает обработчик который посылает сообщение но(ВНИМАНИЕ) обработчик сработает в контексте этого модуля...
и письмо будет послано... по измененному адресу.

как вы видете эта система вобще не ставит никаких ограничений что будет изменено СПЕЦИАЛЬНО для этого моуля...

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

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

но помимно этого я добавил возможность отменять .. знаком "-" ...


чего я этим добился???..

ну например.

надо чтобы на сайте был темплейт "temp1"

хорошо.. пишу в корне
"template temp1"

потом комуто понадобится сменить темплейт...
в какойто локации? - пожалуйста!..
<location /my_special_page/thepage >
template temp2
</location>
и все...
скрипт как работал раньше...
так и будет... модуль темплейтов например берет переменную темплейта всегда отсюда.
из $conf['template'] ... и именно в этой локации ему подсунут ПРАВИЛЬНОЕ значение.

вобщем гибкости добился.


шас напишу про .. архитектуру ядра.
(тоже стыбрено(и развито) у апача =)

спустя 22 минуты [обр] lance10t[досье]

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

   $core['boot']=            array();// run at start NO HTML OUTPUT!       
   $core['system']=         array();// run at start NO HTML OUTPUT!       
   $core['automatic']=         array();// automatic module calls PRIMARY HTML OUTPUT HERE!   
   $core['manual']=         array();// manual module calls PRIMARY HTML OUTPUT HERE!   
   $core['disabled']=         array();// disabled modules & methods
   $core['shutdown']=         array();// run at the end of script (NO or limited ) HTML OUTPUT!               

   $core['onModuleStart']['boot']=      array();// multi run before every module
   $core['onModuleStart']['system']=   array();// multi run before every module
   $core['onModuleStart']['automatic']=   array();// multi run before every module
   $core['onModuleStart']['manual']=   array();// multi run before every module
   $core['onModuleStart']['shutdown']=   array();// multi run before every module

   $core['onModuleStop']['boot']=      array();// multi run after every module  
   $core['onModuleStop']['system']=   array();// multi run after every module  
   $core['onModuleStop']['automatic']=   array();// multi run after every module  
   $core['onModuleStop']['manual']=   array();// multi run after every module  
   $core['onModuleStop']['shutdown']=   array();// multi run after every module  

   $core['onNamedModStart']=      array();// run before specified module (multidimentional)
   $core['onNamedModStop']=      array();// run after specified module (multidimentional) 

   $core['onError']=         array();// run on error

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

а моментов масса.

  1. выполнить на какомто из 5-и этапов работы.. от boot и до shutdown
  2. выполнить перед любым модулем... или после любого модуля на выбранном этапе.
  3. выполнить перед или после какогото конкретного названного по имени модуля.
  4. выполнить при ошибке.

вобшем вот такие методы есть у обьекта "модуь"..

function intercept($target,$method) //именованый перехват какогото конкретного модуля
function cover($target,$method)     //именованое прекрытие какогото конкретного модуля 
function intercept_all($method,$ordering='automatic') //общий перехват
function cover_all($method,$ordering='automatic')     //общее прекрытие
function override($target)     //подмена (один модуль полностью подменяет другой)
function execute($method,$ordering='automatic') // запрос на обычный запуск метода.

благадаря этому модули могут лезть куда угодно в любой момент программы устанавливая свои обработчики через переменную $method .
ну и характерной особенностью "перехватов" является то что они могут спомошью возврашенного значения разрешить или запретить выполнение перехватываемого модуля.
и конечно .. на любое из мест может быть добавлено любое количество разных обработчиков.

те например в будущем..
модули из этапа "automatic" будут массово перехватываться как кеширующем модулем, так и модулем безопасности, и модулем темплейтов.
и каждый будет работать независимо и незнать о других модулях-перехватчиках.

спустя 1 день 4 часа [обр] SHillA(0/-1)[досье]
тут я говорил об апаче.
о его подходе к обслуживанию сайтов..
точно такойже подход я решил применить для обслуживания страничек.
Какие были причины брать именно апачевский подход к конфигурированию системы?
Замечу, что именно к конфигурированию, т.к. ту же самую конфигурацию можно представить разными способами, да и вообще это не важно, а важна архитектура ядра, как ядро обрабатывает запросы, API для подключения расширений, вызова функций и т.д., по аналогии с ОС.
Во-вторых чтобы добиться стабильности ядра нужно писать тесты, а это то еще болото..
спустя 10 часов [обр] lance10t[досье]

SHillA[досье]

"Какие были причины брать именно апачевский подход к конфигурированию системы?"

конфигурация.. и принципы её построения сильно влияют на ядро.
это уже влияет на саму логику ядра. поэтому не так уж и много вариантов для передачи.

приемущества следующие.

  1. отсутствие избыточной информации

(как следствие- легкость редактирования)
те не надо хранить гдето много записей что страница1, стстраница2, страница3.
используют темплейт1.

  1. человеческий формат

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

  1. полная гибкость настройки.

(можно давать директивы "на будущее" ... например модуль можно написать с директивой "Cache none", и неважно будет ли кеширование вобще или нет... есть ли модуль кеширования)

  1. отсутствие необходимости заранее продумывать "рычаги управления" и управляющие переменные.

как это в большинестве систем.
при этом ступенчатом наслоении настроек друг на друга.. ненадо писать в коде всякие IF которые будут учитывать всякие щекотливые ситуации.. а просто в файле будет указано.
наприемер.. что "модуль1" ... будучи вызванным изнутри "модуль2" который выполняется в контексте модуля3 .. в локации "/guesbook/" должен использовать параметр а=1 и тд и тп...
все это моджно описать в конфиге несколькими строками а именно вот

<loсation /guesbook/>
 <module "модуль3">
   <module "модуль2">
     <module "модуль1">
     а 1
     </module>
   </module>
 </module>
</location>

удобоно ? помоему да.
да и вобще упроащается логика самих модулей.
"модуль1 " гдето в коде всеголишь использует переменную
$conf['a'] и все.. никаких IF.
если это модуль контента то он будет работать примерно по такому принципу
(упращенная модель которая вытаскивает "преамбулу" к статье помоему должна выглядет так)

$core['mod_io']->setParam('content_part','leading_story');
$core['mod_io']->setParam('name',$conf['ShowContent']);
$core['mod_io']->setParam('lang',$conf['language']);
echo $core['mod_io']->getData();

//mod_io отвечает за ввод и вывод данных.. и например вытаскивает какойто конкретный набор основаваясь на параметрах.. которыее выступают в роли "координат".
если заранее ввести какието данные с определенными параметрами то введя параметры снова можно будет получить эти данные обратно.

  1. апач - система проверенная временем это большой + .

PS про ядро в следующий раз.... (скоро)

спустя 16 часов [обр] SHillA(0/-1)[досье]
  1. апач - система проверенная временем это большой + .

Sendmail тоже система, проверенная временем. Кто-то даже считает синтаксис его конфигурационного удобным и понятным.
Еще есть MS DOS - тоже проверенная временем система ;)

Но! Править cfg файл - это одно, а редактировать через веб-интерфейс - это другое.
И вряд ли конфиг, занимающий несколько десятков экранов можно считать понятным и удобным.
Все зависит от масштабов.
Не стоит с этим запариваться(форматом файла настроек), тем более что гораздо удобней все настройки хранить в БД(за исключением разве что данных аккаунта для соединения с этой БД).

спустя 9 часов [обр] lance10t[досье]

SHillA[досье]
ну стоило только написать один лирический пункт(заметте он последний) так тутже вы меня разметали.. =).
да !.. Sendmail тоже система, проверенная временем.(только результат проверки отрицательный)
Sendmail проверено временем и это + потому что теперь мы знаем что лучше его не использовать.
а .NET не проверено временем и это - =)..
P.S.
DOS - класс!.. хорошая система!

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

ну такой большой конфиг может быть только у большого проекта.. у целого портала.
и изменять его будут редко
также редко как меняется структура портала...
естественно для добавления новости в ленту... или для добавления очередной статьи в категорию конфиг трогать непридется.
ну и конечно кому трудно будут юзать ГУИ.

Не стоит с этим запариваться(форматом файла настроек), тем более что гораздо удобней все настройки хранить в БД(за исключением разве что данных аккаунта для соединения с этой БД).

а все.. уже файл сделан и настройки уже работают как я описал.
а по поводу БД .. удобнее это или нет - спорный вопрос.
но в контексте этой CMS спора не получится потому что постановка задачи такова..
что сайт ДОЛЖЕН работать без БД.. (это для мелких сайтов)

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

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

IDимятипважное_свойство1важное_свойство2весширинадлинавысотацвет...

и порой довольно длинные... так вот ЭТО НЕ ПРАВИЛЬНО
потому что завтра вас попросят добавить 101-е поле в котором будет хранится еще чтото..
и придется лесть в SQL(в скрипте)... и счто самое ужасное.. ужаснее всего на свете придется изменять структуру базы.

поэтому должно быть так.

IDимятипважное_свойство1важное_свойство2ID_опциий

и все.
но должна быть универсальная таблица для хранения любых свойств чего угодно..
и работать она должна примерно так
options_manager->setID($ID_опций);
и потом
можно одной коммандой получить все опции для этого ID ввиде масива
$options_array=options_manager->getAllOptions();

или по выбору(по имени) выгребать любую опицю.
options_manager->getOption('color');
ну а таблица для хранения опций представляет из себя нечто такое

ID_oпцииимятипINTEGERSTRINGARRAYещё какойто тип..

ну типы опций надо заранее прикинуть какие нужны.. но обычно их не больше 4-6...
так вот ID опции это ессесно не уникальный ключ.. =).

...
в чем мастерство?..
мастерство в том чтобы правильно выбрать какие параметры важны для логики программы а какие- барахло.
и правильно разделить все барахло свалить в этот options_manager
а важные параметры пусть будут в таблице.

в чем радость?..
в том что это централизованная система..
в options_manager можно хранить все подряд .. начиная от всякой персональной чуши присущей пользователю, адреса фирм, и вобще каждый модуль может там держать любые опции для любых своих нужд.

спустя 5 часов [обр] Алексей Севрюков(2/1280)[досье]

lance10t[досье]

поэтому должно быть так.
ID имя тип важное_свойство1 важное_свойство2 ID_опциий

А как в таком случае будет выглядеть "ID опций"? И Зачем "ID опций", если есть ID товарной позиции в данном случае. По которому можно связать две таблицы (если у Вас конечно опции хранятся в адекватном виде в другой таблице)

спустя 33 минуты [обр] lance10t[досье]

Алексей Севрюков[досье]
=)..
"ID_опции" он генерируется самим option manager'ом
и он должен быть другим нежели ID товара
потому что смысл этого менеджера в том чтобы создать общепрограммную базу опций...
представте что нет ID_опций
что тогда?!.
вот например там хранятся опции товара с ID 1...
а если вы захотите там хранить ещё и опции юзера с ID 1?.. а опции фирмы с ID 1?.. да малоли что ещё может иметь ID=1? и тогда система накроется медным тазом.

ведь менеджер универсален!.. и применяестя где угодно.
поэтому у него можно сделать чтото типа
$option_ID=$option_manager->newOptions();
или както ещё получать уникальный id
а выглядеть ID_опций может как вам больше нравиится...
ну можно цыфирку поставить... это принципиально?..или не принципиально?..
чесно говоря я и сам не знаю.

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

спустя 1 час 12 минут [обр] Евгений Бондарев aka Eugene Bond(3/1600)[досье]

lance10t[досье]

или както ещё получать уникальный id

поэтому у MSSQL есть специальный GUID.
Кстати, как вариант, ID и может быть какой-нибудь хеш. например по имени_таблицы + количеству_записей_в_таблице + uniqid какой-нибудь

спустя 1 час 18 минут [обр] SHillA(0/-1)[досье]
option manager штука конечно полезная, но не универсальная. Атрибуты, не имеющие сложных связей хранятся на ура, а вот как быть со сложными?
Пример: атрибуты, которые используются для связи с другими таблицами. Как тогда будут выглядеть запросы, использующие эти таблицы?
Еще один маленький вопросик: какой тип поля у атрибута ID_опциий?
спустя 4 часа 38 минут [обр] Кирилл [Kirk] Королев(0/673)[досье]

SHillA[досье]

Пример: атрибуты, которые используются для связи с другими таблицами. Как тогда будут выглядеть запросы, использующие эти таблицы?

Я видел (и немножко дописывал) систему, в которой использовалась обычная структура справочников, в которой, помимо обычных значений, лежали чистые SQL-запросы. Подход спорный, но писал ее человек опытный и неглупый. А главное - она работала.

спустя 14 часов [обр] lance10t[досье]

SHillA[досье]

Пример: атрибуты, которые используются для связи с другими таблицами.

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

"в чем мастерство?..
мастерство в том чтобы правильно выбрать какие параметры важны для логики программы а какие- барахло.
и правильно разделить все барахло свалить в этот options_manager
а важные параметры пусть будут в таблице."

связи с другими таблицами - очевидно важны для логики программы и никак не должны быть в менежджере.

спустя 7 часов [обр] SHillA(0/-1)[досье]

Пример:
Есть некий товар, он имеет атрибуты: страна, город, цвет, тип, рубрики в каталоге.
Все эти атрибуты есть по сути справочники, при этом связь с рубриками - 1:N.
По вашей логике эти атрибуты соответствуют полям в таблице, рубрики - даже целой таблице.
Как же быть, если придется добавить/удалить/изменить еще несколько таких справочников?
ALTER TABLE?
Не гибко.
Одно решение я знаю, может у вас есть интереснее?

P.S. страна и город, кстати, взаимосвязанные(город зависит от страны). Денормализация сделана для удобства и скорости выполнения запросов.

спустя 1 час 50 минут [обр] Андрей Иванов(0/3)[досье]

lance10t[досье]

хе хе хе... =).. ядро уже написано!...
и код ядра помещаетя на один экран..
потому что ядро не знанимаетвся вобще ничем ктроме вызова плагинов и сопутствующих функций.

Это не ядро, а фиг знает что. Где в нём поддержка распределённости, централизация доступа к БД, обработка ошибок и так далее? Я не верю, что всё это поместится на один экран. Даже если это очень большой экран. Сомневаюсь даже, что одни только комментарии ко всему этому добру поместятся на один экран.

Слишком всё простым кажется.
Например, у меня два модуля, оба хотят обработать результаты какого-то третьего модуля. Непременно оба и непременно в самую первую очередь.
Про свойства объектов в БД читай теорию. Слова товарища это хорошо, но неформализованно. Пример со всеми свойствами всех объектов в виде полей одной таблицы для детского сада.

Не советую всё в одну кучу сваливать, потому что за деревьями не увидишь леса. Ты делаешь очень сложную систему, которая сдохнет от лёгкой нагрузки. Смысл? Надеяться на кэширование также не советую. Потому что всё и вся кэшировать замучаешься, лучше правильно организовать структуру. Хранение всех полей всех объектов в одной таблице сгодится для мощного сервера и человек 30 одновременно работающих, дальше вряд ли что-то поможет.

Историческая справка: БД появились, когда нас ещё на свете не было и даже наших родителей ещё наверное не было, а это существенно больше 15 лет, так что товарищ твой нагло врёт.

Да, чуть не забыл =)
Бесплатный совет: подели систему модулей на части. Чтобы одна часть заведовала, например, получением данных, другая их обработкой а третья их форматированием. Разбивать можно разными способами, используй тот, который тебе понятнее или ближе.

спустя 4 часа 56 минут [обр] lance10t[досье]

SHillA[досье]

Есть некий товар, он имеет атрибуты: страна, город, цвет, тип, рубрики в каталоге.
Все эти атрибуты есть по сути справочники, при этом связь с рубриками - 1:N.
По вашей логике эти атрибуты соответствуют полям в таблице, рубрики - даже целой таблице.
Как же быть, если придется добавить/удалить/изменить еще несколько таких справочников?
ALTER TABLE?

признаюсь .. я струдом понимаю ваш вопрос.

если есть товар...с такими свойствами
"имеет атрибуты: страна, город, цвет, тип, рубрики в каталоге. "

  1. вобще товар не знает в какой он рубрике..

это забота самой рубрики знать какие ей пренадлежать товары

  1. тип- видимо важное свойство будет в таблице самого товара.
  2. все остальные.. поля попадают в менеджер опций..

ничуть не расщиряя его структуры.
"страна, город, цвет" - все будут STING.. в виде опций..
но наприемер..
если задача ставится так что очень интенсивно будет выборка по городам..
ну если сама прогрпмма ориентированна на выбирание товаров по городам...
тогда город нельзя в опции записывать..
вобщем все зависит от поставленной задачи.

насчет "не гибко"..
ну я несовсем понимаю что именно не гибко?.. ну понадобится ещё какоето свойство у товара хранить..
придется добавить одну строчку
options_manager->setOption('NewOption',$option_value);
таблица менеджера опций при этом не расширится структурно.. только добавится ещё одна запись.

спустя 2 часа 22 минуты [обр] lance10t[досье]

Андрей Иванов[досье]

Это не ядро, а фиг знает что. Где в нём поддержка распределённости, централизация доступа к БД, обработка ошибок и так далее? Я не верю, что всё это поместится на один экран. Даже если это очень большой экран. Сомневаюсь даже, что одни только комментарии ко всему этому добру поместятся на один экран

"Где в нём поддержка распределённости," распределённости чего?..
"централизация доступа к БД," будет модуль mod_database
"обработка ошибок " будет mod_error
"и так далее?" ... у вас какието странные понятия о ядре..
ядро оно потому и ядро назвается потому что неделимо.
сайт может работать без обработки ошибок?..может!.. заначит обработка ошибок это не часть ядра
по постановке сайт работает без БД.. - работает значит БД это модуль.
[[[
Даже если это очень большой экран. Сомневаюсь даже, что одни только комментарии ко всему этому добру
]]]
хотя да сейчас ядро разраслось на 300 строк.
потому что я ввел поддержку "СМЕЩЕНИЯ КОНТЕКСТА" ... (когда писал про один экран там было только поддержка перехватов)...а смещение контекста.. это когда вызываешь например
$core['mod_database']->setQuery($sql);
так вот на время выполнения метрода setQuery от постороннего обьекта mod_database, среда меняется так как указанно в конфиге для данного конкретного случая.. поэтому теперь все уже не один экран.
а перехваты..
ну они делаются 3-мя функциями.. если хотите я приведу листинг той старой верссии которая делает перехваты когда она была ещё маленькая.. (я кстати пищу в FAR'е и экран у меня 62 строки)
и эти 3 функции помещаются на этот один экран.

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

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

1-й модуль прекрывальшик.
в своем конструкторе заявляет
$this->cover('имя_цели','1свой_метод_прекрытия');

2-й модуль прекрывальшик.
в своем конструкторе заявляет
$this->cover('имя_цели','2свой_метод_прекрытия');

Этот "свой_метод_прекрытия" в качестве параметра получает весь output "цели"..
и может делать с ним что хочет.
если этот модуль ничего не return то и ничего не случится.. а если return то этот output "цели" будет замнен на return.

но они логичкски не могут работать одновременно. потому что будет непонятно кто из них прав.. и чьи изменения надо принять а чьи отбросить...как не актуальные.
если какойто модуль не вносит изменения в output то его надо просто поставить раньше всех.

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


я ещё не закончил отвечать на ваше сообщение...
просто шас времени нет.. потом продолжу.

спустя 6 часов [обр] lance10t[досье]

Андрей Иванов[досье]

Слова товарища это хорошо, но неформализованно. Пример со всеми свойствами всех объектов в виде полей одной таблицы для детского сада.

Не советую всё в одну кучу сваливать, потому что за деревьями не увидишь леса. Ты делаешь очень сложную систему, которая сдохнет от лёгкой нагрузки. Смысл? Надеяться на кэширование также не советую. Потому что всё и вся кэшировать замучаешься, лучше правильно организовать структуру. Хранение всех полей всех объектов в одной таблице сгодится для мощного сервера и человек 30 одновременно работающих, дальше вряд ли что-то поможет.

"Хранение всех полей всех объектов "
у меня складывается ощущение что вы не читаете что я пишу...
я же писал что надо туда отправлять только то что не влияет на логику программы..
всякую ерунду!..
уточняю.
я не вкоем случае не собираюсь и не пизываю коглибо использовать это менеджер опций для хранения всех полей всех объектов ... цитирую опять сам себя.

мастерство в том чтобы правильно выбрать какие параметры важны для логики программы а какие- барахло.
и правильно разделить все барахло свалить в этот options_manager
а важные параметры пусть будут в таблице.

конечно любую хорошую идею можно довести до абсурда.
и "Хранение всех полей всех объектов" - абсурд.

спустя 9 часов [обр] Андрей Иванов(0/3)[досье]

lance10t[досье]

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

Именно об этом я и говорил. И мне интересно, как будет решаться такой вопрос. Ведь система-то универсальная пишется. И всё должно быть круто - подключил модуль и радуешься... А тут получается, я писал-писал модуль, а он будет не первый, а третий или 12 в очереди на данные после какого-нибудь модуля... А ещё смешнее получится, если мне будет требоваться для работы какой-нить модуль, которого не будет в системе =)

и "Хранение всех полей всех объектов" - абсурд.

Отнюдь =) Я другого быстрого и удобного способа не знаю для универсального хранилища.

ядро оно потому и ядро назвается потому что неделимо.

Ладно, подождём ещё пару версий и будем дальше разговаривать =)

спустя 4 часа 33 минуты [обр] lance10t[досье]

Андрей Иванов[досье]
вначале вы пишете

Не советую всё в одну кучу сваливать, потому что за деревьями не увидишь леса. Ты делаешь очень сложную систему, которая сдохнет от лёгкой нагрузки.
...
Хранение всех полей всех объектов в одной таблице сгодится для мощного сервера и человек 30 одновременно работающих, дальше вряд ли что-то поможет.

а потом

Отнюдь =) Я другого быстрого и удобного способа не знаю для универсального хранилища.

ну и как вас понимать?.
просто эта дискусия напоминает мне следующий разговор..

я-"вот есть отвертка, отвертка - хороший инструмент"
вы-"отвертка - плохой инструмент, ей трудно забивать гвозди и открывать консервные банки"
я-"отвертку надо применять умело в нужных ситуациях, забивать гвозди отверткой - абсурд"
вы-"Отнюдь =) Я другого быстрого и удобного способа не знаю для забивания гвоздей."

=).

Ведь система-то универсальная пишется. И всё должно быть круто - подключил модуль и радуешься... А тут получается, я писал-писал модуль, а он будет не первый, а третий или 12 в очереди на данные после какого-нибудь модуля... А ещё смешнее получится, если мне будет требоваться для работы какой-нить модуль, которого не будет в системе =)

это логическая проблема...
без уточняющих данных её нельзя решить...
можно конечно запустить 2 модуля одноврменно..
тогда получится раздвоение алгаритма..
и на выходе обоих алгаритмов будут ДВЕ разные странички..
и какую из них показывать пользователю(обе?)?..
когда вы по человеческим понятиям скажете какая из них должна быть показана
я скаджу как это будет реализовано в компьютере...
а если вы как человек незнаете какая из 2-х копий верная то как об этом может знать компьютер???.

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

А ещё смешнее получится, если мне будет требоваться для работы какой-нить модуль, которого не будет в системе =)

а почмеу это вдруг его не будет в системе?.. вы же не станите в своем модуле обращаться к заведомо несушествующему в системе модулю?...или станете?..
будет также как с DLL ... вот что будет с программой если она обратится к функции из несуществующей dll ? результат известен.

вобщем.. сделаю так.. (это опросто при нынешнем ядре, и архитектуре)
в конфиге указывается так

dynamicMod имя_модуля1
dynamicMod имя_модуля2
dynamicMod имя_модуля3
dynamicMod имя_модуля4

все модули будут загружаться только в том случае если откуданибуть произайдет вызов
типа $core['имя_модуля4']->какойто_метод();
так вот перд выполнением этого метода будет загружен php файл с классом и будет создан новый экземпляр который и будет выполнять метод.
естественнго при повторном вызове никаких новых загрузок.

спустя 2 часа 43 минуты [обр] Александр aka Efreeti(3/111)[досье]
lance10t[досье]
Я бы на Вашем месте прекратил дискуссию с Андрей Иванов[досье], потому как мне кажется (да и вам, как я понял, тоже), Вы разговариваете на разных языках. Вы бы продолжили писать по намеченному плану. Имхо было бы интереснее. Хотя дискуссия тоже важна (в конце концов, именно для этого вы здесь и пишите), но так как вы не всё ещё описали, может возникать непонимание.
спустя 2 часа 23 минуты [обр] Pavel Ivanov[досье]

lance10t[досье] У вас идея интересная и хорошо продуманая.Как програмист, меня ето нравится.Всё очень логично и четко.Но если я правилно понял,вы хотели сделать очень удобную пользователскую ситему.Вы думаете что user будет в состоянии конфигурировать болшого сайта? Мне кажеться что вся работа сместилась на client sidе и в сложности напоминает Dreamweaver. Потом, кто будет модули писать? Понадобиться вербовка програмистов и так далее.Не маленкая задачка. Все таки, решение технически изящное.Желаю успеха.


Прошу прощения для плохого руского.Я собстевено из Болгарии и совсем не полиглота :)

спустя 3 часа 1 минуту [обр] lance10t[досье]

Андрей Иванов[досье]

Ладно, подождём ещё пару версий и будем дальше разговаривать =)

хех!,.. сегодня я полностью переписал ядро!..
итак считаем что версия 0.02 =)
и добавил динамически подгружаемые модули.
я думаю не лишним будет тут привести и код ядра..
(за исключением некоторых сопутствующих функций)
http://apps.webtrox.com/partial_listing.txt
вот и все .. полтора экрана!
этот кусок не содержит листинга важной функции shift_config ... которая выполняет сдвиг контекста а остальное все как я писал выше...
перехываты, прекрытие, буферизация работы модулей...

Александр aka Efreeti[досье]
да .. я продолжу подробнее.

Pavel Ivanov[досье]

Вы думаете что user будет в состоянии конфигурировать болшого сайта?
Мне кажеться что вся работа сместилась на client sidе и в сложности напоминает Dreamweaver.

вы просто прочитали мои мысли =)..
да клиент будет похож на Dreamweaver и Explorer одновременно в котором сильно развито drag&drop.
на client sidе смещается ввесь интерфейс.. но сервер будет напрямую управлять этим интерфейсом,
вплоть до того что будет указывать какие панели создать, какими кнопачками их наполнить,будет указывать как и чем наполнить дерево обьектов.
те клинет будет выполнять роль такого умного браузера написанного специально для этого сервера.

Потом, кто будет модули писать?

я буду писать по мере необходимости... как понадобится чтонибть так и напишу. всеравно мне приходится много писать.. так буду с пользой для своей системы а не работать "впустую" переписывая open source

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

спустя 13 часов [обр] Pavel Ivanov[досье]
lance10t[досье]
Ну допустим что вы все сделал. Как вы убедите меня в том что ваш софт лучше Мамба? Прошу заметить что я уже согласен с предимсвами в настойке, скорости и внутренной четкости. Но это для меня не основное. Я прежде всего хочу иметь болшого выбора модулей и гарантированой поддержкой. Мамбо это имеет, да и free. Заплатит за это неким неудобством в настройке кажеться нормально. Технически говоря, ваша идея намного лучше Мамба но по моему нуждаеться некоторой гибкости в лицензировании.
спустя 3 дня [обр] Дмитрий Донцов+++(0/68)[досье]
lance10t[досье]
Да, если можно, то продолжайте излагать согласно вашему плану...
Очень интересно...
Тем более что я тоже задумывался о неком клиенте (XUL+XPCOM), правда это только для платформы Мозилла. А вы похоже на большее замахиваетесь...
спустя 5 часов [обр] lance10t[досье]

конечно я продолжу...
просто шас важные дела происходят и я выкраиваю время на разработку..
а на форум не всегда остается.

именно сейчас я делаю mod_location
который развивает идею апачевых директорий...
модуль просто меняет среду... основываясь на URL который получает/

настройки работают следующим образом

<location /test/docs/>


-loadModule staticcontent4

          <location /mod/>


          -loadModule staticcontent1
          -loadModule staticcontent2


          </location>


          <location /lmod/>

           loadModule staticcontent3
           loadModule staticcontent4

          </location>

   <location /??-??-??.(html|htm)>

           loadModule staticcontent3222
           loadModule staticcontent43333

         </location>
             
</location>

тут все очевидно.
есть настройки на локацию /test/docs/
и на вложенные папки. /mod/ и /lmod/

но если будет запрос например /test/docs/NOT_ExIsts.html
то будет сгенерирована ошибка.
это упращенно...

насамом деле может быть сложнее

  1. настройки сумируются..

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

<location /test/docs/mod/>

          -loadModule staticcontent1
          -loadModule staticcontent2

</location>
  1. можно использовать регулярные выражения.

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

<location test/*/\d{0,}/????.html>
loadModule staticcontent222   

</location>

надеюсь всем очевидно как сработет этот регексп.(по правде говоря я переделываю регекспы налету... именно поэтому можно написать "+" вместо ".+" ) (+ написал вместо звездочки.. потому што звездачка делает жырный шрифт )

этот регексп сработает на
test/ANYTHING_BUT_SLASH/12345666666/qw12.html

и еще ... это большая разница написать так <location /test/*> или так.. <location /test/*/>
первый пример.. он сработает как и ожидается.. он повлияет на все что начинается с /test/

а второй.
он касается только /test/docs/ , /test/dffffocs/ , /test/12345docs.htm
но не повлияет на /test/docs/folder/, /test/docs/folder.html

спустя 2 дня [обр] lance10t[досье]

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

раньше я работал с CVS ... и признаюсь что это Г ещё то.
начиная от настройки и установки CVS сервера и заканчивая клиентами.
ну сам CVS как вы знаетет командное приложение...
это вызвало у меня сразу страшную антипатию...
ведть если пользоваться каждый день то должно быть удобно.
те я готов потыкать команды в консоли.. но когда это нужно.. чтобы настроить, запустить...
но постоянно - увольте.
поэтому я попробовал 3 GUI клиента к CVS ... один какйто на яве.. и два win32
все неудобные...
и ничего удевительного... что сейчас уже другие требования к юзабилити...
ведь уже почти 2005 год... =)
CVS - безнадежно устарел...
я стал искать альтернативы.
были каието 2 проекта.. я уже и забыл как они называются... которые пытались сделать свое .
но все неудачно.
но удача улыбнулсь и я нашел
сервер
http://subversion.tigris.org/
и клиент
http://tortoisesvn.tigris.org/

Разработчики! .. я обращаюсь ко всем кто будет работать в команде или использует CVS
обязательно поробуйте или хотябы почитайте о subversion
CVS - на помойку.

вобщем дело обстоит так . что мой домашний комп 85% времени подключен к сети и имеет хороший канал связи.(а скоро будет гарантированнно все 100% времени)
и я поставил SVN сервер на нем.
без особых кстати хлопот.
и теперь мы сможем нормально работать...

кстати кому интересна музыка на скачку
можете заглянуть
http://lance10t.dyndns.org:2229/music/

спустя 9 часов [обр] Алексей В. Иванов(0/2861)[досье]
Subversion пока сырой и глючный. Я бы не стал призывать к массовому использованию.
спустя 2 дня 2 часа [обр] lance10t[досье]

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

скоро я напишу что именно и как было испорчено в рекурсии ... и как стало переделано.

а пока для затравки немного хорошей теории.

Программирование рекурсивных функций и Нагорная проповедь

Специфика рекурсивных алгоритмов состоит в том, что они полностью исключают “исторический” подход к проектированию программы. Попытки логически проследить последовательность рекурсивных вызовов заранее обречены на провал. Их можно прокомментировать примерно такой фразой: “Функция F выполняет … и вызывает F, которая выполняет … и вызывает F…”. Ясно, что для логического анализа программы в этом мало пользы. В психиатрии известны аналогичные случаи: “Я хочу Вам написать, что я хочу Вам написать, что я хочу Вам написать…”. Тем не менее, эта фраза смутно напоминает нам попытки “исторического” анализа циклических программ. Там для того, чтобы понять, что делает цикл, предлагалось предложить некоторый инвариант (условие, соотношение) , сохраняемое шагом цикла. Наличие такого инварианта позволяет “не заглядывать вперед” к последующим и “не оборачиваться назад” к предыдущим шагам цикла, ибо на них делается то же самое.

Аналогичная ситуация имеет место в рекурсии. Только она усугубляется тем, что при ветвящейся рекурсии “исторический” подход вообще неприменим, поскольку: “Функция F выполняет … и вызывает F второй раз, которая выполняет … и вызывает F в третий раз … а потом, когда опять вернется в первый вызов, вызовет F еще раз во второй раз…”.

Отсюда первая заповедь: алгоритм должен разрабатываться, не выходя за рамки текущего рекурсивного вызова. Для нее есть общеизвестная аналогия. В Нагорной проповеди Нового Завета Иисус высказал одну из заповедей блаженства : Итак, не заботьтесь о завтрашнем дне, ибо завтрашний сам будет заботиться о своем: довольно для каждого дня своей заботы (Мф. 6, 34). Сама по себе эта фраза, вырванная из контекста и принятая без должного размышления, сильно смахивает на обыкновенный “пофигизм”: живите сегодняшним днем, а после нас - хоть потоп. На самом же деле смысл ее, как руководства к действию, прямо противоположен: если хочешь в жизни достичь благодати, будь достоин сегодняшнего для, не объясняй своих слабостей прошлым, не уповай на исправление сегодняшних ошибок в будущем. Сосредоточься на сегодняшнем дне, и тогда цель в будущем будет достигнута сама собой. То же самое - и в проектировании рекурсивной функции : следует сосредоточить внимание на текущем шаге рекурсии, не заботясь о том, когда она была вызвана и что будет делать следующий ее шаг: на самом деле они будут делать то же самое, что и текущий (хотя и не написанный). Если “сегодняшний” вызов функции корректен и все ее действия приводят к такому же корректному вызову ее “завтра”, то цель рано или поздно будет достигнута.

спустя 11 дней [обр] lance10t[досье]

вот я и вернулся..
вобщем дело с рекурсией было в следующем.
функция поучает 3 параметра первые 2 операнды и опреация..
и получалось что операнды бывают 4х типов и операция 3-х видов..
вобщем по комбинаторике получалось куча целая вариантов и каждый вариант должен быть обработан посвоему....
и я начал тупо писать
кучу ветвящихся if ... и логка развервлений была такова..
:-/
блин чем писать я лучше нарисую.. это проще и нагляднее...

http://img115.exs.cx/img115/7375/algold7tu.gif

вобщем как вы увидили при добавлении новой операции - наступает крах. темболее что в некоторых ветвях я "заботился о завтрашнем дне"

после переписывания стало так..

http://img80.exs.cx/img80/8171/algnew6zr.gif

и ветвление алгаритма не становится больше второго уровня...
и уже через несколько часов работы с движком я отловил всякие забытые ситуации...
и получилось что там описаны не потенциально ВСЕ ситуации а только те что реально случаются на практике.
 теперь это более-менее расширяемая схема...

спустя 20 минут [обр] lance10t[досье]

заметка об убиении 3-х зайцев одним выстрелом

итак совершенно неожиданно я обнаружил некоторые совйства у модуля который выбирает настройки в зависимости от урла...

оказалось что этот модуль выполняет 3 функций..

он как я уже рассказывал
работает по регулярным выражениям... типа

<location thumbnail/(1?\d{1,2})x(1?\d{1,2})/(\w{1,100}(.jpg|.jpeg))>

-LoadModule
LoadModule thumbnail

</location>

эта конфигурация заставляет загрузить только один модуль thumbnail и отменить все остальные модули.
срабатывает на урл типа такого..

http://www.---------.net/thumbnail/123x90/test.jpg

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

а теперь модуль передает в среду движка найденные параметры

INFO found param[/thumbnail/123x90/test.jpg]
INFO found param[123]
INFO found param[90]
INFO found param[test.jpg]
INFO found param[.jpg]

и что очнеь хорошо что тепреь есть гарантия
гарантия того что например цыфры это точно будут цифры...
что имя файла буде точно алфавитное и не больше 100 символов а не хакерское "../../file.jpg"

вобщем меньше проблем с контролем урлов....

вот привожу исходники модуля... может кому интересен подход к реализации этого механизма.

http://apps.webtrox.com/locations.txt

спустя 1 час 9 минут [обр] lance10t[досье]

есть идея по рисованию таблиц


проблема в том что частенько надо рисовать какието таблицы из модулей который хоть както форматируют данные для браузера..

вот ... проблема эта есть ... - кто пишет тот знает.
потому что надо бывает делать какиенибуть хитрые таблички.
чтобы правильно распологать контент...

есть несколько вариантов решения.
ну номер 1 - станартный тупой вариант...
это внедрять и смешивать HTML и php код ..

вот пример из мамбо!..

            echo '<td valign="top" '. $width .'>';

            // outputs either intro or only a link
            if ( $z < $intro ) {
               show( $rows[$i], $params, $gid, $access, $pop, $option, $ItemidCount );
            } else {
               echo '</td>';
               echo '</tr>';
               break;
            }

            echo '</td>';

            if ( !( ( $z + 1 ) % $columns ) || $columns == 1 ) {
               echo '</tr>';
            }

            $i++;
         }

         // this is required to output a final closing </tr> tag when the number of items does not fully
         // fill the last row of output - a blank column is left
         if ( $intro % $columns ) {
            echo '</tr>';
         }

         echo '</table>';
         echo '</td>';
         echo '</tr>';
      }

начинающие програмеры!!!!....
не пишите так!!!... НИКОГДА..

потом есть распространенный вариант 2...
он помоему получше
этот пример из PHPShop

      <td width="50%" valign="top">
        <table width="100%" class="adminlist" >
          <tr> 
          <th colspan="2" ><?php echo $PHPSHOP_LANG->_PHPSHOP_STATISTIC_NEW_ORDERS ?></th>
        </tr>
        <?php foreach($new_orders as $order_id => $total) { ?>
          <tr>
          <td width="50%"><?php 
              echo "<a href=\"".$_SERVER['PHP_SELF']."?option=com_phpshop&page=order.order_print&order_id=$order_id\">";
              echo $PHPSHOP_LANG->_PHPSHOP_ORDER_LIST_ID." ". $order_id ."</a>" ?>:</td>
          <td width="50%">(<?php echo $total ." ".$_SESSION['vendor_currency'] ?>)</td>
        </tr>
        <?php } ?>
        <tr> 
          <td colspan="2">&nbsp;</td>
        </tr>
        <tr> 
          <th colspan="2"><?php echo $PHPSHOP_LANG->_PHPSHOP_STATISTIC_NEW_CUSTOMERS ?></th>
        </tr>
        <?php foreach($new_customers as $id => $name) { ?>

вот ещё один подход с подгружаемыми темплейтами...
и кстати в этоже phpShop есть куски разного стиля...
явно разные люди писали.. =)))...

      $product_cell = str_replace( "{product_flypage}", $url, $template );
if($image) $product_cell = str_replace("{product_thumb_image}", $product_thumb_image, $product_cell ); 
else $product_cell = str_replace( "{product_thumb_image}", "", $product_cell );

      $product_cell = str_replace( "{image_width}", PSHOP_IMG_WIDTH, $product_cell );
      $product_cell = str_replace( "{product_name}", $product_name, $product_cell );
      $product_cell = str_replace( "{product_s_desc}", $product_s_desc, $product_cell );
      $product_cell = str_replace( "{product_details...}", $product_details, $product_cell );
      $product_cell = str_replace( "{product_rating}", $product_rating, $product_cell );
      $product_cell = str_replace( "{product_price}", $product_price, $product_cell );
      $product_cell = str_replace( "{form_addtocart}", $form_addtocart, $product_cell );
      $product_cell = str_replace( "{product_vendorinfo}", $product_vendorinfo, $product_cell );
      $product_cell = str_replace( "{address}", $address, $product_cell );      
      /*** Now echo the filled cell ***/
      echo "<td valign=\"top\" width=\"". intval(round(100/$products_per_row)) ."%\" >";
      echo $product_cell;

вобщем понятно как работет.... =)..
просто подгружается файл типа такого..

<table width="100%" cellspacing="0" cellpadding="0" border="0" >
  <tr>
    <td WIDTH="1%"><a href="{product_flypage}">{product_thumb_image}</a></td>
    <td >
        <a style="font-size: 14px; font-weight: bold;" href="{product_flypage}">{product_name}</a><I>{address}</I><br>
        {product_vendorinfo}
    </td>
  </tr>
</table>
<hr />

и происходят подмены...
ну тоже вариант так себе.... но более мнее приемлимый...

но самый ужасный вариант(какой я видел) был в OSCommerce

    $list_box_contents[0] = array('params' => 'class="productListing-odd"');
    $list_box_contents[0][] = array('params' => 'class="productListing-data"',
                                   'text' => TEXT_NO_PRODUCTS);

    new productListingBox($list_box_contents);

навид все просто...

те вначале формируется массив... и формируется по особым правилам... как видите ключ params там есть...
и потом передается обьекту вродебы...

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

    var $table_border = '0';
    var $table_width = '100%';
    var $table_cellspacing = '0';
    var $table_cellpadding = '0';
    var $table_parameters = '';
    var $table_row_parameters = '';
    var $table_data_parameters = '';

типа такого... помимо этого можно передавать параметры выравнивания НА КАЖДУЮ ЕЧЕЙКУ!! и прочее.. и содержимое ечейки тоже передается через какойто именованный параметр...

$info_box_contents[] = array(array('params' => 'height="14" class="infoBoxHeading" width="100%"',
                                         'text' => $contents[0]['text']));

вобщем усилия на фрмирование всех этих параметров... ничуть не меньше чем на создание таблицы "вручную"... с помошью echo и циклов...

те этот подход-бесмыслеца... потмоу что не дает выйгрыша.


так вот кастаельно таблиц... я посидел подумал...
и решил сделать так, как мне будет удобнее...
вот незнаю как другим это удобно или нет покажется???..

вобщем для примера возмем таблицу из help от xpoint

таблица вам известна..

LCR
A222
A333
multi span
A4-6fourfour
fivefive
sixsix

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

$table = 
 '{(LCR)'
 .'[qwe]'
 .'[asd]'
 .'[mmm]'
 .'[zrt]'
 .'[zfg]'
 .'[zvb]}';

echo $core['html']->table($table,'test_table');

вобщем при моноширинном шрифте это смотрится ровно...

идея такова, что для того чтобы получить таблицу даже со сложной структурой ...
надо просто нарисовать эту таблицу буквми..
и если поставить рядом 2 одинаковые буквы.. то они сольются в одну большую ечейку...
(там например "m" и "z" так сливаются )
если взять в () вместо [] то это будет заголовок...
если не поствить {} то будет генерация одних <TR>
ну и конечно ..там все кешируется...
создав один раз таблицу... с кодом {(LCR)[qwe][asd][mmm][zrt][zfg][zvb]}
модуль запомнит .. схему...
и сможет вывести эту таблицу с заполненными данными ячейками уже без конструирования самой таблицы...

а если надо заполнить чемто ячейку обозначенную буквой q то надо предать параметр..
например
$t['q']="НАЧИНКА ДЛЯ ЕЧЕЙКИ q";

напримр те команды генерируют следующий код...

<table class='test_table'>
<tr>
<th class='L'>&nbsp;</th>
<th class='C'>&nbsp;</th>
<th class='R'>&nbsp;</th>
</tr>
<tr>
<td class='q'>&nbsp;</td>
<td class='w'>&nbsp;</td>

<td class='e'>&nbsp;</td>
</tr>
<tr>
<td class='a'>&nbsp;</td>
<td class='s'>&nbsp;</td>
<td class='d'>&nbsp;</td>
</tr>
<tr>
<td colspan='3' class='m'>&nbsp;</td>
</tr>
<tr>
<td rowspan='3' class='z'>&nbsp;</td>
<td class='r'>&nbsp;</td>
<td class='t'>&nbsp;</td>
</tr>
<tr>
<td class='f'>&nbsp;</td>

<td class='g'>&nbsp;</td>
</tr>
<tr>
<td class='v'>&nbsp;</td>
<td class='b'>&nbsp;</td>
</tr>
</table>

поскольку я рьяный приверженец использования CSS то меня это вполне устраивает в плане настройки внешнего вида...
потому что можно настраивать каждую ечейку конкретно.. через
.test_table .нужная_буква
{
....
}

ПРЕЖДЕ чем критиковать... обратите внимания...
я не предлагаю ЭТО как замену механизму темплейтов...
это только чтобы не рисовать таблички...!..
до темплейтов мы ещё не дошли...


PS ксати ... так случилось что пришлось использовать движок в реальных условиях... раньше чем я ожидал...
просто получилось что мы делал сайт.. и там обязательно должны были быть красивые урлы...
и оказалось что проще всего прикрутить туда этот движок.. с одним единственным модулем..
location так что ... ядро-загрузчик + loactions уже крутятся в реальной жизни..

спустя 11 часов [обр] Александр aka Efreeti(3/111)[досье]

lance10t[досье]

$table = 
 '{(LCR)'
 .'[qwe]'
 .'[asd]'
 .'[mmm]'
 .'[zrt]'
 .'[zfg]'
 .'[zvb]}';

Насколько я понял, этот механизм не предназначен для вывода таблиц, размеры которых не известны заранее (например товары в магазине). Или же нет?

спустя 2 часа 50 минут [обр] lance10t[досье]

Александр aka Efreeti[досье]
вовсе нет..
например вот этот код выведет таблицу неизвестной длинны с шапкой

$table ='{(NNP)';
$t['N']='NAME';
$t['P']='PRICE';
echo $core['html']->table($table,'product_table',$t);
// заголовок таблицы


$table =
 '[nnp]'
.'[ddd]';
// шаблон для каждого товара... на каждый товар в это примере  отводится 2 ряда.

foreach( $products as $product)
{
$t['n']= $product->name;
$t['p']= $product->price;
$t['d']= $product->description;
echo $core['html']->table($table,'product_row',$t);
/*
у каждого рядя будет CSS стиль product_row но его конечно можно менять чтобы делать полосатые красивые таблицы.
или высвечивать например некоторые особые товары... 
*/
}

$table ='[ttt]}';// последний ряд
$t['t']="summary information"; 
echo $core['html']->table($table,'table_footer',$t);

этот код сформирует такую таблицу

NAMEPRICE
prod name 110
description1
prod name 220
description2
prod name 330
description3
summary information

ну канечно можно формировать и длинну таблицы налету.. просто буквы нужно новые добавлять и все...
ведь таблица сроится фактичкси из передаваемой строки...
а какую строку передать так это уже дело програмера.
просто нетакуж и часто нужно делать таблицы которые ростут в ширину...просто сама логика таблиц подразумевает их использование.. ну какбы "вертикально".. =)..

спустя 2 минуты [обр] lance10t[досье]
там описка == "ну канечно можно формировать и длинну таблицы налету.."
имел ввиду..
"ну канечно можно формировать и ШИРИНУ таблицы налету.. "
спустя 7 часов [обр] lance10t[досье]
наваял общую схему работы ядра.
http://img82.exs.cx/img82/4480/coreactivity11yb.gif
спустя 9 минут [обр] Александр aka Efreeti(3/111)[досье]
lance10t[досье] Так $core['html']->table() что создаёт - несколько строк или же всю таблицу целиком? Просто в одном случае у Вас одним вызовом получаеться таблица, а в других - только её части...
спустя 15 минут [обр] lance10t[досье]

Александр aka Efreeti[досье]
да вы правильно заметили...

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

все зависит от фигурных скобок..
вот начало ... со скобкой..
$table ='{(NNP)';
потом повторяющаяся середина ...без скобок..
$table =
 '[nnp]'
.'[ddd]';

и в конце... опять со скобкой..
$table ='[ttt]}';

пэтому.. получались куски...

а тут открывающая и закрывающая скобка есть сразу... вот и вышла таблица целиком.
$table =
 '{(LCR)'
 .'[qwe]'
 .'[asd]'
 .'[mmm]'
 .'[zrt]'
 .'[zfg]'
 .'[zvb]}';

яж внаале написал... "если не поствить {} то будет генерация одних <TR>"

спустя 11 часов [обр] Александр aka Efreeti(3/111)[досье]

lance10t[досье] Простите, пропустил Вашу фразу.

В общем, довольно оригинальное решение. Интерестно, что скажут другие участники.

спустя 33 минуты [обр] Алексей Севрюков(2/1280)[досье]
Лично мне такой вариант кажется абсолютно нечитабельным.
спустя 27 минут [обр] lance10t[досье]

Алексей Севрюков[досье]
насчет нечитабельности...
вот например это ечейка для товара из phpShop

{product_name}
{product_image}{product_description}
<hr>
{product_price}
{product_rating}{product_addtocart}

это подгружаемый темплейтик.

<table width="100%" cellspacing="0" cellpadding="0" border="0">
  <tr>
    <td colspan="2">11
        <a style="font-size: 16px; font-weight: bold;" href="{product_flypage}">{product_name}</a>
        
    </td>
  </tr>
  <tr>
    <td ><a href="{product_flypage}">
          <img src="{product_thumb_image}" width="{image_width}" border="0" alt="{product_name}" /></a>
    </td>
    <td >{product_s_desc}<br />
      <a style="font-size: 9px; font-weight: bold;" href="{product_flypage}">[{product_details...}...]</a>
    </td>
  </tr>
  <tr>
    <td colspan="2"><hr /></td>
  </tr>
  <tr>
      <td align="center"colspan="2" nowrap align="left">{product_price}</td>
  </tr>
  <tr>
      <td width="60%" align="center">{product_rating}</td>
      <td width="40%" align="right">{form_addtocart}</td>
  </tr>
</table>

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

t['n']={product_name};
t['i']={product_image};
t['d']={product_description};
t['h']='<hr>';
t['p']={product_price};
t['r']={product_rating};
t['a']={product_addtocart};

$table=
 '{[nn]'
 .'[id]'       
 .'[hh]'       
 .'[pp]'       
 .'[ra]}';

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

спустя 15 минут [обр] Алексей Севрюков(2/1280)[досье]

lance10t[досье] Только не Вашим способом. Вам может быть и удобно (хотя если Вы под себя и делаете то почему и нет). Лично в первом варианте сразу понятна структура.

Я вообще не могу уловить суть Ваших шаблонов. Хорошо, вот Вы привели, пример, а покажите как он будет подставляться в HTML?

спустя 43 минуты [обр] lance10t[досье]

Алексей Севрюков[досье]
вот одной строкой

echo $core['html']->table($table,'product_table',$t);

если надо именнт подставить то можно и без echo
а например получить HTML во внутрь переменной

нууу...
вот может это прояснит ситуацию

http://img27.exs.cx/img27/5176/source0kq.gif

http://img27.exs.cx/img27/6764/result9dr.gif

спустя 10 минут [обр] Алексей Севрюков(2/1280)[досье]
lance10t[досье] Т.е. у Вас все равно соеденены срикпт с шаблоном. Т.е. по русски - в скрипте задаются переменные, которые потом помещаются в шаблон?
спустя 10 минут [обр] lance10t[досье]
ну да.. переменные задаются...
но не только переменные но и ВЕСЬ сам шаблон хранится внутри скрипта..
хранится одной строкой... '{[nn][id][hh][pp][ra]}' вот и весь шаблон.
те нет никакого внешнего файла ...
вот те скриншоты - это все...
там не загружается нкаких дополнительных шаблонов..
функция.. table налету сделает HTML таблицу(на основе '{[nn][id][hh][pp][ra]}' ) и заполнит её переданными данными из $t[]
спустя 21 минуту [обр] lance10t[досье]

вот можете сами поиграться с этим генератором..
вот код...
http://apps.webtrox.com/html.txt

там надо внести поправку и он будет запускаться как отдельный обьект.
а то шас он "extends module"
на enableDirectDraw не обращайте внимания... это так для скорости...
если это будет отдельно стоящий обьект то enableDirectDraw не нужен.

спустя 1 час 41 минуту [обр] lance10t[досье]

кстати по поводу дебаганья .. я тут откапал казырную штуковину!..
Eclipse называется...
ооочень интеллектуальная..
думаю скриншоты покажут что это за зверь.
это редактор
http://img43.exs.cx/img43/8695/editor0xt.gif

ну там полный набор!..от сворачивания функций в трубочку!..
всевозможные всплывающие подсказки
и ВСЕ настраивается все хоткеи Ctrl+Tab и прочее.. как что будет работать
ну и поддержка не только Projects но и Workplace!
также он показвакт ошибку в скрипте в тот самый момент как её пишешь.. а не когда только запустил скрипт.
показывает где была обьявлена функция .. при наведении мыщки и какие она хочет параметры.
также всплывает и хелп для родных функций php ...

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

http://img33.exs.cx/img33/2480/debuger9cr.gif

но это не просто дебагер! это мульти дебагер.. на скриншоте видно что я запустил 2 дебагера одновременно один стережет файл index другой стережет class.module.php
ну вобщем - просто сказка... ведь можно этими дебагерами управлять .. типа остановить дебаганье index поработать.. потом одной кнопкой снова включить дебаганье... и у каждого дебаг процеса- свои настройки.

помимо всего этого там есть хрень для работы с SQL

http://img128.exs.cx/img128/3950/sql3lx.gif

тожне добрая штука.
и также встроенная поддержка CVS!!!... (я правда ей не пользуюсь)

и-и-и.. (БАРАБАННАЯ ДРОБЬ)
ВСЕ ЭТО СОВЕРШЕННО БЕСПЛАТНО!.. без всяких кряков.

единственное что плохло... чтобы все это запустить у меня ушел 1 день....
потмоу что там есть некоторые тонкости при настройке дебагера чтобы он правильно работал...

спустя 1 час 5 минут [обр] Алексей В. Иванов(0/2861)[досье]
я тут откапал казырную штуковину!..
что-то все забывают сказать, что эта "штуковина" написана на Java и жутко тормозит на любых машинах, независимо от конфигурации.
спустя 15 минут [обр] lance10t[досье]

Алексей В. Иванов[досье]
не смешите мои тапки.. я в даннную минуту работаю
    Компьютер:
      Операционная система Microsoft Windows 2000 Professional
      Пакет обновления ОС Service Pack 4
      Internet Explorer 6.0.2800.1106 (IE 6.0 SP1)
      Имя компьютера WINTER_SILENCE
      Имя пользователя Administrator
      Вход в домен WINTER_SILENCE

    Системная плата:
      Тип ЦП Intel Pentium IIIE, 800 MHz (6 x 133)
      Системная плата Dell Computer Corporation OptiPlex GX110
      Чипсет системной платы Intel Whitney i810E
      Системная память 192 Мб (SDRAM)
      Тип BIOS Phoenix (08/30/01)

не жалуюсь на скорость.
а дома где у меня машина помощнее так там вобще летает.

спустя 5 минут [обр] lance10t[досье]
а забыл добавить что при этом у меня запущены сервера... sql и apache.
спустя 6 часов [обр] Алексей Севрюков(2/1280)[досье]

lance10t[досье]

кстати по поводу дебаганья .. я тут откапал казырную штуковину!..
Eclipse называется...
ооочень интеллектуальная..

На вкус и цвет товарищей нет. Notepad - FOREVER!

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

спустя 33 минуты [обр] lance10t[досье]

Алексей Севрюков[досье]
дауж .. =)..
ну попробую последний раз.

вобщем. есть таблица...которую надо сделать и наполнить ечейки разными данными..
эnо стандартная задача.

но проблема в том что таблица бывают зачастую сложными и их надо както ОПИСАТЬ чтобы компьютер понял какую таблицу надо вывести.
описать таблицу можно например с помощю HTML и вставок типа <?=$переменная_php?>

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

итак.

поймите .. чтобы сделать таблицу - её надо нарисовать псевдографикой

есть некоторые правила рисования..

  1. каждая ечейка рисуется какойто буквой...

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

  1. границы рядов изображаются квадратными скобками.
  1. границы таблицы рисуются фигурными скобками
  1. две(и более) ячейки "одинакого цвета" ..(наприсованные одинаковыми буквам)

сливаются в одну ечейку.

ВСЕ.

НАПРИМЕР
таблица для играния в крестики-нолики
должна состоять из 9-й разных ячеек...
давайте нарисуем её с помошью псевдографики

{[qwe]
 [asd]
 [zxc]}

теперь каждая ечейка обозначена одной какойто буквой..

соотвтственно центральная клетка обозначена буквой "s".. это видно?..
правая нижняя буквой "с"... итп..
компютер ДОЛЖЕН интерпритировать этот рисунок как таблицу

qwe
asd
zxc

PS
и заметте копьютеру абсолютно всеравно каким именно буквами вы будете рисовать эту таблицу.

надо про слияние обьясняь или уже стало понятно?..

спустя 12 минут [обр] Алексей Севрюков(2/1280)[досье]

Теперь понял, без описания трудно конечно понять. Только вот все равно я не считаю такой способ удобным. Я только не понимаю - зачем изобретать какой то новый синтаксис? Имхо - xml читабельнее (хотя и избыточен, а как другой человек потом будет разбиратся в Ваших таблицах я себе слабо представляю). Хотя на вкус и цвет товарищей нет.

Хорошо, с этим все ясно. Теперь я хочу сделать в ячейках разное выравнивание и какие-нибудь другие атрибуты, тот же самый nowrap, например.

спустя 5 минут [обр] lance10t[досье]

вобще ... этот способ.. ну рисовать буквами я придумал ещё в универе.
когда мы писали в досе на паскале.. лабораторную работу.
где надо было выводить самопальные картинки...
и все почмуто мудохались с огромными масивами строк
put_pixel (x, y, color)
put_pixel (x, y, color)
put_pixel (x, y, color)
put_pixel (x, y, color)
или lineto(x , y )
... я чето посмотрел на все это с тоской..
и потом нарисовал даже мультик маленький...
потмоу что не стал делать как все они..
а делал картинку рисуя прямо буквами.


Теперь я хочу сделать в ячейках разное выравнивание и какие-нибудь другие атрибуты

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

в css (относящийся к нужной ечейке) напишите white-space: nowrap
вот и все.

спустя 5 минут [обр] lance10t[досье]
 зачем изобретать какой то новый синтаксис?

потмоу что помоему этот новый синтаксис лучше HTML

  1. легче воспринять
  2. он заставляет использовать CSS для оформления(это хорошо и правильно)
  3. его легко менять во время разработки сайта.
  4. он избавляет от ошибок возникающих при неосторожном использовании html

(особенно в больших и сложных таблицах легко напортачить а потом трудно искать)

  1. он позволяет в будущем заменить ОДНУ функцию генерации ..и перевести сайт например на xml или на какойто ещё формат.

(без необходимости серьезно переделывать модули)

достаточно? =).

спустя 4 минуты [обр] lance10t[досье]
а и ещё... центральна функция генерации может быть достатоно отлажена чтобы генерировать канонически правильный и чистый html код, что само посебе уже круто и этим можно будет гордицца =).. и повесть такой значек...
типа "ОДОБРЕНО W3C"
спустя 47 минут [обр] Алексей Севрюков(2/1280)[досье]

lance10t[досье]

  1. Это к п. 5. Хорошо, а теперь я хочу сделать вложенные таблицы. Или сгенерировать этим шаблоном кусок XML вида:
<items>
<item>
<title>Щетка надувная щетинистая</title>
<price>100</price>
<description>простая такая щетка, формат PS/2, автоматическая, 20 fps</description>
</item>
...
</items>

Т.е. для этого мне надо переделать функцию генерации? А если завтра я хочу поменять формат, например на CSV? Мне опять надо переделывать функцию генерации. ИМХО, неудобно.

  1. Я хочу чтобы у каждой 2-ой (3,4,5, ...) строки был другой класс (например зебру сделать). Мои действия?
спустя 7 минут [обр] Александр aka Efreeti(3/111)[досье]
lance10t[досье] Но ведь букв может и не хватить. Крайне редко, но случаеться ситуция, когда у вас есть таблица, в ней много рядов, но стиль у них повторяется через раз (классическая зебра), и в каждой строке по 14 (или даже больше) ячеек с разными стилями. А букв то всёго 26! Что будете делать в таком случае?
спустя 6 минут [обр] Алексей Севрюков(2/1280)[досье]
Александр aka Efreeti[досье] Добавит большие буквы, цифры и прочее. Для таблицы 3 на 3 еще более или менее читабельно. А вот как быть с таблицами 10 на 8 например я себе слабо представляю.
спустя 5 часов [обр] lance10t[досье]

Алексей Севрюков[досье]

Или сгенерировать этим шаблоном кусок XML вида:

сейчас я не занимался этим ... и XML не сгенерируется ну никак.

"Т.е. для этого мне надо переделать функцию генерации? А если завтра я хочу поменять формат, например на CSV? Мне опять надо переделывать функцию генерации. ИМХО, неудобно."

конечно неудобно...
но переделывать одну функцию- лучше чем преписывать все места её вызова.

Хорошо, а теперь я хочу сделать вложенные таблицы.

а вот это не проблема..

вот например вставка маленькой таблицы 2x2 во внутрь правой верхней ечейки таблицы 9х9

$table =
 '{[ty]'
  .'[gh]}';

$t['e']=$core['html']->table($table,'guest_table',$g);

$table =
 '{[qwe]'
  .'[asd]'
  .'[zxc}';

echo $core['html']->table($table,'host_table',$t);


Я хочу чтобы у каждой 2-ой (3,4,5, ...) строки был другой класс (например зебру сделать). Мои действия?

посмотрите сообщение от 2005-01-09 03:07:06
там показано как делать таблицы неизвестной длинны.
и какраз там есть возможность давать стиль целому ряду.
и при этом не надо использовать кучи разных букв.
вобщем ..это совершенно не проблема. просто прочитайте немного выше.

А вот как быть с таблицами 10 на 8 например я себе слабо представляю.

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

если там есть много поторяющихся(по виду) рядов посередине то опять это не проблема.
посмотрите сообщение от 2005-01-09 03:07:06

те на создание таблиц для форума(типа phpBB) этой системы должно вполне хватать.

спустя 38 минут [обр] Алексей Севрюков(2/1280)[досье]

lance10t[досье]

сейчас я не занимался этим ... и XML не сгенерируется ну никак.

конечно неудобно...
но переделывать одну функцию- лучше чем преписывать все места её вызова

Как раз наоборот. Шаблон у Вас для каждого сайта свой и таблицы могут быть свои. И проще в шаблоне сделать нормальный вывод. У Вас же вся фнукциональность завязана на одну функцию обаработки. И чтобы будете делать если понадобятся другие форматы? Писать дополнительные функции и писать $core['html']->csv(...) или $core['html']->xml(...)?

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

Например в CMS. Хотя да, я не совсем сообразил, столбцов то будет 10, а строки будут разные.

спустя 4 часа 19 минут [обр] lance10t[досье]

Алексей Севрюков[досье]

Как раз наоборот. Шаблон у Вас для каждого сайта свой и таблицы могут быть свои.

цитирую сам себя
2005-01-08 13:14:26

ПРЕЖДЕ чем критиковать... обратите внимания...
я не предлагаю ЭТО как замену механизму темплейтов...
это только чтобы не рисовать таблички...!..
до темплейтов мы ещё не дошли...

этот механизм для внутреннего использования в модулях.
например делая логин форму надо бывает расположить все красиво а не просто вывалив в кучу <input>
или надо выводить картинки товара особым образом в колонку справа от товара.
или надо выводить в форуме сообщения в виде сложной таблицы.
или просто делая кртотеку надо распологать данные карточки на экране особым образом.
или например делая форму для голосования.
вот для такого рода проблем и сделан этот механизм.
и он .. специально сделан так чтобы не мешать оформлению сайта..все таблицы получаются абсолютно безликие.
и могут быть гибко настрены под любое оформление.
те.. это механизм.. он только для создаия небольших кусочков-кирпичиков...которые будут в последствии вставлены в темплейт.

так вот чтобы перевести это в другой формат...
надо будет соешить подмену..
модули .. как вызывали $core['html']->table();
так и будут вызывать.. только функция будет их обманывать и выдавать XML например
или возможно тотже SCV ...
а другие форматы будут делаться так..

$core['xml']->node(...);
или
$core['csv']->addLine(...);

спустя 15 минут [обр] lance10t[досье]
ХОЧУ ЗАЯВИТЬ ВСЕМ.
сечас я склоняюсь к тому чтобы выпустить
(когда будет более-мнее готово)
эту CMS как open source но при этом держать и закрытый зеркальный проект который можно будет продавать с другой лицензией.
спустя 27 минут [обр] Алексей Севрюков(2/1280)[досье]
lance10t[досье] Понял. Ждем дальнейших достижений.
спустя 12 часов [обр] newcontinent[досье]

Пора кончать с системным идиотизмом nuke, а то идиотизм прикончит нас.

Одназначно!
Ясно, что блоги не только модное поветрие, но и наиболее перспективная концепция современной единицы информационного наполнения сети (сайта).

Во-первых.
Любая информация размещенная в сети мёртвая, если ее нельзя прокоментировать. Если подумать - это касается абсолютно любой информации. Ссылки, файлы, программы, новости, статьи, объявления, предложения...
[i]Отсюда понятна «непонятность» :) структуры Борзе и многочисленных его последователей. Функциональная нечеткость назначений стандартных модулей nuke: «новости» ( по сути лента текстов с возможностью комментирования), «content» (тексты без возможности комментирования, но с вводной частью, закл.частью подписями), «review»( загадачная вещь :) , новые сторонние модули «pages» и другие advanced фичи. Неясность назначения «Категорий», «тем», «разделов». Аброкадабра.
Всё это усугубляется традиционным критинизмом русских переводов. Что имел ввиду Франческа когда создавал модули «review» , «news» , «content» так и останется ментальной тайной. А мы узнаем только то, что вообразили по этому поводу переводчики наши славные локализаторы. Очень большие сомнения одолевают, что разработчики Windows закладывали в свои лабелы темное историческо-аптекарное словечко «Ярлык». Однако Казанские переводчики подарили России новый и яркий компьютерный термин, который включен во все пособия для чайников по Windows.
[/i]

Во-вторых.
Технически, реализация практически любых таких информационных модулей ничем не различается. Самое время подумать о стандартном классе. Отличия только в названии модуля «name», специфики названий стандартных узлов «node» . То есть узел можно назвать «товары», а можно «статьи», или «программы» (орписание), или «новости». Механизмы абсолютно одни и те же.
Объяснюсь до упора, что бы не возвращаться. Соответстветственно в ноды можно помещать описания товаров, тексты статей, описание прог, новости и т.д.
Во всех без исключения случаях желательно (необходима) функция помещения изображения. Может быть меняя размер, положение на странице.
Во всех без исключения случаях нужна, точнее необходима возможность комментирования.
Можно добавить в админскую часть - «вкл»-«выкл» эту доп.функциональность.

В-третьих
Структура таблиц абсолютно идентична «id» - сущности (никаких идиотских «id-anketa», «id-store»...) «id» и в африке «id». Далее родительский узел «parent», «name» (и так понятно) ... и далее по вкусу, но лучше сразу стандартизировать «date», «description», «keyword» (сразу заложить поля для динамических тагов) , «short» (короткий анонс основного текста можно еще announce) , «text», «image», «author», «agent», «number», «born» (birthday сущности) ... добавляйте далее по вкусу. Можно первую часть стандартизировать, а дальше free для гибкости.

[i]В сложных случаях иерархия ссылок на standard таблицы. Например, если надо запомнить много ссылок относящихся к одному объекту - пожалуйста. Связь по полям id (в основной таблице описания сущности) - parent (в единой для сайта общей таблице reference - тот самый каталог links :)
Повторяю таблицы индентичны, во всяком случае первые поля.
Любое поле может содержать в себе вместо записи идентификатор - это значит, что значения надо искать в соотвествующей таблице, например по названию поля.
То есть если вместо красивого имени или логина автора в поле «athor» торчит что-нибудь уродское типа начинающееся с id_12345 - значит искать в таблице «athor» по полям parent и(или) link со значением 12345. Выглядит немного сложновато, но это для сложных случаев и стандартизированный (значит документированный) механизм. [/i]

Таким образом реализуется чрезвычайно гибкая структура на основе стандартизированных таблиц. Которые в некоторых случаях небольших или специализированных сайтов вообще можно свести в одну, добавив поле «modul» для идентификации принадлежности к одному из модульных расширений.
И на основе стандартизированного кода. Вот редкий действительно подходящий и оправданный случай для применения классов.

Идиотизм построения nuke-систем на лицо. Отсюда куча мелких ошибок, глюков, от которых в сложившейся системе невозможно избавиться в принципе. Касается и всех десятков, а то и сотен клонов. Заразно. Передаётся по наследству.
Из промежуточной пользы, которую можно получить от nuke, можно отметить использование системы администрирования. (Cкорее всего временно). И конечно объединяющий фактор - «не на пустом месте».

В-четвёртых. Всё, это как правило, с разной степенью успешности, во всяком случае, пытаются реализовать в системах блогов. Можете взглянуть [url=http://www.newcontinent.org]newcontinent.org[/url], [url=http://www.livejournal.com/users/newcontinent/friends]ЖЖ livejournal.com[/url]

[b]Пора кончать с системным идиотизмом nuke, а то идиотизм покончит с нами. ( nukes idiots :)[/b]
Предлагаю открыть коллективный проект по написанию класса (может быть группы) к nuke (не факт, что к nuke, класс можно сделать системо-независимым) для реализации стандартизированного информационного модуля. Желающим и заинтересованным предлагается включиться в общий агрессивно-креативный поток «эры Водолея».

По сути, вся функциональность классов уже написана. Например модули: «files», «pages», «spaw» - там и так всё уже есть. Останется только скомпоновать, добавить несколько доп.классов. И Российский «линкор» (линейный корабль - модульная информационая система на основе nuke) отправится в кругосветное плавание по бескрайним информационным просторам, оставив далеко позади пошлых Европцев.
Иначе так и будем поджидать новенькие Франческины идейки и версии с новенькими лицензионными происками. А в нашем случае, это позволит напрочь отделить содержательную систему модулей от административного ядра.
Momentum more

спустя 4 часа 44 минуты [обр] Александр aka Efreeti(3/111)[досье]
newcontinent[досье] Это ОФФТОПИК. А по моему глубокому IMHO, ещё и полная ...
спустя 1 час 49 минут [обр] lance10t[досье]
newcontinent[досье]
вы наверно дверью ошиблись...
батенька, ваш бганивичек для толкания агитационных речей явно не тут.
спустя 3 часа 50 минут [обр] newcontinent[досье]

Вот хотела мнение специалистов послушать насчёт идеи и возможности ее реализации
а не пацанскую :) болтовню про лажу флуд двери и оффтопик.
Александр aka Efreet, если в состоянии по человески, поясни (аргументировано только :), пожалуйста почему считаешь что это лажа.
lance10t то же самое, если можешь конечно.

могут быть несколько вариантов. Коллективно мы сможем определить наиболее приемлемое и рациональное решение.
Вот пара принциальных вариантов.

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

И так вариант с единой разделяемой common библиотекой общих функций и вариант класса
например "russian_modul" (уж больно банально звучит и М :) лучше просто "russian" :)
Соответственно в случае класса это не старые добрые function и variant, а новенькие методы и свойства.
Хрен редьки не слаще.
________________________________
Личный состав (Свойства) :

$id -
$parent - родитель
$node - идентификатор узла(node)
$type - возможность определять типы. Еще не знаю конкретного тприменения, но например типы лента, галерея, оглавление, ... (идеи)
$word - array специцифической терминологии, напрмер:
                  книга, часть, глава, страницы, абзац, комментарии ;
                  магазин, отдел, витрина, товар, ценник, книга жалоб ;
                  каталог, раздел, подраздел, ссылка, примечания ;
                  Это также можно более гибко определить в текст-языковом файле, термины статические и наверное нет смысла загружать ими базу.
$parent - родитель
$code - личный числовой код (специально закладывается некоторая избыточность, потом лишнее выкинем)
$name - ясно
$base - Базовая опорная таблица модуля. Можно сначала поискать таблицу соответствующую имени модуля, а, в случае неудачи, использовать значение этого поля. Хотя для устранения всякой автоматики :) лучше явно задать и знать где лежит идентификатор таблицы.
$title -
$description -
$key - для этетов metatag system там вообще их еще много
$announce -
$text - текстовое содержание
$date -
$born - время рождения записи
$author -
$agent - типа модератора, например агент по клиентам, но который может добавлять и редактировать своих users
$lang - ссылка на расположение языковых файлов
$theme - ссылка на расположение шаблонов, если таковые имеются
$link -
$note - тех.примечания
$image -
$small - thumbnale
$midle - иил проще image1, image2, image3, а то и в одно поле поместить 256 если использовать base_url то поместится и больше чем три, но если это ссылки на изображения то тогда лучше отдельные поля.
...
добавляйте (аргументированно), подправляйте(взвешено)

__________________________________________
... далее free parameters

Methods (чего делать умеет)

create() - создаёт новое расширение (модуль) и возможно запоминает параметры в таблицу расширений (модулей)

new() - тиражирует имеющийся модуль (создаёт новый экземпляр по аналогии с ООП).
         Например есть модуль news, можно создать news("местные"), news("заграничные"), news("дурацкие") ...

add() - добавление новой сущности, проще записи в таблицу по имени расширения.
         forexample : add("Новое объявление") в таблицу announcements,
                       add("Новая статья ") в таблицу stories.
comment() - может быть реализован как отдельный клас (только нафиг), так в xoops но там концов не найти, потому, что и DHTML тоже классы.

/* Если внутри функций пометить механизм наподобие
if ($row2['radminsuper'] == 1 || $auth_user == 1) { ...
можно позволить админу производить эти действия со всеми записями, а не только со своими.
*/

edit() -
delete()
image()
/* Такие действия как изменения параметров картинки лучше выполнять передавая сигналы в метод, чем плодить и потом документировать отдельные специальные функии методы как например getImageSize(), setImageHeight() и тд Лучше image(12345, , , height=100, , ,);
*/

rss() - соверщенно обязательный метод-свойство для любого типа узлов.
theme() - мгновенная смена шаблона. (лучше если селектор тем всегда доступен, например в спец блоке)
...
добавляйте (аргументированно), подправляйте(взвешено)

__________________________________________
В результате получим прогр. интерфес (будет чего документировать) или всем известный универсальный класс. Ну одним то наверняка дело не обойдется, но нельзя допустить экспансионизма и раползания вширь. Шейпинг и гимнастика.

А теперь самое главное.
«Король умер. Да здравствуект король!»

В index.php где то около строчек $modpath .= "modules/$name/".$mod_file.".php";

Встраиваем механизм сканирования наличия виртуального (новое название :) т.е. которого нет ) модуля в таблице вирт.модулей (это может быть и обычная таблица moduls, но там не достаточно полей, что бы запомнить все характеристики модуля например
new($id, $parent, $node, $code, $name, $description, $key, $announce, $text, $author, $date, $agent, $link, $note, $image ... далее free parameters )
Кстати это не ошибка. :) Сами модули как сущности также могут размещать свои характеристики в стандартизированной структуре, в нашем случае таблице "russians" содержащей записи о наделанных расширениях-модулях (в старой терминологии)
Дальше просто.
Где то здесь надо поместить загрузчик v-модуля.

if (file_exists($modpath)) {
   include($modpath); //
} else {
...

Если такой модуль найден (если не найден генерим по умолчпнию) создаем новый экземрляр нашего класса через самодельную new() или стандартный механизм создания экземпляра класса new("Russian") красиво $our=new("R") и забиваем в него его сохранённые параметры.
Например сразу через конструктор :
new($id, $parent, $node, $code, $name, $description, $key, $announce, $text, $author, $date, $agent, $link, $note, $image ... далее free parameters )
или присваивая значения после создания
$our=>$date($now);
$our=>$image("http://newcontinent.ru/i/sitechko.png");
...
Модуль работает.
Всё.

И в чём лажа?
С таким же успехом можно сказать, что писать браузер на js(и чего там профессионально знать можно :)
чудеснейшая глупость и утопия, как с тех, так и с маркет сторон.
Шутка.

спустя 44 минуты [обр] lance10t[досье]

newcontinent[досье]

Вот хотела мнение специалистов послушать насчёт идеи и возможности ее реализации

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

спустя 14 минут [обр] newcontinent[досье]

Сколько я помню это название этого топика -"пишу CMS(мысли вслух, концепции, идеи, решения)"
А я как раз и выкладываю мысли-вслух, концепции, идеи и решение практически новой СМS на основе популярных клоногв nuke
Может название темы неправильное, а надо было назвать идеи lance10t
или может я неправильно с русского его перевела :)
Но Вы lancelot мне подходите в качестве рыцаря :) и Александер тоже , еще и поэтому пишу здесь

поэтому вот еще и если и это не понравится уйду от вас свой топик делать :)

 
Общие вводные вопросы «Russian».

Black_Heart: Я так понял что это попытка сложить всё в одну кучу, с изменениями под текущие потребности. Т.е. нечто вроде контента+SPAW+комменты+download+upload+динамические титлы+...+... Но при этом это один модуль и при создании нового раздела, подключаешь к нему нужные функции.

israelin : Идея интересная... На самом деле, ведь можно же создать единый блок-модуль "для всего", с возможностями и News, и Downloads, с редакторами текста, с организацией перекрёстных ссылок, может, с возможностью добавления собственных полей из админки....

Yuras : Сложно будет, имхо, разделять полномочия на гостей, юзеров, админов, когда все это будет унифицировано. А мысль стоящая.

kristallex :Унификация с использованием классов может стоить производительности. Но сама идея интересна и может нести к примеру следующий характер:
имеем модуль с именем "х". Поля стандартные не варьируются, варьируется лишь вывод информации из этих полей: выводить/не выводить. Все запросы модуль делает к таблице $префикс_$имя_модуля. Далее все просто - оснащаем аднинистративный раздел инструментом, который способен клонировать данный модуль "х", как файлы, так и таблицу БД (соответственно назвав таблицу по имени клона)... Развивать?

dwarf_Kain : Помойму у Вас очень смутное представление об ООП и классах. Испольовать их в нюке будет несколько неудобно. Если уж Вы взялись за разработку модуля, который может заменить всё, - то проще написать свою CMS. Всё вешать на один модуль?) Классы и ООП сильно сужаёт возможность модернизации/изменения для обычного пользователя. Придётся так же попыхтеть над админкой, т.к. для тех кто любит раздавать другим юзерам права будет неудобно.

Ответы :

  1. Никакой кучи :) а стройный проинтерфейс. Настройки коорые обычно записываются в config модуля или config табличку запоминать в регистрационной таблице модулей. Модуль в данной концепции представляется как запись в таблице с набором полей-свойств-характеристик модуля. Соответственно появляется возможность добавлять много, очень много разных модулей, сколько в табличку поместится. Самого модуля, в виде файлов не существует. В память загружается класс, из регистрационной таблицы модулей считываются его свойства и присваиваются новому объекту. Модуль работает. В случае использования include() библиотеки функций вызов виртуального модуля осуществляется через специальную функцию подменяющую оператор new() из ООП. Суть процесса таже.

<i>(отвлечённое дополнение : Кстати в качестве свойств в таблицу можно записывать хоть целые куски кода, функции, нечто подобное делается в Майрософтовских свойствах, когда в качестве значения полю прописывается вычисляющая функция.)</i>

  1. Дубовое использование классов как в xoops утомялет, там даже элементы DHTML реализованы как классы. Замучаешься их интерфейсы изучать. Но есть ситуации где классы очень подходящие. Например здесь. Забегая вперёд немного, скажу, что реализовать функциональность nuke в файлах main.php, modules.php, config.php и т.д. можно наследованием нашего универсального инфо класса «russian» от, скажем, базового «nuke» в которм будет реализованы инициализация, проверки и т.д. Это по поводу сложности разделения полномочий. То есть полезный механизмы нюки сохранены. А можно просто оставить все include() как и было.
  1. Да! на идетичные имена таблицы и модуля помогут съэкономить одно поле. И вообще логично. Но могут быть ситуации когда несколько разных модулей смогут использовать одну и ту же базовую таблицу. Пример мой подправленный Web_Links из которого получился модуль links. Они могут работать одновременно и использовать одну и туже таблицу и одни и теже данные. Только links по встроенному жлобству будет выводить только ссылки с обратной ссылкой на себя :) В то время как стандартный Web_Links будет выводить все, но своим уродским нюковским способом, через сами знаете что. Так что я за явное указание имени таблицы, а может и таблиц через запятую. Гибкость.
  1. Не нужно клонировать файлы их и так гора. Наоброт избавиться от фактически повторных текстовых скриптовых файлов и использовать вместо них разделяемый общий код или общие функции или класс. Даже малая степень реализации common кода даст эффект хотя бы в уменьшении размерав кода.
  1. Свою CMS писать не проще. Бесконечное дублирование. Проблемы будут теже. Выращивать рациональную систему. На основе существующих наработок, идей, решений их множество. ну какой смысл писать свой spaw или новый вариант files, когда там и так всё оптимизовано и рационально.
спустя 51 минуту [обр] lance10t[досье]

newcontinent[досье]

я написал в самом первом сообщении этого топика.

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

надеюсь этот отчет-дневник о написании CMS будет вам интетесен а комуто полезен.
также надеюсь что если я буду ошибаться вы меня поправите.

если(а в данном случае это так) ваши идеи не касаются конкретно того что я пишу.. то и не пишите СВОЕ в этот топик.

спустя 13 минут [обр] newcontinent[досье]
Ладно. Убедил.
спустя 20 минут [обр] Александр aka Efreeti(3/111)[досье]

newcontinent[досье]

  1. Как вам уже скзали, надо в свою тему писать.
  2. Очень сумбурно написано, и непонятно к чему всё.

Господа модераторы:
Если newcontinent[досье] создаст свой топик, большая просьба перенести/удалить соответствующие постинги из этой темы. Если не создаст, то всё равно удалить.

спустя 3 часа 19 минут [обр] lance10t[досье]

возвращаясь к теме.


это просто заметка.

у меня дома 2 компьютера один современный и быстрый
а другой пентиумII 400 довольно тормазнутенькая тачка...
учитывая то что я пользуюсь не всех компах одним и темже софтом.
одинм и темже шеллом и одним и темже браузером файрфоксом с плагинами.

так вот.. разрабатывать эту CMS мне нравится именно на стареньком компе.
и вот почему.
я проверял и убедился что файрфокс при загрузке сайта сжирает 100% процессора ..и комп попросту тормозит..
так вот
почему приятно разрабатывать за таким компом.
потому что я замечаю без измерительных приборов как и с каими задержками работает скрипт =)..
те я в настрйке сайта
пишу например вместо
AddModule html (которая подключает модуль при старте скрипта)
на
DynModule html (загрузка по принципу DLL)
и тутже ВИДНО как скрипт загружается подругому с микрозадержкой!
перед тем местом где первый раз обращение к этому модулю.
и даже слышно как клацает HDD =))...

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

спустя 21 час [обр] lance10t[досье]

=)...знаете..
вот ведь так бывает что на PHPэшном сайте чтонить случается когда он ещё не хорошо отлажен и лезут всякие warnings
и некоторые клиенты видя стандартное сообщенеи об ошибке на сайте (которое кстати разрывает весь дизайн к чертям)..
очень сильно начинают волноваться ...ну типа все сайт накрылся медным тазом.
вобщем панику разводят. и этим действуют мне на нервы.
но и ошибки отключать полностью- глупо.
так вот я такю штуку сделал чтобы небыло паники.
посмтавил обработчик ошибок который заменяте сообщение на картинку

вот например warning это красный жук
а notice это черножелтый
http://img120.exs.cx/img120/1010/shot9qf.gif
и при наведении мыши показывается сообщение об ошибки.
ну .. вобщем дизайн при таком выводе не рвется и клиенты не паникуют и нервные клетки целы. =)..

вобщем кому идея понравилась..
вот http://apps.webtrox.com/buger.zip
забирайте и пользуйтесь !.. картинки 3 разных стилей прилагаются (если ктото хочет более строгого вида чем жуки) =).

спустя 8 часов [обр] Алексей Севрюков(2/1280)[досье]
lance10t[досье] а что хорошего если страница будет заполнена жуками? Может удобнее сделать страницу ошибки и на ней выводить ошибку. Для разработчика ее прятать, а для пользователя показывать что-нибудь типа "Идет профилактика".
спустя 1 час 53 минуты [обр] VR[досье]

А чем вам TYPO3 (www.typo3.com www.typo3.org)не понравилась?
Использую ее уже полтора года (последние полгода активно).

Cлишком сложно показалось?
"Месяц биться головой об монитора, зато потом счастье на всю жизнь..."
Примерно так кто-то написал про изучение TYPO3.
Но, так это система несколько другого класса, чем Mambo :-)


...demonstrated TYPO3 in a lab environment some months ago. This was an evaluation of:
CMS-packages: MMBase, Microsoft CMS, Smartsite en TYPO3
Portal-packages: Luminus, Microsoft Sharepoint, Oracle, SUN en uPortal
TYPO3 was declared the cheapest to implement and the most userfriendly.


Одно из заметных достоинств - заказы можно брать только благодаря TYPO3
(некоторые заказчики хотят именно ее).

спустя 16 часов [обр] lance10t[досье]

Алексей Севрюков[досье]
если пользователя вобще капитально обманывать(в плане ошибок) то ИМХО от этого в сумме вреда больше получается чем пользы....
а насчет "профилактики".. ну незнаю...просто у нас случай был когда сайт работал но глючил один модуль... те сайт грузился..
и могбы и дальше работать еслибы его не разрывало сообщением об ошибке.
а еслибы вместо этого была "профилактика" то клиент бы вопил страшно.. "какая профилактика?! давайте сайт включайте у мнея клиенты зайти не могут"..
а жучок вместо убившегося баннера или какогтот ещё модуля
... это былобы самое то!..

вобщем от ситуации зависит что лучше...
вот вы считаете что так лучше вот и напишите и тоже на формуе дайте скачать.. вам будут благодарны. =).

спустя 1 час 13 минут [обр] lance10t[досье]

VR[досье]

Cлишком сложно показалось?

именно так =).. отпугнуло.
захожу я значит в какойто модуль!.. и что вижу.. обьявлно 109! функций ..
захожу в другой!.. о боже ещё 97!..
а зачем нужна например функция
   function getIndpEnv($getEnvName) {

  • Abstraction method which returns System Environment Variables regardless of server OS, CGI/MODULE version etc. Basically this is SERVER variables for most of them.
  • This should be used instead of getEnv()

очень хорошо придумано!.. вопервых ..
то что в php эти переменные итак доступны... это полбеды...
эти ребята придумывают функцию getEnv которая возврящает эти перменные..! =).. но спрося систему.. что именно вернуть..
потом придумывают ещё функцию которую надо использовать вместо первой.. в какихто ситуациях...когда надо получать переменные из $_SERVER
итак повсемесно!..там фактически горы мелких функций на все случаи жызни....
 те полчается не на PHP пишеш а на TYPO3 поддерживающим синтаксис ПХП


а зачем ?..вся эта городьба?..

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

технически это не сложно зато модуль на порядок упрощается...
он как обрашался к стандартным php переменным так и будет.

или вот ещё очередной ШЕДЕВР (коих там несметное количество)
функция verifyFilenameAgainstDenyPattern
функция из 3-х строк!..
да мне чем помнить эту функцию, чем вобще знать о её существоании проще написать эти 3 строки.

но самое то прикольное.. что помимо этого есть целый интерфейс для работы с файлами и почемубы этму интерфесу не проверять можноли или нельзя... работать с файлом?...
те вначале надо написать
verifyFilenameAgainstDenyPattern
а потом вызвать функцию
upload_copy_move
 и это надо опять помнить что это именно upload_copy_move а не uploadCopyMove
 ..
или вот.. функция специально для удаления временных upload файлов функция делает 4 проверки прежде чем выполнить unlink
...
это типа на всякий случай чтобы ошибка неслучилась?...
ЗАЧЕМ ЭТО НАДО.?..
это функция что специально для тех кто пишет архи кривой код кого надо 4 раза проверять?...
ну даш в unlink несуществующий файл... будет ошибка... верно?..
а тут проверка написана пред unlink ! который тоже ошибку вернет!.. =).. если файла нет...
а смысл в этом какой? функционал PHP пееписать с помошью PHP ?..

или вот ..
привожу функцию

   function tempnam($filePrefix)   {
      return tempnam(PATH_site.'typo3temp/',$filePrefix);
   }

КлаСС!.. я как такое вижу .. сразу морской болезнью страдать начинаю...
или вот

   /**
    * Make instance of class
    * Takes the class-extensions API of TYPO3 into account
    * Please USE THIS instead of the PHP "new" keyword. Eg. "$obj = new myclass;" should be "$obj = t3lib_div::makeInstance("myclass")" instead!
    *
    * Usage: 455
    *
    * @param   string      Class name to instantiate
    * @return   object      The object
    */
   function &makeInstance($className)   {
      return class_exists('ux_'.$className) ? t3lib_div::makeInstance('ux_'.$className) : new $className;
   }

больше всего порадовали камменты..

пажалуста используйти
$obj = t3lib_div::makeInstance("myclass")
вместо
$obj = new myclass;

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

а франкенштейновский "человек из кусочков"...
он какбы небыл хорош всеравно монстр.
так вот .. это TYPO3 и сеть такой монстрищще..
вобщем ужаснулся я ненашутку и для себя решил что както мышление у нас слишком разное ... воротит меня от такого подхода...

у них на сайте написано что документации уже 1600 страниц..!(у PHP столько набеется?.. или у апача?)

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

ну чтож...
раз вам нравится пользуйтесь.

спустя 1 час 26 минут [обр] lance10t[досье]

немогу удержаться...
я всетаки запостю эти 2 функции ...из TYPO3

   function ext_getCategoriesForModMenu()   {
      return $this->ext_getCategoryLabelArray();
   }
   
   function ext_makeHelpInformationForCategory($cat)   {
      return $this->ext_getTSCE_config($cat);
   }

вам не кажется что само наличие подобных функцй в системе говорит о её неправильной поректировки ..?

спустя 36 минут [обр] lance10t[досье]

а и ещё ... =)...
это я просто впервом сообщении забыл добавить...

...demonstrated TYPO3 in a lab environment some months ago. This was an evaluation of:
CMS-packages: MMBase, Microsoft CMS, Smartsite en TYPO3
Portal-packages: Luminus, Microsoft Sharepoint, Oracle, SUN en uPortal
TYPO3 was declared the cheapest to implement and the most userfriendly.

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

спустя 6 часов [обр] VR[досье]

Дык, конечно. Кто же еще тебя похвалит :-)))

Кода кривого в TYPO3 достаточно, с этим я согласен.
Но это все работает. И позволяет делать проекты типа
www.yourassist.com
И патчится нормально, если что-то нужно сделать.
1600 страниц - это вместе с эктеншенами наверное.
Сильно нужного там, ясное дело, не много.


А ты сам не догадываешься почему мамбы нет в этом списке?
Это была цитата из описания презентации системы для крупного
немецкого университета - несколько десятков редактороров, разграничение доступа,
сотни страниц. Мамба отдыхает :-)))

У меня кстати есть один сайт на мамбе.
www.edinoborstva.ru
И выбрал я ее потому же что и ты.
(быстро все можно было сделать и дизай готовый)

спустя 3 минуты [обр] VR[досье]

NNN from the Technical University of NNN and myself demonstrated TYPO3 in a lab environment some months ago. This was an evaluation of:
CMS-packages: MMBase, Microsoft CMS, Smartsite en TYPO3
Portal-packages: Luminus, Microsoft Sharepoint, Oracle, SUN en uPortal

TYPO3 was declared the cheapest to implement and the most userfriendly.
How about that as an argument! I was very proud to be there with TYPO3 among companies with a turnover of like 14 billion dollars.


Следующая такого плана цитата, как мне сказали знающие люди,
это перегиб, но все равно приведу для полноты картины:


Some days ago we held a 7h technical training, during which I demonstrated one of our latest TYPO3-customer-installations with more than 15.000 Frontend-Usern und ~900 Usergruppen. This show-off led to the fact that the listeners discarded their presumption of TYPO3 being some kind of nice-little-cms (and guided them to serious considerations to drop their Oracle-Portal ;-).

спустя 7 минут [обр] VR[досье]

Я понял!!
мы по разному подходим к оценке системы:
ты как разработчик, а я скорее как менеджер

Я код TYPO3 практически не смотрел, когда выбира
(и мне пофиг как там вызываются фунции классов :-) ):

Работает на 2300 сайтах (включая хай-енд проекты) - ОК
Ставится - OK
Есть поддержка неск. доменов в одном интерфейсе - ОК
Есть управление контентом на уровне блоков и управление картинками - ОК
Есть экстеншены с нужной функциональность - ОК
Гибкий дизайн, несколько шаблонов дизайна - ОК

спустя 10 минут [обр] VR[досье]

CMS software license prices example:
Vignette V7 € 105.000,-
Interwoven TeamSite € 85.000,-
Microsoft CMS Server € 35.000,-
IXOS-Obtree C4 € 25.000,-
Tridion R5 € 45.000,-
Sitecore Enterprise € 30.000,-
Synkron € 35.000,-
TYPO3 . € 0,-
http://www.typo-systems.com/Front_Page.38.0.html

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

спустя 12 минут [обр] Алексей В. Иванов(0/2861)[досье]
VR[досье] ха-ха-ха
спустя 1 час 11 минут [обр] Александр aka Efreeti(3/111)[досье]
Господа newcontinent[досье], VR[досье] и Алексей В. Иванов[досье].
Может мы не будем в этом треде сравнивать разные CMS или предлогать улучшить nuke, а послушаем lance10t[досье], и идеи его CMS.
Если же хочеться поспорить, заведите себе другой тред. Если лень, я могу сам создать.
спустя 2 минуты [обр] Александр aka Efreeti(3/111)[досье]
newcontinent[досье] прошу прощения, не увидел Вашей темы.
спустя 15 часов [обр] lance10t[досье]

VR[досье]

Я понял!!

алилуйа!.. =)..
я и есть разработчик =)..


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

вобщем я на грани того чтобы уже разродиться этой теплейт системой... она повидимому будет похожа... на named pipes только данными будет HTML код (я незаню как это по русски сказать named pipes ("именованные трубы"- звучит подурацки, или "именованные каналы" чтоли?))

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

те .. будет довольно прикольно...
все модули даже не подозревают что все что они output будет залито в нужном порядке в заранее заготовленную область...
при этом соврешенно неважен прядок выполнения модулей ..
можно даже вызывть один модуль изнутри другого и всервно! их echo output не перемешается и если надо, будет пущен по разным каналам.(но это все конечно настраиваемо.. если надо, то конечно перемешается их HTML код)
как наприемер при вызове модля $core['html']->метод();...
то очевидно что код вышедший из модуля[html] должен перемешаться с кодом самого вызывающего модуля. =)

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

вот например если в большинстве сайтов отключить темплейты.. то сайт просто не может работать...

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


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

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

я все свои идеи получаю обратной инженерией..

те чтобы разработать модуль темпетйов я ... для себя начинаю предствалять .. не сам модуль..
а то как я делаю темплейт..
и просто фантазирую.. вот как былобы идеально...
и потом насобирав таких мечтаний я начинаю на следующем уровне .. уже какбы работаю с тех заданием.. =).. отсекаю труднореализуемые или конфлиутующие с другими требования.

спустя 4 часа 18 минут [обр] VR[досье]
на прошлой неделе попалась новая книга Д. Котеров А. Костарев PHP5. Наиболее полное руководство.
Там есть целая глава про шаблонизатор
(честно признаюсь, не читал)
Исх. коды из книги висят здесь http://php5.dklab.ru
Может пригодиться
спустя 2 дня 20 часов [обр] lance10t[досье]

ВРЕМЕНИ МАЛО У МЕНЯ..
изложу тезисно

тема ТЕМПЛЕЙТЫ

требования
1 легкость в создании -должен требоваться минимум прогрмерских знаний.
(контр пример... смарти и темплейтер от ДК )
они слишком сложны и слишкм много на себя берут.

по моему понятию темплейт не должен вызывать компоненты.

ТЕМПЛЕЙТ - ЭТО ТРЯПОЧКА.
и ядро само её правильно приложет и раскроит.
 и никаких

{t_component src="Test_Date" name="date" format="Y-m-d"}
   {$date}
{/t_component}

это слишком сложное програмирования., это - слишком много власти темплейту.

требование 2.
совместимость с HTML
СМАРТИ СО СВОИМИ {} не совместим!..
а вот темплейтер насколько я понял да.

требование 3
интреграция функции превода (ну чтобы в темплейте написать прямо в HTML )
например так...

<td>Login</td><td><input... ...></td>
а потом это 'Login' без проблем это поддалосьбы прееводу!.. БЕЗ ПРОБЛЕМ...
заменялось бы на русское "Логин"

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

требование 5
удобно должно быть на не через.. }|{ как это часто бывает.


решение.( обратите внимание !.. у меня нет просто время подробно расписывать, я просто лиш показываюь суть подхода)

придумано после 4-х дней раздумий.

называется это Embedded Template (ET)
почему ?.. потмоу что у этой системы разметки темплейта нет собственного носителя..!!!
разметка паразитирует на действующих HTML тегах.
те разметка распологается не внутри собсвенных {} или []... или даже собственных тегов а-ля ..<datasource>

это сделано для удобства и упрощения создания темплейта из обычной HTML странички.

теплейт создается вначале человеком. как просто HTML страница...
затем она прекомпелируется движком темплейтов в очень быстрый php файл в котором разметка превращается в комманды и управляющие структуры php

который и будет использоваться при реальной работе.

принцип работы иллюстрирует следующий пример.

<TABLE WIDTH="700" BORDER="0" CELLSPACING="0" CELLPADDING="0">
 <TR if='showtitle'>
  <TD>&nbsp;</TD>
  <TD>&nbsp;</TD>
  <TD>&nbsp;</TD>
 </TR>
 <TR repeat='news'>
  <TD display='title'>заголовок по умолчанию</TD>
  <TD display='intro'>&nbsp;</TD>
  <TD if='readmore' display='readmore' >&nbsp;</TD>
 </TR>
 <TR>
  <TD trans='prew'>PREW</TD>
  <TD trans='top'>TOP</TD>
  <TD trans='next'>NEXT page</TD>
 </TR>
</TABLE>

поясняю смысл.

комманда
(if='showtitle')

  1. самый превый TR будет выведен .. только если темплейт запустется в среде где будет существовать(!=false) переменная.. showtitle

команда
(repeat='news')
второй TR
будет повторен стольук раз - какова длинна масива news
из элементов которго будут подставляться title и intro

команда.
(display='title')
 если в массиве $news[$i][title] будет неопределно то останется "заголовок по умолчанию"

далее
комбинированная команда
(if='readmore' display='readmore')
значит что ячейка readmore будет выведена только тогда когда есть чем её наполнять.

директива
(trans='prew')
говорит что надобы поискать локализованное значение 'prew' и положить его в ечейку вместо того .. что там поумлочанию...


по проще говоря надо отмечать trans'ом .. все что надобы перевести в будущем...
всякие словечки ... типа ... "добавить сообщение" итп...

во время создания скомпелированного php файла.. движок помимо самого файла создает

  1. схему документа.(для прогрмаера)

чтоб он без труда потмо сделал подключения (bindings)

пример сгенерированной схемы

// $showtitle // - ifFlag
//
// $news //array -repeat
// $news[$i]['title'] // display
// $news[$i]['intro'] // display
// $news[$i]['readmore'] - ifFlag & display
// end $news repeat

нечто одобное по смыслу создается и для переводчиков..
где будут все фразы котроые надо прееводить..
ну внеше бужет похоже на..

next 'NEXT page'.
и тепреь если тут(в файле прееводов) заменить то на сайте торже изменится..!..
но если удалить.. то на сайте останится прежнее.. "NEXT page" (введенное в html)

попмимо этого темплейт поддерживает перенаправалени работы модулй в указанные зоны.
(без играния с присвоением переменных)

спустя 2 часа 5 минут [обр] Алексей Севрюков(2/1280)[досье]
  1. Я хочу вывести несколько значение в ячейку, как?
  2. На мой взгляд - эти темплейты будет очень сложно поддерживать.
спустя 3 часа 9 минут [обр] lance10t[досье]

Алексей Севрюков[досье]

если есть темплейт <td display='myvalue'>deafult!</td>

то подстановка значения $myvalue='NEW value';
после вызова темплейта результат(в браузере) <td>NEW value</td>

слжно?.. а что именно сложно?.

спустя 47 минут [обр] Алексей Севрюков(2/1280)[досье]

lance10t[досье] Несколько значений, а у вас одно. А я хочу дату, название например.
Это будет что-то типа:

display="date title"

?

спустя 8 часов [обр] Александр aka Efreeti(3/111)[досье]
Алексей Севрюков[досье]
скорее
<td display='more'>
    <span display='date'>01-01-05</span>
    <span display='title'>def</span>
</td>
спустя 3 часа 59 минут [обр] lance10t[досье]

Александр aka Efreeti[досье]

<td display='more'>
    <span display='date'>01-01-05</span>
    <span display='title'>def</span>
</td>

(display='more') ненадо!. там может быть умесно (if='showtitle')
в вашем варианте стоит только определить в программе пременную $more то оба спана будут перзаписаны!.

а так есть 2 варианта..
1-й правильный. это почти как сказал Александр aka Efreeti[досье]

<td>
    <span display='date'>01-01-05</span>
    <span display='title'>def</span>
</td>

правильный !. потму что логически разные элементы получааются в разных тегах и могут быть обработаны CSS пооддельности .. что есть хороший тон!. и почти наверняка вам так и понадобится разные данные разукрашивать поразному или както выделять... (если у вас будет такойже дизанер как тот с которым я работаю =).. )

второй вариант
неправильный.
это присвоиить одной переменной нужную строчку ... в иллюстрациях не нуждается.

Алексей Севрюков[досье]
понимаете ..я бы мог сделать такой механизм как вы говорите...
типа "display="date title"" но не буду потому что 90% всего что я видел в сайтах выводится в разные ечейки .. потому что так просто удобнее работать...
 
я делаю не супер систему!..
а просто решаю реальные проблемы. (только реальные)
и .. создавать код на всякие редкие случаи .. который в моей практике почти не встречаютя .. я пока не собираюсь... (это просто нерационально)

спустя 9 часов [обр] Hairy[досье]
lance10t[досье]
По поводу многоязычности:
  1. Переводу подлежат картинки т.е. должен менятся атрибут src
  2. Переводу подлежат куски css т.е. css файл должен так-же генерится при помощи шаблонов.
спустя 37 минут [обр] lance10t[досье]
Hairy[досье]
спасибо что напомнили!... а то я както упустил это из виду..
... не только src но и alt .
вобщем .. перевод картинки будет отмечаться так.
<img src='original/path/image.jpg' trans='go_button' >
ну и css также ..
спустя 4 часа 46 минут [обр] Александр aka Efreeti(3/111)[досье]
lance10t[досье] Кстати, а эти преобразования ( из repeat, display и т.д.) происходят каждый раз при запросе, или вы их каким-то образом "компилируете"?
спустя 8 часов [обр] lance10t[досье]
Александр aka Efreeti[досье]
цитирую сам себя.

теплейт создается вначале человеком. как просто HTML страница...
затем она прекомпелируется движком темплейтов в очень быстрый php файл в котором разметка превращается в комманды и управляющие структуры php

который и будет использоваться при реальной работе

спустя 48 минут [обр] Александр aka Efreeti(3/111)[досье]
lance10t[досье] Прошу прощения, пропустил.
спустя 7 часов [обр] Hairy[досье]

lance10t[досье]
Теперь такой вопрос, точнее тема для размышления (обсуждения) , допустим есть у нас какой-то смысловой блок страницы что нам требуется для его написания

  1. Файл задающий структуру (SQL,XML, ... )
  2. PHP код экспортирующий значения
  3. Шаблон HTML для отображения блока
  4. Шаблон CSS для стилей
  5. Шаблон JScript для (допустим в этом блоке есть кнопочки для popups)
  6. Файл с переводами
  7. ... ?

итого: 6 файлов (или кусков фалов) скорее всего лежащих в разных каталогах и которые нужно (добавить/изменить) для написания одного(каждого) блока страницы.
Сам вопрос: "Будет-ли это удобно для разработчика сайтов?"

спустя 3 часа 9 минут [обр] Алексей Севрюков(2/1280)[досье]
Hairy[досье] Будет. А Вы за то, чтобы все было в одном файле? Сам шаблон уже подразумевает подключение отдельных блоков, иначе весь смысл и вся прелесть теряется.
спустя 27 минут [обр] Hairy[досье]
Алексей Севрюков[досье]
Я вот и хочу подумать какие могут быть варианты, поскольку редактировать 6 файлов
одновременно, лично мне неудобно и слишком медленно.
Насчёт "всё в одном файле" - это худший вариант, помойму база гораздо лучше.
спустя 1 час 57 минут [обр] Алексей Севрюков(2/1280)[досье]
Hairy[досье] А если у Вас нет базы и шаблоны ее не используют? Зачем она тогда нужна? И кто сказал что поправить 6 файлов сложнее, чем 6 записей в базе. Причем в первом случае можно править напряму, во втором придется делать какой-нибудь интерфейс, что опять же неудобно.
спустя 49 минут [обр] Hairy[досье]

Алексей Севрюков[досье]
Ни кто не говорит о том, что на сайте обязательно должана быть база,
она может быть и у разработчика.

К 6 записям в базе можно нарисовать удобный интерфейс, в этом и смысл.

P.s. Интерфейс всегда есть (FAR тоже интерфейс и даже MC интерфейс),
вопрос лишь в том насколько он подходит для таких задач, не смотря
на всю его привычность.

спустя 40 минут [обр] Gansik[досье]

Решил и я подключиться к обсуждению...

Думаю что для полной совместимости темплитов c HTML (точнее с XML и XHTML) необходимо использовать namespace для нестандартных атрибутов. Во первых это не сложно сделать. Во вторых так более правильно по стандартам. В третьих если когда нить потребуеться программная обработка таких темплитов (XSLT, WYSIWYG редактор, ...) то с namespace это будет проще делать.

Соответсвенно темплит будет выглядеть так:

<div MyNS:repeater="news">
   <span MyNS:display='date'>01-01-05</span>
   <span MyNS:display='title'>def</span>
</div>

Я уже заметил что уважаемый Ланцелот в своих размышлениях плавно
движется в сторону технологии ASP.NET ;)
Отсюда такие вопросы (предложения):

  1. Предложеная система темплитов решает проблему подстановки содержимого тегов, а как быть с атрибутами тегов?
  2. Я не знаю как вы планируете сделать "компиляцию" темплитов во внутрений формат, но хочу вам предложить почитать описание такой фишки в ASP.NET как "компиляция по требованию".
  3. По поводу локализаций темплитов. Думаю раз уж вы решили темплиты компилировать во внутрений формат может нету вообще смысла в написании атрибута "trans" везде в темплите? Можно же просто найти все строки в темплите, и вместо них (в скомпилированом варианте темплита) написать что то типа <span><?php = trans("Last Name:") ?></span>. Найдет функция перевод фразы "Last Name"- хорошо, не найдет- отдаст то же что и получила на вход.

Пока все. С большим интересом наблюдаю за этой темой.

спустя 26 минут [обр] Gansik[досье]
IMHO, CSS вообще не надо переводить и как- то с этим заморачиваться. Да, там могут быть background-image, которые по хорошему надо бы иметь возможность менять для разных языков. Но мне кажется накладные расходы связаные с тем что CSS будет генерироваться из PHP большая проблема, чем проблема создания необходимого набора CSS файлов для разных языков.
Скажу больше, в тех верстках что я делаю в последнее время у меня на страничке вообще из всех картинок указаных через IMG присутсвует только логотип. Все остальное либо в CSS вынесено, либо из базы берется, т.е. SRC картинок переводить не нужно (по крайней мере для моих проектов).
Все это конечно спорно, но идею Ланцелота, по поводу написания движка "под себя", я полностью подерживаю. Были попытки написания универсальных, все могущих CMS, всегда результат один- сложная и непонятная система :(
спустя 44 минуты [обр] Gansik[досье]

Ну и последнее мое сообщение на сегодня ;)
Я бы в качестве протокола удаленых вызовов рекомендовал использование SOAP вместо XML-RPC. Причина дурацкая, именно SOAP Microsoft "любит". .NET- клиенты будет проще писать.
Есть и библиотечки этот SOAP реализовующие в PHP, например http://dietrich.ganx4.com/nusoap/.

Мне кажеться что в качестве клиента, выполняющегося на машине менеджера сайта, незаслужено не упомянута технология XUL от Mozzila. Для вебмастеров эта технология должна быть ближе (ну хотя бы теоретически) чем Delphi или вообще (о ужас!) c++ ;)

Я даже мог бы потом попытаться написать клиента на XUL для движка, так мне эта технология нравится :)

спустя 3 дня [обр] lance10t[досье]

Hairy[досье]

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

  1. Файл задающий структуру (SQL,XML, ... )
  2. PHP код экспортирующий значения
  3. Шаблон HTML для отображения блока
  4. Шаблон CSS для стилей
  5. Шаблон JScript для (допустим в этом блоке есть кнопочки для popups)
  6. Файл с переводами
  7. ... ?

Сам вопрос: "Будет-ли это удобно для разработчика сайтов?"


ну вопервых мне не совсем понятно.. что это за файл?...
из пункта 1.. вродебы такого нет.

  1. ну это и есть сам рабочий скрипт.. ну.. те например..

прямо в коде гостевой книги.. и происходят
присвоения.
(этот пример пример сгенерированной схемы

// $showtitle // - ifFlag
//
// $news //array -repeat
// $news[$i]['title'] // display
// $news[$i]['intro'] // display
// $news[$i]['readmore'] - ifFlag & display
// end $news repeat
)
это и нужно копипастнуть в сам код программы...
эта схема сделана с одной только целью чтобы пограмер не лазил в
темплейт чтобы посмотреть какие ему нужны значения.

файлы 3,4,5 - в одной папке.. (относяшейся к темплейту)... тамже и
будет файл перевда.
но наличие этого файла вовсе не обязательно ..
и вобще програмеру незачем лазить в этот файл.

так что не вижу приципиальных проблем с редактированием.


вопрос про хранение таких файлов в базе.. я закрыл ещё вначале.

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

да и вобще... ну ..редактировать темплейт например удобнее всего в
специальном редакрторе.. типа dreamweaver...
css тоже в редакторе.. topStyle... ну так само собой напрашивается
решение хранить в файлах.
вобщем это более естественный способ.

Gansik[досье]

Думаю что для полной совместимости темплитов c HTML (точнее с XML и
XHTML) необходимо использовать namespace для нестандартных атрибутов.
Во первых это не сложно сделать.

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

# Предложеная система темплитов решает проблему подстановки
содержимого тегов, а как быть с атрибутами тегов?

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

да и вобще.. допишу такую фишку (это не слишком сложно)

вот обрашаясь к нашему примеру
<div repeat="news">
 <span display='date'>01-01-05</span>
 <span display='title'>def</span>
</div>

предположим надо сделать "зебру" с помощю css
и при этом надо ещё и выделеть важную новость (опять css'ом) например
в title добавить ещё один css селектор.

делаться это будет так..
// эта строчка в цикле сделает зебру.
if ($i % 2) $news[$i][attrib][class]=' odd_row';

а выделение например title новости $i
$news[$i][title][attrib][class]=$news[title][attrib][class].' mega_cool_new';

"$news[title][attrib][class]" это обращение к уже введенному атрибуту
'class' которое будет вытащено из html'a

при этом не надо исправлять темплейт !
и можно будет устрнавливать(и добавлять) любые атрибуты (у отмеченных
display тегов).
можно и считывть значения атрибутов.

Я не знаю как вы планируете сделать "компиляцию" темплитов во
внутрений формат, но хочу вам предложить почитать описание такой фишки
в ASP.NET как "компиляция по требованию".

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

По поводу локализаций темплитов. Думаю раз уж вы решили темплиты
компилировать во внутрений формат может нету вообще смысла в написании
атрибута "trans" везде в темплите?

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

IMHO, CSS вообще не надо переводить и как- то с этим заморачиваться.
Да, там могут быть background-image, которые по хорошему надо бы иметь
возможность менять для разных языков. Но мне кажется накладные расходы
связаные с тем что CSS будет генерироваться из PHP большая проблема,
чем проблема создания необходимого набора CSS файлов для разных
языков.

о генерации CSS небыло и речи... я имел ввиду только генерацию тега <link>

С большим интересом наблюдаю за этой темой.

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

Я бы в качестве протокола удаленых вызовов рекомендовал использование
SOAP вместо XML-RPC. Причина дурацкая, именно SOAP Microsoft "любит".
.NET- клиенты будет проще писать.

ну.. я видел XML-RPC для .NET... разве этого недостаточно?... ИМХО
SOAP слишком сложный для такого уровня проблем и XML-RPC прекрасно справится с задачей...
и не забывайте что PHP дружит с XML-RPC и XML-RPC обычно поумолчанию включен в большинстве хостингов...

Мне кажеться что в качестве клиента, выполняющегося на машине
менеджера сайта, незаслужено не упомянута технология XUL от Mozzila.
Для вебмастеров эта технология должна быть ближе (ну хотя бы
теоретически) чем Delphi или вообще (о ужас!) c++ ;)

а я даже и не подразумевал что комуто придется лезть в код клиента...
те.. клиент он в первую очередь будет представлять конфигурационную утилиту для работы с конфиг файлом.
и только как его второстепенная функция будет работа с компонентами сайта..
те например добавление новых товаров в магазиy или новых статей...

да конечно xul хорош... очень хорош...
но я хотелбы "срезать путь" ... и сделать чтото типа своей убогой версии ксула..
которая будет именно заточена по своим функциям на работу с этой CMS ...
ну те моя версия она будет не такая функциональная.. как ксул..
но зато она будет напрямую работать с серверным php и сила её будет в простоте..

будет чтото вроде такого ... (я ещё не размышлял на этим ... )этопросто так...общая идея..
пишешь..
<button 'PRESS ME'>
$core['my_module']->CallMe();
<button>
и на интерфесе появится кнопочка PRESS ME которая вызывает $core['my_module']->CallMe(); прямо на сервере..

хотя ... хотя.. я пока незнаю ещё все настолько сырое... в плане этого клиента что я могу ещё 20 раз поменять мнение на то как и что он будет из себя предствлять...

PS.... у меня сейчас вышла звдержка в разработке от того что я нашел логическую ошибку ядра и исправляю её...

ошибка... появилась от того что я хотел обойти дурацкое ограничение nuke подобных систем где... на одной страничке может быть вызван только один большой компонент..
ну например... в большинстве CMS можно указать что на такойто сраница- пусть загрузится... ну например... галерея... и все!.. или .. один интренет магазин... или чтото такое большое НО ОБЯЗАТЕЛЬНО В ОДНОМ ЭКЗЕМПЛЯРЕ.

и больше на эту страницу ничего не запихать... а это глупо ...
бывает надо несколько независимых компонент прогрузить в одну страничку..
и нынешнее ядро это прекрасно поддерживает... можно грузить хоть 10 РАЗНЫХ большх компонент с кучей разных параметорв для каждого из них...

но вот что я упустил...
нет возможности никак запустить один и тотже компонент несколько раз... НО в разной среде...
те .. понимете в чем проблема то?!!... вот например .. если вызывается модуль например CONTENT который выводит статью определенную...
вот во всех ситемах (и в этой тоже) нельзя вызвать его ещё 3 раза.. но с новыми параметрами ... на тойже самой страничке...
а вот если например надо 2 голосовалки?... а если надо 2 разные статьи...??... 3 разных меню?... 6 разных баннеров?
выходит что надо обязательно иметь возможность в одной ссыке-локации запустить один и тотже модуль по нескольку раз., да так чтобы он и не знал что он был уже запущен...
это настолько упростит создание компонент!.. особенно меню!..
придется написать всего один простенький модулик...
а ядро уж будет его по 3 раза врететь в разных вариантах...
но скоро я это исправлю... и тогда будет маленькая опреационная система =))).. для модулей...

спустя 1 час 6 минут [обр] Алексей Севрюков(2/1280)[досье]
ну так и предпологалось что при вызове темплейта перый if будет проверять есть ли файл..
и если его нет то он будет скомпелирован
А если Вы замнеили темплейт? То показываться будет старая версия из скомпилированой. А посему проверять надо не только на существование, а еще и вычислять не менялся ли файл исходника (по дате изменения).
спустя 5 часов [обр] lance10t[досье]
Алексей Севрюков[досье]
ну ... это ессесно что надо так... я просто не написал.
тамже даже файл конфигурации точно также сделан...
те сейчас работает так...
что если файл конфигураци не изменился то ядро подгружает уже скомпелированный конфиг напрямую как масив...
а если изменился то включает парсерилка которая расшифрует этот человеческий конфиг и сделает "быструю версию".
спустя 9 дней [обр] lance10t[досье]

приветствую всех!..
спешу напомнить что я не пропал и не пропаду с форума заране об этом не обьявив. =).
вобщем сейчас немного отпустили меня бытовые передряги.
и есть время отписать в форум.
итак.. за это время я сделал немного... но всеже чтото продвинулось.
ну вопревых.
появилась поддержка альясов как в апаче вродебы ..
также как и в апаче появились "хендлеры файлов"...
поясню что это значит в ROS ... а да кстати .. система называется и будет называться ROS (это сокращение)
так вот ...

"хендлеры файлов"
как они работают...
предположим есть локация с какимито модулями и настройками
например ...
/test/docs/mod/core.html

что позволяют выворять "расширения" ...
можно написать этотже урл но вот так.. (без "l")
/test/docs/mod/core.htm
и это выведет этуже страничку адаптированную для принтера
/test/docs/mod/core.txt
текстовую версию..
/test/docs/mod/core.src
выведит html сорс =)... для отладки удобно чтобы блокнот не запускать.
/test/docs/mod/core.prof
добавит в страничку данные профайлера о работе
/test/docs/mod/core.dbg
дебагную информацию.. =)..
вобщем применения у этого механизма - куча...
и все очено удобно выходит...
вот нарпимер как выглядет модуль для вывода сорса html на расширенеие .src
php файл модуля

class viewsource extends module{
   function viewsource ($instanceName) 
   {                                 
        $this->_name=$instanceName; 
   $this->cover_all('display_source','viewsource');
   }
   function display_source($output) 
   {
   return nl2br(htmlentities($output));
   }

}

ini файл этого модуля

extensions .src   // register ".src" extension othervise it will jam location.

<location '*.src'>      
// all src file will be handled by that module 
           +LoadModule viewsource
</location>

вот собсно и все...

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

при этом пришлось реализовать 2 разных метода повторонй загрузки...

  1. метод... это когда на каждую загрузку модуля создается совершенно новй экземпляр обьекта модуля...

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

2 второй метод .. это загрузка в "shared memory" =)... ну те это эмуляция такая обьект модуля как был один так и остается один просто инициализируется и исполняется ОДИН И ТОТЖЕ ОБЬЕКТ несколько раз ... в разной среде.
это нужно например ... когда на сайте например 3 меню ... (такое бывает)...
так вот совершенно нет необходимости создавать 3 экземпляра обькта меню...
достаточно один и тотже экземпляр проинициализировать 3 раза.. но в разной среде.. =). тогда создасться видимость работы 3-х разных модулей.. =).. а память и время экономится.

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

за исключением того что пришлось обходить убогость php который при создании обьекта не вызывает конструктор предка этого обькта..
поэтому тепреь любой модуль котороый хочет правильно поддерживать многоразовую загрузку.. должен содержать в начале одну строку...
$this->_name=$instanceName;
эхх... пришлось ити на такие меры..

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

спустя 8 минут [обр] lance10t[досье]

а вот .. ещё забыл добавить...
также появилась поддержка виртуальных корней... (virtual root)
работает это примерно так...

вот например есть сайт с древовидной структурой.. папок и документов..

и в сайте есть /test/docs/mod/core.html
теперь ... если зарегистрировать виртуальный корень .. virtualrootexample
то к этому самому документу можно обратится
/virtualrootexample/test/docs/mod/core.html
но с какимито изменеными настрйками... специфичными именно для virtualrootexample

ну... применение у этого механизма - например разные версии сайта.. поддерживать..
например в виртуальном корне ru - русский в en - английский
а .. дерево документов реально только одно!..

спустя 17 дней [обр] lance10t[досье]

вот я и вернулся..
жызь у меня тяжелая.. и реально заниматься системой получается вечерами и по выходным..
но вот наконецто я сделал первую часть движка темплейтов.
итак...
поскольку на xpoint нет подсветки синтаксиса то я выложу большую часть кода в отдельном файле.

http://apps.webtrox.com/ryo-ohki/templates.html

итак.. по порядку..

  1. для примера есть HTML темплейт.
 1sdadas
<B> 2asdasd</B>
3asdasdasd
4asdasdasd

<TABLE WIDTH="700" BORDER="1" CELLSPACING="0" CELLPADDING="0" IF='showtable'if='readmore' repeat='posts'>
<TR if='showtitle' sad='qwe'>
  <TD>&nbsp;!!!asddd</TD>
  <TD>&nbsp;safaf</TD>
  <TD>123&nbsp;</TD>
</TR>
  <TR repeat='news' WIDTH="123" HEIGHT="123" ALT="Test--!!!...!!!///"  >
      <TD display='title'>&&#247&&&&#240&&&&#243&&&&#254&&&&#251&&&&#254&&&&#242&&&&#254&&&&#250&& &&#255&&&&#254&& &&#186&&&&#252&&&&#254&&&&#251&&&&#162&&&&#240&&&&#253&&&&#248&&¦</TD>
      <TD display='intro' if='displayintro' CLASS="intro">&nbsp;</TD>
      <TD if='readmore' display='readmore' CLASS="readmore">&nbsp;</TD>
      <TD if='related' display= 'related'  repeat  =  'related'   CLASS="related" test>&nbsp;dddddd</TD>
  </TR>
   <TR>
     <TD trans='prew'>PREW</TD>
     <TD trans='top'>TOP</TD>
     <TD trans='next'>NEXT page</TD>
</TR>
</TABLE>
asdasdasd
<!-- 22 -->
<DIV    ALIGN="center" repeat='whatever'        display='whatever' CLASS="classtest" ID="the_ID">asdf</DIV>
<!-- 22 -->
<DIV ALIGN="center" repeat='whatever' display='whatever2'            ></DIV>

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

чтобы была понятна суть вкратце опишу некоторые директивы.

  1. у таблицы IF='showtable'if='readmore' repeat='posts'

это значит что если есть showtable и readmore то надо повтарять таблицу и наполнять её данными из масива posts

  1. у TR repeat='news' это под массив... те он целиком содержится внутри каждого элемента масива posts
  2. у TD if='related' display='related' repeat='related' директивы говорят что "если есть related то надо повторять и показать все related"

теперь...
привожу пример использования этого темплейта изнутри.

$template=$core['templates']->select('content'); // выбрали темплейт. 
/*
именно во время выбора происходит поиск запрашиваемого темплейта
1. в виртуальной файловой системе модуля... (да у каждого модуля свое дисковое пространство внутри которого он может делать файловые операции)
2. в реальной папке темплейтов модуля
3. в глобальной папке темплейтов сайта

если есть ресурсный файл то он будет загружен.
если файла нет или темплейт изменен то темплейт компелируестя

но в конце полюбому возвращается ресурсный массив... 
в данном случае это $template
*/
                                             
$template["posts"][0]["news"][0]["readmore"]["HTML"]=$core['html']->table($table,'test_table',$t); // init expected array 
// в этой строке происходит наполение содержимым (например тут вставляется некая таблица)


$core['templates']->render($template);
// вот и последняя команда.. которая выводит... результат.

....
теперь обратимся к ресурсному файлу.

<?
/*
   WARNING: DO NOT EDIT THIS FILE
   COUSE
   1. it will be overwritten during next template regeneration.
   2. that file was not designed for human meddling.  
   NOTE: edit HTML template instead
*/

/*
   WARNING: use $rc["_tplpath"], but do not rely on it like on static path,
   it will be dynamically rewritten during template loading.
   it can be altered in case of using MediaServer and different protocols.
   EXAMPLE:
   after calling ->select("template");
   "_tplpath" may be changed from "mod/content/templates/content/"
   to something like "http://img.example.com/media/mod/content/templates/content/"
*/
$rc["_tplpath"]="mod/content/templates/content/";
$rc["name__"]="content";
$rc["timestamp__"]=1108908055;


// default "if" switch for each $rc["readmore"] for tag TABLE
$rc["readmore"]="";
// default "if" switch for each $rc["showtable"] for tag TABLE
$rc["showtable"]="";

// array [posts] to repeat and show in tag TABLE
// default "if" switch for each $rc["posts"][$i]["showtitle"] for tag TR
$rc["_posts"]["showtitle"]="";

// array [news] to repeat and show in tag TR
// default "if" switch for each $rc["posts"][$i]["news"][$i]["displayintro"] for tag TD
$rc["_posts"]["_news"]["displayintro"]="";
// [title] default attributes for tag TD, to set inner HTML use $rc["posts"][$i]["news"][$i]["title"]["HTML"]
$rc["posts"][0]["news"][0]["title"][0]=""; // init expected array
$rc["_posts"]["_news"]["title"][0]=""; // init expected attributes array

// [intro] default attributes for tag TD, to set inner HTML use $rc["posts"][$i]["news"][$i]["intro"]["HTML"]
$rc["posts"][0]["news"][0]["intro"][0]=""; // init expected array
$rc["_posts"]["_news"]["intro"]["class"]="intro";

// array $rc["posts"][$i]["news"][$i]["readmore"] is switch for showing for tag TD
// [readmore] default attributes for tag TD, to set inner HTML use $rc["posts"][$i]["news"][$i]["readmore"]["HTML"]
$rc["posts"][0]["news"][0]["readmore"][0]=""; // init expected array
$rc["_posts"]["_news"]["readmore"]["class"]="readmore";


// array [related] to repeat and show in tag TD
// array $rc["posts"][$i]["news"][$i]["related"] is switch for showing for tag TD
// [related] default attributes for tag TD, to set inner HTML use $rc["posts"][$i]["news"][$i]["related"][$i]["related"]["HTML"]
$rc["posts"][0]["news"][0]["related"][0]["related"][0]=""; // init expected array
$rc["_posts"]["_news"]["_related"]["class"]="related";
$rc["_posts"]["_news"]["_related"]["test"]="test";


// array [whatever] to repeat and show in tag DIV
// [whatever] default attributes for tag DIV, to set inner HTML use $rc["whatever"][$i]["whatever"]["HTML"]
$rc["whatever"][0]["whatever"][0]=""; // init expected array
$rc["_whatever"]["align"]="center";
$rc["_whatever"]["class"]="classtest";
$rc["_whatever"]["id"]="the_ID";


// array [whatever] to repeat and show in tag DIV
// [whatever2] default attributes for tag DIV, to set inner HTML use $rc["whatever"][$i]["whatever2"]["HTML"]
$rc["whatever"][0]["whatever2"][0]=""; // init expected array
$rc["_whatever"]["align"]="center";
return $rc;
?>

этот файл создается полностью автоматически..
и предназначен для 2-х целей..

  1. инициализация темплейта
  2. предоставить програмисту понятную заготовку для рабоьты с темплейтом...

для этого там комментарии и пишутся.

вот например оттуда можно просто сроки копировать и после мелких исправлений все работает
$rc["whatever"][$i]["whatever"]["HTML"]
заменили на
$template["whatever"][0]["whatever"]["HTML"] ="HELLO TREMPLATE";
вот и все... нулевое значение присвоено..
а если надо поставит например class этому элементу
то надо написать
$template["whatever"][0]["whatever"]["class"]="css_class";

а вот таким способом устанавливается заначение по умолчанию
$rc["_posts"]["_news"]["_related"]["class"]="related"; для каждого элемента массива $rc["posts"][$i]["news"][$i]["related"][$i]

ну ... и а что говорить про скомпелированный файл?..

      <b> 2asdasd</b> 
<? if ($rc["showtable"]||$rc["readmore"]) { foreach ($rc["posts"] as $posts_key => $posts_item) if ($posts_item) { ?><table width="700" border="1"> 
<? if ((!isset($posts_item["showtitle"]) && $rc["_posts"]["showtitle"])||(isset($posts_item["showtitle"])&&$posts_item["showtitle"])) { ?><tr sad="qwe"> 
  <td>&nbsp;!!!asddd</td> 
  <td>&nbsp;safaf</td> 
  <td>123&nbsp;</td> 
</tr><? } ?> 
<? foreach ($posts_item["news"] as $news_key => $news_item) if ($news_item) { ?><tr width="123" height="123" alt="Test--!!!...!!!///"> 
  <td<? foreach ($rc["_posts"]["_news"]["title"] as $key => $value) if ($key!="HTML"&&!isset($news_item["title"][$key])) echo " ".$key."=\"".$value."\""; foreach ($news_item["title"] as $key => $value) if ($key!="HTML") echo " ".$key."=\"".$value."\""; ?>><? if(isset($news_item["title"]["HTML"])) echo $news_item["title"]["HTML"]; else { ?>чруюыютюъ яю єьюыўрэш¦<? } ?></td> 
  <? if ((!isset($news_item["displayintro"]) && $rc["_posts"]["_news"]["displayintro"])||(isset($news_item["displayintro"])&&$news_item["displayintro"])) { ?><td<? foreach ($rc["_posts"]["_news"]["intro"] as $key => $value) if ($key!="HTML"&&!isset($news_item["intro"][$key])) echo " ".$key."=\"".$value."\""; foreach ($news_item["intro"] as $key => $value) if ($key!="HTML") echo " ".$key."=\"".$value."\""; ?>><? if(isset($news_item["intro"]["HTML"])) echo $news_item["intro"]["HTML"]; else { ?>&nbsp;<? } ?></td><? } ?> 
  <? if ((isset($news_item["readmore"]) && $rc["_posts"]["_news"]["readmore"])||$news_item["readmore"]) { ?><td<? foreach ($rc["_posts"]["_news"]["readmore"] as $key => $value) if ($key!="HTML"&&!isset($news_item["readmore"][$key])) echo " ".$key."=\"".$value."\""; foreach ($news_item["readmore"] as $key => $value) if ($key!="HTML") echo " ".$key."=\"".$value."\""; ?>><? if(isset($news_item["readmore"]["HTML"])) echo $news_item["readmore"]["HTML"]; else { ?>&nbsp;<? } ?></td><? } ?> 
  <? if ((isset($news_item["related"]) && $rc["_posts"]["_news"]["related"])||$news_item["related"]) { foreach ($news_item["related"] as $related_key => $related_item) if ($related_item) { ?><td<? foreach ($rc["_posts"]["_news"]["_related"] as $key => $value) if ($key!="HTML"&&!isset($related_item["related"][$key])) echo " ".$key."=\"".$value."\""; foreach ($related_item["related"] as $key => $value) if ($key!="HTML") echo " ".$key."=\"".$value."\""; ?>><? if(isset($related_item["related"]["HTML"])) echo $related_item["related"]["HTML"]; else { ?>&nbsp;dddddd<? } ?></td><? } } ?> 
</tr><? } ?> 
<tr> 
  <td><? if (isset($tr["prew"])) echo $tr["prew"]; else { ?>PREW<? } ?></td> 
  <td><? if (isset($tr["top"])) echo $tr["top"]; else { ?>TOP<? } ?></td> 
  <td><? if (isset($tr["next"])) echo $tr["next"]; else { ?>NEXT page<? } ?></td> 
</tr> 
</table><? } } ?> 
<? foreach ($rc["whatever"] as $whatever_key => $whatever_item) if ($whatever_item) { ?><div<? foreach ($rc["_whatever"] as $key => $value) if ($key!="HTML"&&!isset($whatever_item["whatever"][$key])) echo " ".$key."=\"".$value."\""; foreach ($whatever_item["whatever"] as $key => $value) if ($key!="HTML") echo " ".$key."=\"".$value."\""; ?>><? if(isset($whatever_item["whatever"]["HTML"])) echo $whatever_item["whatever"]["HTML"]; else { ?>asdf<? } ?></div><? } ?> 
<? foreach ($rc["whatever"] as $whatever_key => $whatever_item) if ($whatever_item) { ?><div<? foreach ($rc["_whatever"] as $key => $value) if ($key!="HTML"&&!isset($whatever_item["whatever2"][$key])) echo " ".$key."=\"".$value."\""; foreach ($whatever_item["whatever2"] as $key => $value) if ($key!="HTML") echo " ".$key."=\"".$value."\""; ?>><? if(isset($whatever_item["whatever2"]["HTML"])) echo $whatever_item["whatever2"]["HTML"]; ?></div><? } ?>

ну надеюсь он будет очень быстрый потому что там происходит прямая генерация HTML с помошью исключительно родных для PHP инструкций..
там только IF, FOREACH, ECHO, ISSET и все.... также это вынесено в отдельный файл...
и значит что ZEND optimizer не будет связан внешними вызовами и очень очень хорошо оптимизирует этот файл.
возможно с максимальной эффективностью.

во время компиляции темплейта не порисходит банального поиска и замены директив... на php вставки..
просиходит полная разборка и анализ структуры HTML и пересборка его в 100% xml или XHTML
у картинок и прочих ресурсов появляются динамические урлы.
есть ещё переводы.., ещё всякие приятные но несущественные мелочи.

вобщем темплейт генерирует отформатированный XML. (да я читал спецификации)
и поэтому <HR noshade> превращается в <hr noshade="noshade" />

<table width="700" border="1"> 
 <tr sad="qwe"> 
  <td>&nbsp;!!!asddd</td> 
  <td>&nbsp;safaf</td> 
  <td>123&nbsp;</td> 
 </tr> 
 <tr width="123" height="123" alt="Test--!!!...!!!///"> 
  <td>чруюыютюъ яю єьюыўрэш¦</td> 
  <td class="intro">&nbsp;</td> 
  <td class="readmore"></td> 
  <td class="related" test="test">&nbsp;dddddd</td> 
 </tr> 
 <tr> 
  <td>PREW</td> 
  <td>TOP</td> 
  <td>NEXT page</td> 
 </tr> 
</table>

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

а.. и ешё один забавный момент...
промните...
$core['templates']->render($template);
// вот и последняя команда.. которая выводит... результат.
вот исходный код этой функции

function render($rc)
{
global $conf;
include $conf["ServerRoot"].$rc["_tplpath"].$rc["name__"].".php";
}

это уже темплейт инклудится и все.

в общей сложности чтобы сделать этот генератор компилятор у меня ушло примерно 7 трудодней.

продолжение следует....

спустя 1 день 20 часов [обр] Александр aka Efreeti(3/111)[досье]
Да, не слабо. Я не спец по CMS, и не рассматривал, что может делать Mambo, TYPO3 и т.д., но то, что пишете Вы - впечатляет.
спустя 15 дней [обр] Forgiven[досье]
странно... это всё мне напоминает CMSку EZ... http://ez.no
начиная от идей, заканчивая их реализацией :)
спустя 2 дня 19 часов [обр] lance10t[досье]

Forgiven[досье]
Да есть чтото общее... - дальние родчствинники (на первый взгляд)
=)..

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

речь пойдет о неком фреймворке для создания... (нет не сайтов) ... компанент.

цель- создать механизмы которые позволят "клепать" как на конвеере , форумы, гостевые, регистрацию юзеров, карзину, листинги и директории...

помните? на форум захаживала newcontinent ?
c темой "Пора кончать с системным идиотизмом nuke, а то идиотизм прикончит нас."
и там было придложено написать некий универсальнй обьект который бы делал ВСЕ.. да вобще _ВСЕ_ ...

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

для начала очертим круг проблем...

итак .. 90% интернет приложений... (да просто вобше приложений)...
они по большому счету.. решая очень разные проблемы - выполняют по сути похожие действия...
ээх... давайте к практике.. .

например:
почти все пиложения решают проблему отношения (принадлежности) .. одного обьектак ко многим ... или наоборот...
(отношение "один к одному" - часный случай)...
пример 1 "форум"
отношение
топика к теме
сообщения к топику
настроек к пользователю
пользователя к группе..
итп.. .

пример 2 "магазин"
отношения
товар - категории
пользователь - разные ценообразующие группы
категории к категориям...
итп...

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


помимо этого есть ... опции .. у обектов есть опции мы говорили об этом уже.

так вот ... таких базовых понятий относяшихся к обьектам- много...
но можно выделить основные и универсальные куски...

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

есть у обьектов - функции логирования...
как например - количество показов статьи.
или количество проданных товаров.
или время последнего посщения.. у пользователя на форуме...
....

как вы знаете большинство девелоперов... делают базы данных группируя разношерстные данные в разные таблицы..
по принципу принадлежности этих данных к некому обьекту...
те например форум-
там есть таблица юзеров куда понапихано вобще все что относится к юзеру.
я же хочу группировать данные в таблице ... не на основании их принадлнжности к какомуто понятию, а на основании похожести сути харанимой информации ...
те..
например я собираюсь сделать отельную таблицу в системе котороая будет отвечать за "отношение" чегото к чемуто...
и сделать специапльный API для управления этой таблицей...
и по моим прикидакам подобный механизм накроет 80% потребностей в описании отношений...

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

id-родителятип-родителяid-дитятип-дитя

теперь ТЕОРИЯ....
концепция называется

Кварко Атомарная Модель Обьектов

я решил позаимствовать физические термены потому что в этой модели ООП много сходства с физической моделью кварков.

что такое кварк в КАМО?..

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

пример кварка - это "менеджер опциий" который будь он взят отдельно - бесполезная штуковина.. потому что просто какието абстрактные "опции" непонятно к чему относящиеся...
точно также .. обькет отвечающий за отношения - он тоже сам по себе смысла не имеет...
но будучи встроенным в нормальный обьект.. привнесет в него необходимый функционал.

атом - это полноценноый обьект(класс в PHP) в его основу заложен обыкновенный ОБЬЕКТ как его понимают в ООП.
отличие атома в том что он состоит из набора необходимых ему кварков + некоторые особые функции реальзующие логику обьекта... вобщем атом это сумма кварков + "то чего не хватает в кварках"...

в системе КАМО подразумевается что каждому типу(классу) атомов заводится отлдельная таблица...

как это выглядит при использовании
упрощенный пример с "директориями и файлами"

class direct extends atom{

      function direct()
      {
   $this->atom();
   $this->addQuark('parent');     // add quark "Parent" recponsible for parent relations
   $this->addQuark('child');
   $this->addQuark('data');       // add quark "Data" recponsible for general data storing
      }

}

class file extends atom{

      function direct()
      {
   $this->atom();
   $this->addQuark('parent');     // add quark "Parent" recponsible for parent relations
   $this->addQuark('data');       // add quark "Data" recponsible for general data storing
      }

}

что происходит при подобном обьявлении.
вопервых у всей системы КАМО есть 2 режима работы..
режим "разработки" и "продукционный" режим...
я в дальнейшем буду говорит только о режиме "разработки"

так вот в этом режиме
автоматически создается 2 таблицы..
"atom_direct " и "atom_file"
 с пока единственным полем ID

затем подключаются обьекты кварков.

как с этим работать?...
например надо переименовать asd в qwe.
например вот так..

$director=new direct();
$director->data->name="asd";
$director->select();
$director->data->name="qwe";
$director->update();

вот и все.. это будет сделано одним SQL запросом. при вызове update.

или вот как выбрать все директории котоые находятся внутри директории с именем "root"

$director=new direct();
$director->data->name="root";
$director->parent->direct=$director->select();
$director->select();

// после этого можно работать с $director как со множеством... директрорий... 
// работать как с единым целым... 

// вот как например все эти директроии перенести в другую новую директроию... например "new_root"

$children=$director; // запмнили текущие выбранные директроии...

$director->data->name="new_root"; // выбрали имя.. 
$director->insert();  // добавили запись (она уже выбрана по умолчанию) 
$children->parent->direct=$director->select(); // поставили родителя. (селект не делает запроса в базу)
$children->update(); //  ВСЕ.

понастроящему селект данных из базы делается при попытке считать данные.

так что PHP'шные ... __SET и __GET - рулят =)...

ой чето я устал писать... пойду на перекур.

спустя 3 дня [обр] Михаил Евдокимов(0/1)[досье]

Приветствую!

Жутко интересный топик! Зачитываюсь вот уже третий день — спасибо! :)
Сегодня "случайно" (интересны были вариации на тему обмена информацией с сервером без перезагрузки целой страницы) накопал интересный на мой взгляд подход к управлению блоками информации на странице (не ново в плане ПО-интерфейсов, но на мой взгляд интересно для веб-интерфейсов). Клиентские исходники там, правда, "закодированы" (также как на gmail.com), но все равно думаю, что это может быть интересно: http://www.backbase.com/index.php?p=prod

Жду продолжения.. :)

С уважением,
Михаил

спустя 5 часов [обр] lance10t[досье]

Михаил Евдокимов[досье]
какие исходники клиентские ?..
эти чтоли http://www.backbase.com/js/backbase.js =)..
порылся на их сайте , и чесно говоря не понял их идей...

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

вот когда боты - Боги Интернета!
научатся по таким сайтам ходить тогда и буду думать.


ОБРАЩЕНИЕ КО ВСЕМ!
тут появился большой вопрос..

что лучше использовать xul+firefox
или exe

именно использовать, а не програмить...

вот какие я вижу тут разводки.
плюсы xul+firefox

  1. кросплатформенно

больше плюсов в использовании нет.

минусы xul+firefox

  1. тербует обязательно установить FF.
  2. не работает как отдельностоящее приложение.

а это не хорошо.. будут быки кто не захочет городить.

плюсы exe

  1. загрузил по ссылке, нажал Open и работай.

+ exe заведомо сильнее ксула.

минусы exe

  1. не кросплатформенно.

Люди пожалуйста оттветте кому не лениво.
про плюсы минусы этих технологий

спустя 6 часов [обр] Дмитрий Донцов+++(0/68)[досье]
lance10t[досье]
exe тоже надо как-то ставить, если это только не монолитное приложение - 1 exe и все, но мне кажется в таком случае оно будет обло, огромно и лаййе... :)
спустя 1 час 59 минут [обр] Михаил Евдокимов(0/1)[досье]
Прошу прощения, я забыл указать, что именно меня заинтересовало: демка Backbase Portal
спустя 19 часов [обр] DJ G.E.D(0/101)[досье]
Ликбез по авторским правам
http://www.ibase.ru/kdv/copyright.htm
спустя 5 дней [обр] Gansik[досье]

lance10t[досье]
Я уже писал вам ранее свое мнение по поводу что использовать в качестве клиента, теперь добавлю доводы в пользу XUL (все что ниже - жестокое ИМХО):

>> вот какие я вижу тут разводки.
>> плюсы xul+firefox
>> 1. кросплатформенно
И по моему это главный довод. Уж лучше тогда на Java писать, чем использовать EXE, который будет работать только при установленой DLL, которая должна быть скачана непонятно откуда. Но даже если вы и решите использовать EXE, то тогда хотя бы разработку на NET вести, там хоть инстал приложений можно сделать "в стиле xcopy".

>> минусы xul+firefox
>> 1. тербует обязательно установить FF.
В принципе скоро можно будет использовать XULRunner
http://wiki.mozilla.org/XUL:Xul_Runner.

>> 2. не работает как отдельностоящее приложение.
Если использовать XULRunner то можно при помощи BAT файла все решить.

>> плюсы exe
>> 1. загрузил по ссылке, нажал Open и работай.
то же самое и XUL приложение. В конце концов ничего страшного не будет если те кто будут пользоваться вашим клиентом постявят себе FF. Потом еще и спасибо скажут ;)

>> + exe заведомо сильнее ксула.
Думаю что средства XUL позволяют описать достаточно сложный UI.
Нету конечно возможности нарисовать свой контрол (тут писал неуверено) но они и не надо будет.

спустя 11 часов [обр] Прохожий[досье]

Я не являюсь разработчиком приложений на зуле. Но честно хотел этим заняться. И даже сделал какую-то мелочь.
Так вот. Я перелопатил массу всякой информации - в том числе и официальные доки и форумы. Для себя сделал вывод, что в существующем виде, зул не только не является серьезным средством разработки, но и его кроссплатформенность весьма условна. Даже в одной системе у одного пользователя, приложение будет работать замечательно, а у другого - нет... Народ извращается, как может, чтобы добиться "кроссплатформенности" в рамкох ОДНОЙ системы...
Я уж не говорю о том, что для него нет человеческой среды разработки...

Если стоит задача, сделать красиво, нужно делать EXE. В конце концов, у каждого, кто занимается созданием и поддержкой сайтов обязны быть винды...

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

спустя 1 месяц 1 день [обр] lance10t[досье]

открываю тему снова..
ведь больше месяца прошло как я ничего не писал.

а все потмоу что был сильно занят.

так уж получилоссь что у меня заказ и какраз на ксул и карказ на клиент-сервер с php

и выбрасывать эти наработки нехотелосьбы.
вобщем сейчас есть 2 темы.

  1. xul
  2. xmlrpc

попроядку.

да мне пришлось реально работать с ксулом..
впечатления:

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

PS
и на маке он чуток подругому работает чем под виндой.


про xmlrpc

наверно каждый кто начинал работать с xmlrpc обращали внимание чтоон какойто дубовый в php ?

вот и я с этим столкнулся..

начилось все с того что ,
проштудировав мануалы, я зашел посмотреть а чего ещё народ наимплементировал

http://xmlrpc.scripting.com/directory/1568/implementations

   PHP: client/server (Bård Farstad)
   PHP: client/server (Epinions)
   PHP: client/server (eZ systems)
   PHP: client/server (Keith Devens)
   PHP: client/server (Robert Hoffmann)
   PHP: client/server (Simon Willison)
   PHP: client/server (Stefan Saasen)
   PHP: client/server (Steven Apsotolou)
   PHP: client/server (Useful Inc)
   + пеаровсеая версия

аж 10 реализаций..

сразу стало интересно.. а почему именно так много?..
и оказалось что они в большинстве свем представляют из себе одно и тоже
а именно вариации на xmlrpc-epi который вкручен в php
так вот эти пакеты представлютиз себя написанные на php обработчики xml
ну те ПОЛНАЯ реализация xmlrpc
мне это сразу не понравилось
потому что это написано на php ... а в самом php есть xmlrpc-epi который должен работать гораздо быстрее ..

и я начал искать интерфес к этому xmlrpc-epi
естественно ничего приличного не нашел.

а кстати.. если кого интересует отдельно стоящий php xmlrpc сервер
реакмендую посмотреть http://scripts.incutio.com/xmlrpc/

так вот .. закончилось все тем что я написао свой интерфейс.. к xmlrpc-epi
который собрал очень хорошие черты других имплементаций.

интерфейс выполнен в виде классов.

а кстати можете его использовать в своих коммерчиских разработках
интерфейс распространняется по этой лицензии
http://www.opensource.org/licenses/artistic-license.php
только для читающих ЭТОТ топик.
http://apps.webtrox.com/xmlrpc/rosxmlrpc.txt

и чтобы было понятнее
вкратце обьясню достоинства

  1. скорость за счет использования встроенного в php xmlrpc-epi
  2. удобство использования (покажу на примерах)
  3. расширенная обработка удаленных ошибок.
  4. поддержка Basic HTTP аутентификации
  5. поддержка https
  6. малый размер - всего меньше 6 кило.
  7. коммерческая лицензия.

пример использования клиента.

require('rpcserver.php');

$testparam="aaaaaa";
$testparam2="bbbbbb";

$remoteserver = new xmlrpc_client('http://xmlrpc_client:rpcpass@apps.webtrox.com/xmlrpc/login/login.php');
// $remoteserver = new xmlrpc_client('https://www.google.com/accounts/ServiceLogin');
// $remoteserver = new xmlrpc_client('http://www.google.com:80');


$s = $remoteserver->remotefunction($testparam,$testparam2);

echo '<BR>session '.print_r($s);

создается клиент просто как обьект с параметром ... а парамтр как все уже заметили -
полный форматный адрес сервера..
вот тут и можно писать разные протоколы, юзера с паролем, порты..
imho так удобнее..

но можно и без параметра.. но тогда надо выставлять все вручную
типа
$remoteserver->host="www.google.com/";

ну и вызов удаленных процедур - просто как обращениие к методам обьекта.
$remoteserver->login($user,$pass);
проще пареной репы.

а теперь самое притяное..

если происходит ошибка(любая) НА СЕРВЕРЕ
то вы её увидете какбудто она произошла локально у вас тут где работает клиент.

разбераются все ошибки какие я только смог сэмулировать .

те начиная от требования к аутентификации и невозможностью подключиться по ssl, и все ошибки http протокола
заканчивая фатальными ошибками в php коде сервера, и ошибками синтаксиса..
про всякиt нотайсы, и warning .. итак понятно
все ретранслируется в клиента.

а то иначе так неудобно сервер разрабатывать вслепую...

пример вывода ошибки клиентом

WARNING: [XML-RPC](200) Fatal error: Call to undefined function: aaaddd() in /ХХХХХ/ХХХХ/ХХХХХХХ/ХХХХХ/login.php on line 19

или вот синтаксическая

WARNING: [XML-RPC](200) Parse error: parse error, unexpected '}' in /ХХХХХ/ХХХХ/ХХХХХХХ/ХХХХХ/login.php on line 21

это вместо стандартного "просто отсутствия ответа".


а теперь про сервер
вот его код

require('../rpcserver.php');

class server extends xmlrpc_server{
   function loginserver () 
   {
           $this->xmlrpc_server();
        }

        function remotefunction($p1,$p2)
        {
           return " secred ddd code for $p1 and $p2"; 
        }
}
$serv = new server();

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

и все - сервер начнет работать.

так вот отличительная особенность... от стандартного интрефейса xmlrpc-epi
не надо переходить на другой стиль програмирования...
ведь xmlrpc-epi заставляет работать по следующей схеме
что функция обработчик - получет парамерты в массиве
те rpchandler($method,$params)
где $method - строка а $params - массив..
а в этом же интерфейсе .. нечего нового..
login($user,$pass) работает как и ожидается- получает 2 независимых параметра.

вобщем пока все .

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

именно этот интерфейс будет использоваться в системе.

спустя 13 дней [обр] lance10t[досье]

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

"домашнюю страничку" посвещенную этой системе.
и там будет крутится этот движок.

а пока размышления:

"хакероустойчивая архитектура"..
возможно ли это?...

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

и вот просумировав все свои знания по поводу взлома..

могу констатировать факт что IMHO

90% взломов и хаков основанны только на одном простом принцепе...
некие переменные попадают туда где их не ждут и где они не должны быть...
те по большому счету вся проблема безопасности web систем это проблема защиты "памяти"
от несанкционированной записи...

самое распространенное...
1 всеравно остается SQL инъекции через левые преременные
2 загрузка удаленных файлов.. те нарушение работы include через пременные
3 крос сайт скриптинг ( но это уже шалости... ) через левые пременные
4 получения административных прав. установка вяких важный параметрв в сесию или кудато ещё...

и в целях безопасности я решил вобще

1 отказаться от приема cтандартных переменных GET обыкновенным путем чрез $_GET[].
2 поставить "файрвол" на POST и куки
3 убить проблеу общей доступности памяти. (про это будет подробнее всего)

ну про гет понятно
геты можно нормально заменить красивыми урлами.
и проверять их по регекспам..
это уже давно сделано.. и я спокойно отправляю данные пррешедщщие от регекспов прямо в sql
потмоу что уверенн на 100% что никаких кавычек просто прити не может и % и прочая закодированная лабуда
до скрипта не дойдет, те скрип даже не будет загружен.

пост и куки можно тоже пускать через регекспы и резать все что не проходи по правиам..
а правила - строгие.. по умолчанию "все в топку!.." ...

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

ну для начала замечу что самое чего я нелюблю это GLOBALS
и поэтому вобще весть запуск системы происходит через функцию ..

function  main()
{
   global $core,$conf;
   $conf=array();
   $core=array();

.... КОД ЯДРА ...

}

main();

вот так стартует система... и заранее заводятся 2 глобальных масива...
все остальное будет игнорироваться...

и вобще все загрузки и динамические инклуды происходят исключительно внутри функций...

чтото тиипа такого.

function add_module($filename,$moduleName)
{
   require_once($filename);
   return new $moduleName();
}

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

тепрь моули могут контактировать друг с другом ну факчиески только через функцию...
например call('module_name','method',$params)
ну естественно что все это оскрыто за более красивой оболочкой но суть остается таже...

и теперь фишка!... защищенная память
с помошью STATIC

function call($module,$instance,$method)
   {

      static  $modules;
...

и теперь этот массив модулей будет сохранятся между вызовами функции call
те в этом массиве и хранятся все модули системы и этот массив не досупен извне...

те функция может вобще конролировать все взаимоотношения модулей...

но это ещё не все!
самый фокус-покус в том что функция может вернуть ссылку на этот статик массив...

вот кусочек.. кода, Это метод обьекта..

function &controls()
   {
      static $controls;
      if (!isset($controls))
      {
         $controls['boot']=            array();
         $controls['system']=         array();
........ инициализация важного для сисемы  массива .. 
   
         $controls['onError']=               array();
         return $controls;
      }
продолжение функции
... норамльтный режим работы... функции 
   }

и работет это по следующей схеме...
функция только при первом вызове инициализирует массив и отдает на него ссылку...

и в коде ядра есть такая стрчка

   $controls=&$core['kernel']->controls();

вот и после этого маневра доступ к заветному массиву с модулями и прерываниями есть только у 2х товарищей..
у самой функции и у того кто самый превый её вызовет.. те это только ядро.. =)
и масив "не однодневка" который поидее должен сдохнуть по завершении функции.
а жывучий на все время выполнения программы.

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

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

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


а чтобы небыло sql иньекций... ну надо просто грамтоно модуль БД написать..
который будет одновременно организовывать уровень абстракции чтобы можно было потом с мускула если надо переключится..
на чтото другое.

сейчас система может просто контролировать несколько опасны подключаемые модули...
и просто проверять нету ли там внутри функций прямого доступа к файловой системе или к sql'у

просто уже сейчас.. система при смене настроек самоперекомпелируется...
и во время это перекомпеляции движок сканирует модули и пишет для них интерфейсы...
ну котоыре перенаправляют запросы в эту функцию call

и когда какойто модуль вызовет
$core['sql']->query($query);
то на самом деле будет запущен этот автоматический интерфейс.

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

кстати ядро у системы я преписываю уже ШЕСТОЙ раз ...
и версия ядра 0.6 =)
пришлось отказатьcя вобще от применения overload потмоу что ядро стало крашить апач при php 4.3.11 =).. на линуксе..

и вобще оверлоад был конечно проще в написании но уж больно нестабильно он работает в 4-м php
а писать сразу под 5 я немогу .. потмо что тогда на чем буду делать текущие проекты?..
пока что все ещё работаем на 4-ке..

есть ли у котото идеи по поводу безопасности памяти в php?

спустя 2 месяца 21 день [обр] Александр aka Efreeti(3/111)[досье]
lance10t[досье]Так разработка продолжается?
спустя 1 час 47 минут [обр] lance10t[досье]

Да и сайт уже крутится вовсю...
я хотел тут ссылку дать на него но СЕОшник не разрешает мы вчера только сделали тотальную оптимизацию сайта и он хочет посмотреть "чистые" результаты...

а так я просто ужасно загружен работой еле на разработку время выкраиваю.

дела обстаят так.
вобще идея с темплейтами оказалась просто невероятно пладатворная и движек темплейтов я переписал уже с нуля...
те сейчас Ryo-Ohki Template Engine - версии 2..
он как оддельно стоящий модуль применяется на нескольких сайтах.

там полно наворотов..
например сечас движек генерирует XHTML strict
те например если для отображеия станицы понадобилось применить 5 темплейтов
ну для разных кусков сайта..
и по идеалогии - каждый например инклуды нужных css
так движок переносит <link> в заголовок.
те в конце сурс странички выглядет так какбудто это "ручная работа" а не сборка из 5-и независимых хтмл кусочков.

но главное новвоведение в движке темплейтов это его расширяемость..
те например если вдруг понадобится ввести поддержку какихто новых комманд или тегов то бельше ничего не надо исправлять!..
а только надо добавлять новые пхп файлы. и они сами подключатся куда надо.

затем на основе этого движка я сделал компонент для обработки форм..
те .. знаете всегда с формами проблема.. надо их както удобно обрабатывать
а теперь просто в HTML формы можно дописывать например
<input type='text' require='word' display='user' _error='your have to specify username to login!' >
<input type='password' require='word' display='pass' _error='Password is required' >

@require='word'@ - сделает это поле жывым.. (туда в require= можно и регексп написать)
те форма не просубмитится (естественно там серверная проверка)
пока туда не будет введено слово...
будет выведено красивое сообщегние об ошибке..
и самое хорошее - данные не потеряются те не предется вводить user - повторно.

вобщем я больше PHP код для форм вобще не пишу..

работа с формой выглядет следующим образом

$TemplateResource=$core['templates']->select('formexample');
// загрузка темплейта с формой

$form=formProcessor($TemplateResource);
// универсальный обработчик форм.

if (!count($form['errors'])) // это значит что в форме гарантированно нет ошибок.
{

// данные в $Form гораздо безопаснее чем в POST- тк они прошли всевозможные проверки и защиты.
echo "username:".$form['user']['HTML'];
echo "pass:".$form['pass']['HTML'];

}

$core['templates']->render($TemplateResource);

и все вот этот код... делает полностью цивильную форму. легко и быстро.
вобщем все шасливы.

это то что касается темплейтов...

помимо этого сейчас я работаю над решением очень большой и сложной проблемой
...
делаю "драйвер" для хранения древовидных структур в реляционке.

и работа с драйвером будет похожа на работу с командной срокой доса =).
и конечная цель сделать такую хрень чтобы решить проблему древавидых данных тоже накорню и чтобы не лазить даже в sql ,,, те оно само и таблицы нужные создает.

вобщем идея такая - сделать дерево.. которое будет подключаться к внешним таблицам..
те представте - есть таблица юзеров например с своими ID

И дерево будет подключаться к этой таблице извне не внося в неё изменений.

вот если взять разделение юзеров на группы.
например вывод всех юзеров-администраторов у котороых имя начинается на "А"
и создание подгруппы и перенос части юзеров туда.

$users=$tree->batch(
"
cd groupes://administrators
list {where name like 'a%'}
mkdir superadmin
move {where name like 'a%'} superadmin
"
);

$subdirs=$tree->batch(
"
dir
"
);
// должно вывести списко подкатегорий.

Это должно сработать примерно так.

cd - это сменти текущую папку.. и "диск"
те движок деревьев я делаю многомерный-многоразрезный..
те юзеры могут быть как в группах так и ещё в какихто тругих видах категорий...
а тут четоко указывается что переключаемся на "разрез" groupes://
и выбрать всех кто в administrators
и подключить кусок SQL where name like 'a%'

"mkdir superadmin"
затем создать подкатегорию superadmin

"move {where name like 'a%'} superadmin"
и мувнуть туда всех этих юзеров..

но приэтом эти юзеры котороые теперь в superadmin они попрежнему являются подмножеством administrators

вобщем вот в таком духе доса и будут дерева.

вобщем сейчас получается что на выборки данных из дерева уходит 1 или 2 запроса...
и работать будет быстро за счет избыточности данных.
 
а на ввод листочков к дереву- 2 запроса

на изменение структуры дерева - 5 запросов или около того.

самоа идея движка - гибридная.. это гибрид 2-х концепций.

  1. это координатное хранение данных

те например группа administrators - простирается на виртуальном пространстве от 0 до 1..
а superadmin от 0 до 0..
(ВНИМАНИЕ ТУТ Я СИЛЬНО ОЧЕНЬ СИЛЬНО УПРОШАЮ МОДЕЛЬ)
сделано будет гораздо хитрее.

упрощенно:
а листочки - имеют координаты например 1 или 0 ...
и когда надо выбрать например всех админов то sql Будет искать юзеров с коррдинатами между 1и0 ...
и выберет кого надо...

  1. но там будут многомерные координаты
  2. будут "ссыдлки на листочки" .. потому что листочки - хранаятся вобще во внещней таблице.
  3. листочек может быть во многих категориях одновременно тк он подключен через ссылку.

а поскокльку дерево подключается к внешней таблице то там можно будет мутить очень прикольнын фокусы...
например будет дерево регионов..
его можно и к товаром подключить и тутже и к поставщикам...
если новый регион добавится то он и у "поставшиков" появится и у "товаров"
те дерево одно - а наборы листочков - разные.

а рхитектура примерно следующая..
1 таблица на одно многомерное дерево (хранится только структура дерева)
+

  1. по таблице связей на каждый тип листочкоа .. те связь дерево->товары и дерево->поставшики

это 2 разнеые таблицы.. и в них и будет избыточность..

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

единственный большой минус - это трудно сделать..
и все... ну ниче .. я какнить намучу.

а ещё интересно узнать у публики....
ЛЮДИ КТО КАК РАЗБИРАЕТ XML?
какие идеи проблемы и решения...
те предствте вам дают данные в хмл ...
и говорят - "надо в базу занести!"
какие ваши действия?..
dom? sax? или как?

спустя 25 минут [обр] lance10t[досье]

а и ещё!...
XUL - это задница.
только для мелких плагинов годится

Будь поклят тот день когда я подписал контракт на создане большого плагина для файрфокса!...
плюнте в глаза тому кто скажет про "кросплатформенность" XUL...
на этих уродских макинтошах надо ОСОБЫМ образом писать.. иначе глючит и FF вылетает.

спустя 8 часов [обр] Дмитрий Донцов+++(0/68)[досье]

lance10t[досье]
о, вопрос...

а сколько запросов при построении пути от конкретного листочка (директории) до корня дерева, если уровень вложенности листочка (директории) ну хотябы 10? :)

если вы конечно такой путь строите...

спустя 12 минут [обр] lance10t[досье]

1 запрос
и выборки только по 2-м цифорвым полям..
упрощенно вглядит примерно так..

select * from tree where left<={искомое ID} and right>={искомое ID}

ну это упрощенно насамом деле будет помимо этого 2 join'a (или вобще 1 join если известен хот какойто id листочка) но они будут очень быстрые потмоу что приджоинится только 1 значение да и то по проиндексированным полям.

затем волученные резульаты выстраиваются в иерархию томже цикле где происходит обработка сырого sql результата myswl_fetch_assoc
приэтом вытаскиваются все необходимые данные для работы с любым из родительских узлв.

конечно пути строятся и пути именно текстовые. типа такого /dir1/subdir/anotherdir/lastdir/

спустя 3 минуты [обр] lance10t[досье]
а ну ... это сли реально про листочек..
те например по ID юзера если надо найти в каких он группах ..
то это будет с джоинами
а если уже есть какаято группа и надо узнать куда она вложена то вобще без джоина.
спустя 16 минут [обр] lance10t[досье]
а и ещё..
если например есть какойто товар .. с ID
и он лежит в ну 4 разных категориях вобще в разных вложенностях..
то чтобы вытащить все эти несколько путей нахождения этого товара
будет применятся этот же самый 1 запрос.
спустя 3 дня [обр] Прохожий[досье]
Простой XML я разбираю самописной функцией - ибо быстрее.
С полнофункциональным XMLем как-то не приходилось работать...
спустя 3 дня [обр] y0r1c[досье]
Уважаемый Олег Колыхалин, меня очень заинтересовали ваши идеи, и главное - то, что идеи воплощаются в жизнь, но хотелось бы увидеть вашу CMS в работе...
спустя 14 дней [обр] lance10t[досье]

итак , продолжим....
 помните я писал на этом топике про кварки...
про составные обьекты... которые получают свой функуцилнал пользуясь "детальками" которые поотдельности бесполезны..

так вот я заговорил об этом снова потому что недавно мне удалось написать
реально работающу альфа версию ... ну скажем так.. написан прототип для проверки концепции...

и в итоге ... был получен очень хороший результат.
получилось написать целый класс который ну например реализует управление данными в БД... без единого ручного SQL запроса.

(это все например)
те представте есть БД с 3-я таблицами
главная таблица + две которые хранят в себе дополнительные данные... и ID указывающий на строчку из главной таблицы

главная таблица компаний.
company_table

idloginpassenabledname

и дополнительная.. для хранения например адреса.
company_address_table

company_idstreetcity

и ещё одна для хранения контактной инфы
company_contact_table

company_idfirst_namelast_namephoneemail

так вот это обычная рутина програмистская написать класы с методами для манипулирования всем этим добром...

например поставим задачу..
написать класс.
который будет иметь
getProfile(int company_id) - возвращение всей информации о компании по ID (в ассоциативном массиве)
updateProfile(int company_id, array profile) обновление ресторана (тоже через масив)
ну народ тут догадливый и по названию поймете что следующие функцци должны делать.
insertProfile
deleteProfile
changeEmail - это в качестве примера как изменить какоето конкретное поле.
authorize - это просто авторизация компании входные параметры логин и пароль Возвращает идентификатор компании в случае успеха.

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

теперь работа програмиста сводится к описанюю базы..
те чтобы этот прототип кварка мог самостоятельно писать SQL запросы, есть 3 варианта

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

вот тут какраз 2-й вариант...
итак описание базы выглядет следующим образом.

rosController - это времненное название этого прототипа.

class CompanyProfile extends rosController  {

   // company dataset  это просто массив с названиями полей, но тут альясы не нужны пока

   var $data=array(
   'id'=>null,            //   integer
   'name'=>null,           //    character(100)
   'login'=>null,         //    character(30)
   'password'=>null,      //    character(30)
   'enabled'=>null,      //    boolean
   );

   // Company address set   с этим тоже все ясно описание очередной таблицы.
   var $address=array
   (
   'company_id'=>null,   //   integer
   'street'=>null,       //    character(255)
   'city'=>null,          //    character(100)
   );

   // company contact set  тоже описание таблицы
   var $contact=array( 
   'company_id'=>null,    //   integer
   'first_name'=>null,    //   character varying(100)
   'last_name'=>null,       //   character varying(100)
   'title'=>null,          //   character varying(100)
   'phone'=>null,          //   character varying(100)
   'email'=>null,          //   character varying(100)
   );


   // bind datasets names to tables  а это имя - зарезервированно системой $dbind используется для хранения какой масив какой таблице соответствует. те тут надо обязательно перечислить массивы которые мы создали ранее.

   var $dbind=array(
   'data'=>'company_table',
   'address'=>'company_address_table',
   'contact'=>'company_contact_table',
   );

   // set join keys for datasets  а теперь надо описать связи, те указать что у них общее...  
это необходимо чтобы кварк мог писать запросы с JOIN и просто догонял что если гдето указали ID компании что надо и адрес с такимже ID взять

   var $datalinks =array(
   'data'=>'id',
   'address'=>'company_id',
   'contact'=>'company_id',
   );



   // set primary dataset затем надо указать какой набор данных главный потому что сейчас они все равноправные, итакже надо указать названия масива содержащий связи...  эти primaryset и primarylinks - зарезервированные слова.

   var $primaryset="data";
   var $primarylinks="datalinks";




   // specify data types и на последок остается указать типы данных... а иначе все будет считаться за STRING
   var $find=array(
   'data' => array(
   'id' => 'int',
   'enabled'=>'boolean'
   ),
   'address' => array(
   'company_id' => 'int'
   ),
   'contact' => array(
   'company_id' => 'int'
   ),
   );

все - хватит SQL'a Теперь можно перейти к реализации логики программы...

по порядку

   function getProfile($id,$flags=0)
   {
      $this->reset();
      $this->data['id']=$id;
      $this->target();
      $result=$this->getlinked(array('address','contact'));
      return $result;
   }

вот и все.. на выходе будет просто массив со всеми данными...
как это сработало..
$this->reset(); просто все че можно обнуляет - это банальная функция...

$this->data['id']=$id; тут мы поставили значение в уже существующий масив...

$this->target(); поскольку параметров не дано то target() автоматичести обработает именно главные масив...
помните мы установили главным масивом.. именно data
функция target() она просто пишет концовку запроса а именно where


where
 company_table.id = 777


согласитесь мы дали программе достаточно информации чтобы она осилиа это

затем сработет $this->getlinked(array('address','contact'));
она сделает 2 веши...
вопервых пройдется по переданным ей масивам+по Pimary (его не обязательно передавать, программа итак о нем знает)
и напишет примероно следующее..


 select 
 company_table.id,
 company_table.name,
 company_table.login,
 company_table.password,
 company_table.enabled,
 company_address_table.postal,
 company_address_table.street,
 company_address_table.city,
 company_contact_table.first_name,
 company_contact_table.last_name,
 company_contact_table.middle_name,
 company_contact_table.email,
 from


в тоже время пока getlinked() гуляет по массивам.. тамже пишутся JOIN'ы
опятьже информации для этого предостаточно.


 company_table
 left join company_address_table on (company_address_table.company_id = company.id) 
 left join company_contact_table on (company_contact_table.company_id = company.id)

и все! ВУАЛЯ =)... получили запрос...


select 
 company_table.id,
 company_table.name,
 company_table.login,
 company_table.password,
 company_table.enabled,
 company_address_table.postal,
 company_address_table.street,
 company_address_table.city,
 company_contact_table.first_name,
 company_contact_table.last_name,
 company_contact_table.middle_name,
 company_contact_table.email,
 from 
 company_table
 left join company_address_table on (company_address_table.company_id = company_table.id) 
 left join company_contact_table on (company_contact_table.company_id = company_table.id) 
where 
 company_table.id = 777

а дальше уже все понятно, остается его только исполнить и вернуть результаты

теперь.. дальше - ввод нового профайла компании
insertProfile

function insertProfile($profile)
   {
      $this->reset();
      $this->separateDatasets($profile);
      $this->set('data',true);
      $this->get('data');
      $this->target();
      $this->set('address',true);
      $this->set('contact',true);
      return $this->data['id'];
   }

про reset уже все ясно,

а separateDatasets это простенькая функция которая разобьет один большой ассоциативный масив на 3 поменьше,
те входной параметр это 1 массив...
а для работы надо наполнить данными
$this->data[]
$this->address[]
$this->contact[]

затем вызывается
$this->set('data',true);
true это значит что это не update a insert


insert into company 
(name
,description
,login
,password
,enabled)
 values 
('new TEST comapny Ltd'
,'DESC lorem ipsum'
,'login1'
,'pass1'
,TRUE)

и вобщемто тоже просто напишется инсерт тех данных которые попали в массив data
 а следующая за ним
$this->get('data'); напишет очень простой селект со всеми данными которые были в data в предыдущем запросе.
и таким образом получит новоиспеченый ID
а кстати get она не только возврашает масив дванных она автоматически наполняет внутренний масив...

те если например написать так...

$this->data['id']=777;
$this->target();
$this->get('data');

то масив $this->data будет уже наполнен всеми данными которые пришли по ID=777, потому что get его заполнит.

так вот ...
после такой комбинации

      $this->set('data',true);
      $this->get('data');

тутже появляется действующий ID который находится в $this->data['id']

и концовка функции


$this->target();
   $this->set('address',true);
   $this->set('contact',true);


$this->target();
понимает что $this->address['company_id'] и $this->contact['company_id']
должно быть такимже как и $this->data['id']
и target(); автоматически выставит $this->address['company_id'] и $this->contact['company_id'] равными $this->data['id']

оставшиеся 2 команды
$this->set('address',true);
$this->set('contact',true);

просто напишут 2 INSERT запроса и все будет хорошо потому что
 $this->address['company_id'] и $this->contact['company_id'] уже содержат правильный ID

-------------------
insert into company_address_table 
(company_id,street,city)
 values 
(1,'2120 Avenue Street','Port Moody')
----------------------
insert into company_contact_table 
(company_id,first_name,last_name,phone,email)
 values 
(1,'John','Smith','1-905-89-TAPKA','John@example.com')
---------------------

вот и все, вот и вся вставка нового профайла.

function insertProfile($profile)
   {
      $this->reset();
      $this->separateDatasets($profile);
      $this->set('data',true);
      $this->get('data');
      $this->target();
      $this->set('address',true);
      $this->set('contact',true);
      return $this->data['id'];
   }



$exampleinsert=array (
'name' => 'new TEST comapny Ltd',
'description' => 'DESC lorem ipsum',
'login' => 'login1',
'password' => 'pass1',
'enabled' => 't',
'street' => '2120 Avenue Street',
'city' => 'Port Moody',
'first_name' => 'John',
'last_name' => 'Smith',
'phone' => '1-905-89-TAPKA',
'email' => 'John@example.com',
);
   
$result=$res->insertProfile($exampleinsert);

далее...

deleteProfile

   function deleteProfile($merchant_id,$flags=0)
   {
      $this->reset();
      $this->data['id']=$merchant_id;
      $this->target();
      $this->delete();
   }

до безобразия просто

      $this->delete();
вызывает цепное удаление всех подключенных полей и в конце удалятся primary поле..

$res->deleteProfile(777); 
--------------------
delete from company_contact_table
 where 
company_contact_table.company_id = 777
--------------------
delete from company_address_table
 where 
company_address_table.company_id = 777
--------------------
delete from company
 where 
company.id = 777
--------------------

если указать например

      $this->delete('contact');
То цепного удаления не будет, а только из одной таблицы.

далее...

changeEmail

   function changeEmail($company_id,$email)
   {

      $this->reset();
      $this->data['id']=$merchant_id;
      $this->target();
      $this->contact['email']=$email;
      $this->set('contact');
   }

ну что? надеюсь всем понятно как это сработает?..

и напоследок ....

authorize

   function authorize($login,$password)
   {
      $this->reset();
      $this->data['login']=$login;
      $this->get('data');
      if (trim($this->data['password'])===$password)
      {
         return $this->data['id'];
      }
      else
      {
         return 0;
      }
   }

тоже просто, вытащили по логину - сравнили пароли,.
хотя можно быор ещё короче написать

function authorize($login,$password)
   {
      $this->reset();
      $this->data['login']=$login;
      $this->data['password']=$password;
      $this->get('data');
      return $this->data['id'];
   }

как видите, можно и без target работать, когда работем с primary набором то таргет сам посебе работает...

вобщем эта authorize будет возвращать либо ID либо нулл...
в зависимотсти от успешности авторизации .

вобщем я написал уже кучу функций в таком стиле и все четко и хорошо работает,
те примеры что я тут привел - они простые(там демонстировались отношения 1 к 1)
, на самом деле система спокойно тянет отношения один ко многим,
те например если у компании ну 10 контактных персон,
то вытщать все контакры вместо одного очень просто

$contacts=$this->get('contact',1000);
1000 - это лимит,

и что ещё очень приятно весь этот класс который имеет функции...
get,target,set,getlinked,separateDatasets,reset,delete
уместился в 400 строк хорошо отформатированной программы..

те там все красиво...
вот строчки оттуда


         case 'boolean':
         if ($dir=='get')
         {
            return ($value)?" = TRUE":" = FALSE";
         }
         elseif ($dir=='set')
         {
            return ($value)?"TRUE":"FALSE";
         }

вобщем мне это очень понравилось , работать с sql не написав ни одного запроса...
пусть это будет началом новой эры..
эры БЕЗSQLНОГО ПРОГРАMИРОВАНИЯ.
потому что теперь я понял что это очень круто и удобно, и буду теперь эту тему развивать...

это - была альфа версия.

когда напишу бету... то скорее всего отдам альфу людям....

но в бете я планирую полностью перейти на overload'ы и сделать автодетект структуры базы...
а то мне лень писать это описание базы.. какие поля какого типа...
надо просто будет указать таблицы и связи... а остальное скрипт сам найдет , проанализирует и в файл запишет для последующего использования,

а кстати волею судеб мне пришось работать с Postger SQL
"ну и хлам!", скажу я вам.. постгрешников надо топить в пруду, как муму..

это будет почсеному- выжывут- занчит заслужили..жыть.
а нет - ну и хрен сними,....меньше хлама будет....

постгре , постгре просто хорошо работет когда в запросе ID указано конкретно...
а если ему говориш вытащить все компании LIKE "A%" и приэтом приJOIN'ить какието другие поля вот тут никакой гарантии что данные будут, ....
те чтото гдето у него не срастается...
ему надо давать 2-3 мелких запроса вместо одного,
те при всех его достоинствах и наваротах он всеравно сасет у MySQL не нагибаяз...
именно изза того что не может корректно исполнить банальные вещи а взялся за всякие сложности.
типа хранимых процедур, да и админка к нему- тоже хлам... PHPMyAdmin рулит.

PS.
а по поводу посмотреть CMS , эх я не могу шас дать ссылку на главный сайт, там эти долбанные замеры статистики, .... я в ближайшие неделю-другую. селаю копию сайта на отдельном хосте, и тогда дам на него ссылку.

спустя 13 дней [обр] Андрей Иванов(0/3)[досье]
А что за версия Постгреса?
Я на 8.0.2 под Windows делал LIKE "A%" с JOIN и всё работало нормально.
спустя 3 дня [обр] Дмитрий Кононов(0/16)[досье]
lance10t[досье], вот такую штуку видели?
спустя 15 часов [обр] lance10t[досье]

Андрей Иванов[досье]
Да, не обращайте внимания, про постгре это я так погорячился, ну работбает както ну и фиг с ним...
те естественно если взять базу и сделать "LIKE "A%" с JOIN" он это спокойно обработает,
а у нам там не просто база, а всякие тригеры-функции, связи , foreign key, и прочая лабуда типа UTF-8 как примари кодировка, те я уверен вам не воссодать полностью наш вариант,
а в 99% он конечно сделат "LIKE "A%" с JOIN"

Дмитрий Кононов[досье]
"вот такую штуку видели?"

О!! какраз то что я написал =)..
но!..

я от своего не откажусь уже точно, потому что мое оно гибче
по 1-й простой причине...

когда я эту системку делал то специально проектировал её чтобы она подключалась в любую уже существующую базу с любой структурой, а эта ezpdo.net она сама постановляет какая ей нужна база, и как обрабатывать связи...

те то что я написал оно конечно не содержит транзакций, и обработчиков событий...
но они мне и не нужны.. если чесно..

да и некоторые вещи ezpdo.net не может делать,
а например с их сайта..
вот как выглядет по их методу добавление 4-х авторов к книге

// add authors to books
$b1->authors = array($a1, $a2, $a3, $a4);

у меня можно сделать также
например
$book->author['id']=array($a1, $a2, $a3, $a4);

но в реальности этого не хватает, потому что обыно всегда жызь сложнее чем туториал
поэтому у меня можно делать и вот так
$autor->book['id']=array('select autor_id from .... ');
это будет корректно.

Вобщем, так их система хороша!.. она хороша тем что заметно проще в использовании(хотя почти такойже мощности) чем то что я родил ,
но минус то что она не так хорощо внедряется в чужую базу как мое,

или вот пример как они удаляют книги определеного автора с количеством страниц > 500

//
$book2find->author = "ezpdo4php";
 
// find all books by ezpdo4php
$books = $m->find($book2find);

Say we want to delete all books that have more than 500 pages by author ezpdo4php and mark the rest of books is_easy_to_read.

// for each boook
foreach($books as $book) {
 
  if ($book->pages > 500) {
 
    // delete the thick book (> pages)
    $m->delete($book);
 
  } else {
 
    // otherwise, mark the book thin
    $book->is_easy_to_read = true;
 
    // update it in storage
    $m->commit($book);
  }
 
}

у меня этоже действие будет сделано так.

$book->data['autor']="ezpdo4php";
$book->data['pages']=">500"; 
// хотя "pages" заявлено в системе как INT передаем во внутрь всеже строку,
// и это заставит конструктор воспринять ">500" не как int а как выражение.

$book->target();
$book->delete(); //удалили все "pages >500"
$book->data['pages']=null; // отменили обработку страниц
$book->target();
$book->data['is_easy_to_read']=true;
$book->update();

насклько я понял ezpdo сделает ровно столько запросов сколько книг будет обработано в цикле.
а мой ваириант сделает 2 запроса
$book->delete(); и $book->update();

спустя 2 месяца 15 дней [обр] lance10t[досье]

я ответил на письмо одному человеку...
и тешил тут отпубликовать ответ

> Жаль, что Вы уже довольно долгое время не продолжаете Ваши
> изыскания, поскольку Ваши подходы весьма интересны.

не путайте "пишу на Xpoint" и не продолжаю разработаки,
разработки какраз идут, а на Xpoint нет времени... к сожалению. =(

> Я заинтересовался Вашими мыслями и решил попробовать написать
> более-менее гибкое ядро для своей системы. Я также как и многие другие
> разработчики раньше интегрировал поддержку БД в ядро, но прочитав
> изложенные Вами мысли, понял, что не прав, что если задуматься, то
> сайт действительно должен уметь работать без БД, что работа с БД
> должна быть оформлена в виде отдельного модуля. Я сделал именно так --
> вроде работает.
>
> Единственное, что мне не очень понятно теперь: когда открывать И
> закрывать соединение с БД? Если раньше поддержка БД была интегрирована
> в ядро, то мы соответственно открывали соединение при инициализации
> ядра и закрывали его в конце программы. А что делать сейчас?

у меня сделано так,

система вобще ядро имеет несколько глобальных этапов исполнения...
например

   $runlevels=array(
                "boot",
                "system",
                "automatic",
                "shutdown",
                "end"
               );
пяти этапов пока на все хватает

это чисто формальные названия, можно было сделать 20 этапов или 1...
это не принципиально...
этапы выполняются последовально и в кажом этапе происходит запуск модулей.

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

class mysql{
        function mysql ()
        {

             global $core;

      $core['kernel']->controls('execute close_base end'); //ВЕСЬ ФОКУС В ЭТОЙ СТРОКЕ

//когда будет создан инстанс модуля базы
//этот новый модуль обратится к ядру через $core['kernel']
//и сделает "запрос" те модуль попросит запусить свою функцию с именем close_base
//во время выполнения этапа "end"
              
// а тут можно провести подключение к базе

        }
        function close_base()
        {
         // выполняет закрытие соединения
        }
}

так вот открытие сединения может произойти в разное время, это зависит от того как будет загружен модуль БД,

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

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

а так вот синтаксис функции controls модуля ядра

1 execute 'method' [boot|start|^automatic|shutdown|end]

2 intercept all|each [boot|start|^automatic|shutdown|end] 'method'

3 intercept 'target-module' ['target-method'] 'method'

4 cover all|each [boot|start|^automatic|shutdown|end] 'method'

5 cover 'target-module' ['target-method'] 'method'

6 override 'target-module' ['target-method'] 'method'

те в примере с БД это был вариант 1.

а например про варинт 2

"intercept all" это тожесамое что написать "intercept all automatic"
это значит что модуль хочет чтобы его "method" был исполнен перед выполнением этапа с именем "automatic"

"intercept each" это значит что модуль хочет исполнять свой метод перед каждым модулем который запстется на этапе "automatic" и в этом режиме наш модуль перехватчик может подкоректировать те параметры которые будут переданы перехватываемому модулю .

ну я думаю по названиям догадаться можно
cover - запукаться после чегото там... после модуля , этапа, или
также можно конкретно указать кого перехватить или прекрыть...
те например можно вмешаться в работу системы наприеер так

$core['kernel']->controls('intercept mysql close_base my_special_interceptor');

если какойто другой модуль сделает такой запрос...
то ядро запустет его метод my_special_interceptor какраз перед
тем как модуль базы попытается закрыть базу...
и если my_special_interceptor вернет false то этим он смоджет отменить выполнение close_base...

и при этом не зная что именно и когда именн запустется close_base


а, кстати одна заметка,мудлем надо сделать не только БД.. !!!
но и само ядро!..
те в Рио-Оки(название движка)
даже ядро это самый настоящий модуль..

просто это первый модуль который загружается раньше всех...
и поскольку он загрузился первый и никого нет вокруг то он быстренько
"забегает в центральную рубку управления закрывает там за собой дверь"
и обьявляет себя главным..
а так по сути, ядро это тотже модуль...
просто в Рио-Оки можно получить поинтер на массив модулей только 1 раз в принцепе.. за время выполнения программы. потмоу что сам массив хранится в защищенной static памяти
и кто раньше встал того и тапки тот и сможет потом обрашаться к другим модулям напрямую..


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

он совершенно становится нередактируемый и перегруженный
при маломальски продвинутом сайте,

те теперь все конфигурация происходит через xml
я пользуюсь замечательным визуальным редактором XML который называется XMLShell
и весит 800K ...

Люди!!!... не делайте конфиг файлов типа апача,
если надо хранить хотябы 50 килобайт сильно структурированных данных

спустя 2 часа 50 минут [обр] lance10t[досье]

продолжение переписки

> В моей новой системе есть ядро, есть компоненты (DB, HTTP, etc), есть
> модули (News, Agenda, Dating, etc.). Ядро при инициализации загружает
> минимум необходимых компонентов. Для моего проекта этот минимум пока:
> DB и HTTP (обработчик $_REQUEST, $_COOKIE, $_SESSION). Модули же в
> моей системы как Вы, наверное, поняли - это нечто, напоминающее
> компоненты, но только отвечающее за какую-то особенную единицу
> информации, а компоненты в свою очередь — это чисто фунциональные
> блоки, которые могут использоваться этими модулями.

а ещё чемнибуть они отличаются?

>
> На данный момент у меня нет как в Вашей системе этапов выполнения..
> Грубо говоря, этап всего один, или же несколько иной у него вид,
> основанный на core. Пример:
>
> Есть у меня index.php, который (так не сделано пока, но так
> планируется.. Если на Ваш взгляд что-то "ошибочно", буду рад, если
> прокомментируете!!!...):
>
> 1. стартует сессию

что имеется ввиду под сессией?..
сесия выполнения или сесия в смысле $_SESSION?

> 2. инициализирует ядро:
вопросов нет

> 2.1 считывается конфигурация
тоже понятно

> 2.2 обрабатываются данные из $_REQUEST
кем обрабатываются?...
компонентом HTTP?

> 2.3 в зависимости от данных из $_REQUEST начинают подгружаться
> необходимые модули, в контексте ядра, поскольку у меня следующая
> структура:

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

>
> class core(){}
> class module extends core(){}
> class News extends module(){}

мне непонятен смысл наследования от ядра...
те разве от core ещё ктото происходит?..
если у core только один наследник то можно упростить...
class module {}
class News extends module(){}

и вобще в чем отличие модуля от компонента?...

вы понимаете что введя 2 сущности вместо одной,
вы обрекаете себя на написание в 2-е большего количества кода и 2
большее количество ошибок...

я вобще стараюсь новые сущности не вводить без крайней необходимости,...
поэтому в риооки есть "модули"...
и эти модули... они вобще не от кого ничего не наследуют и ничем
никому не обязаны.. а являются прсото php классами без предков..
просто формально названы модулями.. потому что работают по принципу
модулей.

хотя вначале я тоже напридумывал классов, но когда выкинул все это
просто дышать легче стало...

делайте как можно прощще... иначе не взлетит..

> class DB(){}
> class HTTP(){}
> Эти два класса ничего не наследуют, поскольку являются незавимимыми
> компонентами.
ок, нормально

>
> В классе core есть методы: init_component() & init_module(), которые
> инициализируют соответствующие компоненты и модули и заносят их в
> соответственные статические массивы, $components & $modules. В ядре
> также присуютствуют функции: return_component() & return_module(),
> которые попросту возвращают ссылкы на проинициализированные
> объекты, хранящиеся в этих массивах.

во во!.. я об этом и говорил!.. дубляж кода...
return_component() & return_module(), вместо одной функции!..
>
> При подгрузке модули могут обращаться к БД. Соответственно, если
> соединение с БД еще не создано, то оно будет создано.

вот кем оно будет создано?
кто создает тот и обязан уничтожать..

если вне class DB(){} создали то и уничтожать вне
а если внутри то и понятоно что внутри надо уничтожить..
чтобы не нарушать вселенскую гармонию.. и не искревлять свою карму.

>
> 3. в зависимости от параметров подгружаем нужный шаблон страницы (у
> меня он основан на xslt) и "впрыскиваем" в него данные, заведомо
> собранные из разных модулей (у меня они, данные, представлены в виде
> xml-стрима).
ок, вопросов нет.

хотя я всеже нехочу использовать xml внути системы...
потому чтоне вижу смысла в этом, php массивы позволяют выпонять функцию xml и при этом без лишних перекодировок данные->xml
те там где система общается с внешним миром, там xml уместен..
а внутри нафиг он нужен то?..
я довольно сильно вчитывался на тему xslt и разочаровался в нем, потмоу что
он както странно использует понятие "шаблон" это уже не шаблон поучается а программа для преобразования, опять получается реальное смешение кода и html'a
и при этом xslt провоцирует создавать рваные шаблоны, такие , что глядя на xslt надо напрягаться чтобы осознать какой на выходе получится html

> 4. если создано соединение с БД, то закрываем его, "убиваем"
> проинициализированные модули, а затем само ядро.
>
ну про это я написал 2-я абзацами выше...

спустя 18 дней [обр] Андрей Иванов(0/3)[досье]

Про function close_base() и

вот кем оно будет создано?
кто создает тот и обязан уничтожать..

Существует несколько паттернов работы с запросами к БД. Открывать/закрывать соединение на клиентском уровне неудобно. Когда кода 100 килобайт, это ещё приемлемо, а если запросы измеряются десятками на один хит, такой подход усложнит поддержку и развитие.
Клиентский код должен получать либо массив данных, либо итератор по массиву данных - работать с соединениями ему не стоит.

хотя я всеже нехочу использовать xml внути системы...

Ага, я тоже такого мнения придерживаюсь. XSLT тривиален только для тривиальных задач.

спустя 1 месяц 16 дней [обр] Michael Yevdokimov(0/3)[досье]

Приветствую!

Интересно, что там слышно с вашим проектом cms? ;)
Работа продолжается?
Кстати, есть ли какие-нибудь мысли на счет использования фреймворков для php?

Михаил

спустя 1 месяц 6 дней [обр] lance10t[досье]

ну вот я и вернулся, =)
с падарками

вобщем , ничего не заброшено все работает.

итак вопервых , сайт вот тут http://canadatransportation.com/
но это не самое интересное,
тамое интересное будет на Е43.

я сделал сайт для документации,
теперьо пишу докуметацию и раскрываю код

ну уже есть немного про интерфейс к БД.

http://www.e43.org/Class_dbmysql

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

кстати , помниете я в самом начале говорил про специальный протокол для общения админки и и сервера?..
так вот я его написал

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

эта идея довольно проста и черезвычайно эффективна(не при создании сайтов) а именно при создании интерент приложений

идея заключается в следующейм.

браузр воспринимаетеся сервером не как просто "неизвестно что" создающее запросы и ринимающее странички

а браузер - это тонкий клиент
когда он стартует, то подключается к серверу и начинает посылать не просто так какието GET запросы,
а посылает КОНКРЕТНО СОБЫТИЯ..
те например человек нажал на кнопку,
и на сервер уходит специальный пакет в котором описано это событие,
и тут же от сервера приходят комманды ,что нужно изменить на стороне клиента

также сервер имеет возможность считывать данные из клиента!...

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

в качетсве канала связи используется XMLHTTPRequest
но XML не применяется вобще...
клиент кодирует данные в формате php-serialize
а сервер кодирует данные в виде сырых яваскрипт обьектов
те например так {'property':'value','property2':'value2'}
которые быстро декодируются с помощю eval
также этот протокол поддерживает передачу не закодированного HTML ,
что позвояет использовать темплейты и приемы как при создании обыкновенных сайтов.

и ещё на стороне клиента используется измененный DOM
там в место дома используется дельфисская обьектная модель.
те обьекты адресуются следующим образом
mainpanel.tab_settings.property.value;

ну ладно, потом в документации подробнее опишу...

маленкая демонстрация технологии
http://files.e43.org/jstcp/

чтобы оценить всю красоту процесса рекамендую воспользоваться сниффером и посмотрите что передается на TCP уровне

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

<?php


$in['login']['value']=null;
$in['password']['value']=null;
$in['password2']['value']=null;
$in['name']['value']=null;
$in['email']['value']=null;
$loginform['main']['login']=$in;

    
if (tc_get($loginform))
{
 
   $in=$loginform['main']['login'];
   if (!$in['login']['value'])
   {
      tc_eval('balloon(main.login.login,"You should enter your login");');
      return;
   }
   
   if (!$in['password']['value']||$in['password']['value']!=$in['password2']['value'])
   {
      tc_eval('balloon(main.login.password,"You should enter password and repeat it");');
      return ;
   }
   
   if (!$in['name']['value'])
   {
      tc_eval('balloon(main.login.name,"You should enter your name");');
      return;
   }
   
   $pattern="/^[_a-z0-9-]{2,}(\.[_a-z0-9-]+)*@[a-z0-9-]{2,}(\.[a-z0-9-]+)*(\.([a-z]){2,4})$/i";

   if (!$in['email']['value']||!preg_match($pattern,$in['email']['value']))
   {
      tc_eval('balloon(main.login.email,"email is not valid");');
      return;
   }
   
        tc_eval("balloon(main.login.create,'it is a DEMO');");
   tc_write('statuspanel.innerHTML',dump($in,1));
   
   
}



?>
спустя 17 часов [обр] Александр aka Efreeti(3/111)[досье]

Ну наконец-то, я уж заждался;)

но XML не применяется вобще...
а сервер кодирует данные в виде сырых яваскрипт обьектов
те например так {'property':'value','property2':'value2'}

Это не очень хорошо, вам будет сложно организовать работу с flash'ом.

те например человек нажал на кнопку,
и на сервер уходит специальный пакет в котором описано это событие,
и тут же от сервера приходят комманды ,что нужно изменить на стороне клиента

А не слишком ли много будет событий? Да и тормозить будет.
Тем более, как вы будете обрабатывать onmouseover/move/out? Будете на каждый сдвиг мышки слать запрос?

маленкая демонстрация технологии
http://files.e43.org/jstcp/

Не поддерживаеться back с браузере (для примера смотрите http://www.backbase.com/)

Но в любом случае "пеши есчо". Особенно маны.

спустя 1 час 7 минут [обр] lance10t[досье]
Это не очень хорошо, вам будет сложно организовать работу с flash'ом.

а нафига в интернетприложении флеш?...
я то и на сайтах фреш не люблю, а в ИП и подавно...

А не слишком ли много будет событий? Да и тормозить будет.

вовсе не много и тормозить не будет,
события передаются не все! а избранные..

те со сотроны сервера в НЕКОТОРЫЕ HTML элементы встраиывается функция ONCLICK="server(event)"
и серверу будет послано одно единственное важное сообщение,

вот посмотрите на форму ответа на Xpoint
тут 2 кнопки "посмотреть что получится" и "дбавить сообщение" чтобы это корректно работало надо всего 2 события,...

Тем более, как вы будете обрабатывать onmouseover/move/out? Будете на каждый сдвиг мышки слать запрос?

как вы уже догадались - никак не буду обрабатывать..
потоу что нафиг это не надо...

но если будет обязательно НАДО тогда будет сделана "хранимая процедура JS" на стороне тонкого клиента. =)

Не поддерживаеться back с браузере

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

спустя 56 минут [обр] Александр aka Efreeti(3/111)[досье]
мне кажется что пролему с бэком можно обойти довольно просто, при каждм событии грузить каконибуть мусор в Iframe

Зачем так извращаться. Лучше сделайте как на приведённой выше ссылке (через якоря).

а нафига в интернетприложении флеш?...

А вот хотят некоторые, что бы на флеше. И что бы из базы таскало. Что, откажете?
И это, кстати, может быть не сайт, а игра.

спустя 2 часа 18 минут [обр] lance10t[досье]
А вот хотят некоторые, что бы на флеше. И что бы из базы таскало. Что, откажете?
И это, кстати, может быть не сайт, а игра.

ну а какая тут проблема то?..

можно тожесамое что я для браузера сделал повторить для флеша.. и писать это вовсе не много будет.

те главное требование для реализации чтобы можно было

  1. докачивать куски флеша в уже загруженный флеш - [OK]
  2. декодировать некий тескт в родные обькеты или ассоциативные массивы флеша - [OK]
  3. обратно кодировать "событие" в формат понимаемый сервером - [OK]

те проблем то нету.. вот кодировщик. http://www.sephiroth.it/test/unserializer/

у меня в HTML новые куски интерфейса, создаются динамически на сервере и тутже посылаются клиенту...

а во флеше это можно заменить посылкой урла откуда скачать кусок интерфейса.

вот помните демку что я тут привел, там кнопка есть "создать пользователя"

<?php
require_once('templates.php');
tc_write('main.innerHTML',$rte->render($rte->select('user/new'),1));
?>

это весь код который нужен чтобы переключился экран на форму создания пользователя .
этот код высылает пакет с body наполненным HTMLом вслучае флеша там будет просто урл в теле пакета.

спустя 2 часа 58 минут [обр] lance10t[досье]
вот начал делать доки по протоколу..
http://www.e43.org/Jstcp
спустя 19 дней [обр] Андрей Анатольич+(0/46)[досье]
Прошло уже 16 месяцев с начала разработки )
Очень интересная тема!
Желаю успехов!
спустя 29 дней [обр] Sergous[досье]

lance10t[досье]

  1. КЛИЕНТ-СЕРВЕР(КС)?

изучая внутренности разных CMS я все время обрашал внимание на то что 60-70% кода - это не само ядро сайта которое занимаетя выводом странички а именно административный интерфейс и все что с ним связанно.

и эта админка портит всю красоту и архетектуру ядер.

и усложняят модификацю и расширение ярдра новыми функциями.

и я подума а почемубы не сделаьть KC?

пусть в ядре вобще не будет никакой админки!..

пусть ядро просто обрабатывает команды как консоль...

например.. для того чтобы переименовать например какойто заголовок.

пусть php-админка(на сервере) не занимается рисованием интрфейса в тольео сидит и ждет команды

типа

ID-команды "12345"

кому "модуль-контент"

действие "переиминовать"

ID "123"

name "новое название"

обработать такой запрос совершенно не трудно

если все что надо "вернуть" админке так это только

ID-команды "12345"

статус "выполненно успешно"

при таком подходе.. можено в ядре-админке заниматься "чистым програмированием"

не распыляясь на вывод кнопочек, полей ввода, и прочей лабудой.

выгоды в виде упрощения серверной части очевидны?..

помоему да.

а чтоже по поводу клиента?..

что это будет?

...

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

на келиентскиц комп.

посылая на сервер запросы типа

ID-команды "12346"

кому "модуль-контент"

действие "получить данные"

ID "123"

name

админка прочсто вернет одну строчку с давными...

а JS уже отрендерит все как надо.

и предоставит пользователю интерфейс внешне похожий на windows на простой explorer

это чтобы пользователю нидайбох не пришлось чегото нового учит и привыкать.

у этого решения есть большой минус.

этор трудно сделать на JS ... трудно но можно!..

и я это сделаю. =).

в следующих главах..

  1. модульная архитектура php-ядра
  1. особенности кроссбраузерного JS
  1. проблемы с реализацией JS клиента
  1. СSS на грани возможностей.

Большинство из перечисленного есть в закрытой CMS TreeGraph и ее дальнейшее развитие Morex.

Пользую Morex на работе каждый день и изучил слабые и сильные стороны. Одно время сам хотел сделать еще более продвинутый аналог под GPL, закончилось концепцией проекта и архитектурой основных модулей. Код писать начали, но бросили из-за нехватки времени с надеждой когда-нибудь продолжить.

спустя 4 дня [обр] lance10t[досье]

по поводу КЛИЕНТ-СЕРВЕР(КС)

вот я тут делаю сейчас админку , именно как писал в начале этого топика

и фактически КС тут реализован по полной программе =) только это уже браузерный тонкий клиент но работает именно как КС.

http://ros.e43.org/system/admin/

вобщем это будет не просто админка а просто платформа для аццких интернет приложений..

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

спустя 26 минут [обр] lance10t[досье]

почитал про морекс,.. у меня немного другая идеалогия,..
в моем варианте создается виртуальная "файловая" система..
ну как в виндуосе..
один и тотже эксплорер может как зайти на фтп так и по диску ходить, также как и по сетевому окружению,..
это 3 очень разные штуковины - а интрефейс один, и все выглядет как одна общая Файловая система..

я делаю также.. будет один "эксплорер" и - плагины для разных нужд, например туже гостевую книгу можно вывернуть и представить как папку в которой файлы-сообщения...

главное чтобы был этот самый переходничек окоторый реализует к гостевой книге доступ по принципу файловой системы.

спустя 1 день 22 часа [обр] lance10t[досье]
вот интересно получается , я сижу значит пищу скрипты, и переодически страничку обновляю чтобы протестировать,
и ктото весь день мне окна туда-суда перетаскивает, ну я там сделал чтобы система запоминала расположение окон, а пока юзеров нету то расположение меняется вобще для всех кто видит админку,..
вобщем весь день ктото там окна шурудит, и хотьбы ктото отписал как работает система...
мнеже интересно протокол тормазит или приемлимо работает, ?...
спустя 2 месяца 12 дней [обр] im4LF[досье]

Интересуюсь темой менеджера опций. Реализовал подобный, описаному здесь.
Каждый об'ект имеет field_set_id — набор доп. полей.
В аттаче схема БД, хранящая данные.


Но вот какие вопросы возникают
если необходимо организовать сортировку по какому-то доп. полю
этот вопрос решается:

object
id
data
add
id
object_id
name
value

запрос, сортирующий по определенному доп. полю выглядит примерно так:

SELECT `object`. * , `add`.`value` AS `price`
FROM `object`, `add` 
WHERE `object`.`id` = `add`.`object_id` AND `add`.`name` = 'price'
ORDER BY `price`

но этот запрос не позволяет сразу же вернуть еще и все доп. поля


Еще есть одна идея реализации доп. полей — для каждого field_set создавать отдельную таблицу в БД. Создать единый обработчик этих таблиц (option manager), тогда проблема с сортировками отпадает + все доп. поля при сортировке можно будет вытащить за один запрос.

спустя 12 часов [обр] lance10t[досье]

im4LF[досье]
вобще по поводу менежера,..
мне кажется что менежер штука хорошая но не быстрая =)..
те когда сайт развивался менежер - был просто спасением, я добовлял новые параметры на лету,
но теперь сайт подвергается бОльшим нагрузкам чем ранее,..
и работая с менежером мне так и не удалось както одним запросом все вытаскивать,..
те при показе например спика компаний происходит направаляющий запрос который вытаскивает
какбы костяк информации, те те поля по которым идет сортировка и выборка вобще,
и только после того как ключевая информация получена, я делаю второй запрос, котороый обращается к этим таблицам и вытаскивает всю шелуху...

те смотрите что получается,

предположем надо вывести 100 компаний.
данные о котороых хранятся в менежере,
и каждая компания имет по 10 "свойств"
например
там телефон, сайт, емеил, итп...

для этого делаем 2 запроса,

  1. поиск и сортировка нужных нам копмпаний,
  2. выборка из таблиц менежера,

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

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


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

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

так вот когда будет адимнка, тогда уже будет похоже на цмс =)..

спустя 1 день 17 часов [обр] im4LF[досье]

предположем надо вывести 100 компаний.
данные о котороых хранятся в менежере,
и каждая компания имет по 10 "свойств"
например
там телефон, сайт, емеил, итп...

для этого делаем 2 запроса,

  1. поиск и сортировка нужных нам копмпаний,
  2. выборка из таблиц менежера,

ну по поводу 2х запросов

SELECT `object`. * , `a1`.`value` AS `price`, `a2`.`value` AS `count`
FROM `object`, `add` AS `a1`, `add` AS `a2`  
WHERE `object`.`id` = `a1`.`object_id` AND `a1`.`name` = 'price' 
AND `object`.`id` = `a2`.`object_id` AND `a2`.`name` = 'count' 
ORDER BY `price`

Это позволяет делать накладывать условия выборки и по доп. полям.
Тесты производительности пока не делал (если будет 10/50/100 доп. полей).

Если же будут тормоза, то подумаю над реализацией менеджера через доп. таблицы — для каждого "набора полей" своя табличка, сделать единый интерфейс управления "наборами полей" (расширение аттрибутов через alter table). Каждый аттрибут будет хранится в столбце, что избавит от лишних AND в селектах. Про ограничения на количество таблиц в БД я не слsifk (кроме ограничений ФС).
Данная схема не решит проблемы, когда у об'ектов одного класса переменное количество аттрибутов.

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

Вы все же решили отказаться от идеи ClientSide приложения для админа?
C момента реализации админки через ClientSide ПО (это было довольно давно) еще не нашел плюсов в сторону back-office, кроме как возможночсть редактирования без скачки доп. ПО.

спустя 1 день 22 часа [обр] coldseed[досье]

im4LF[досье] Чисто с точки зрения оптимизации работы SQL-сервера, зачастую удобно пользоваться хранимыми процедурами и "View"-шками для работы с выбираемыми данными.

lance10t[досье]
Только увидел эту тему, супер... так долго с таки энтузиазмом продолжать развивать идеи и подходы, при этом еще выбирая оптимальные технические решения. Так держать!

Кстати, а что с идеей коммерческой CMS как было в самом начале?

Реализация ClientSideSoft имеет конечно преимущество в плане скорости работы на клиенте, что впрочем "размывается" на современных компах... очевидный плюс решения как Web-интерфейса - юзабилити, поскольку проще построить интерфейс с любым необходимым дизайном и логикой визуализации. С той точки зрения что для этого уже есть готовый браузерный движок, отображающий разметку, существенно снижает количество головняка;)

  1. Насчет таблиц option manager'а. Сейчас сам начинаю только думать над решением подобной проблемы. Хочется конечно какой нибудь оптимальный (без ALTER TABLE) и универсальный (под максимум задач) подход.
  1. И еще монументальный вопрос: что в конечном итоге представляет ваша система как единое целое? это CMS, какой то особый API, framework или что то еще? Есть какая то схема системы?
спустя 1 день 9 часов [обр] lance10t[досье]

im4LF[досье]

ну по поводу 2х запросов

SELECT `object`. * , `a1`.`value` AS `price`, `a2`.`value` AS `count`
FROM `object`, `add` AS `a1`, `add` AS `a2`
WHERE `object`.`id` = `a1`.`object_id` AND `a1`.`name` = 'price'
AND `object`.`id` = `a2`.`object_id` AND `a2`.`name` = 'count'
ORDER BY `price`

Это позволяет делать накладывать условия выборки и по доп. полям.
Тесты производительности пока не делал (если будет 10/50/100 доп. полей).

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

и дело вот в чем,

  1. один большой запрос не обязательно окажется быстрее 2 простых.
  2. даже если он окажется быстрее то (в 80% случаев) не не сильно на много
  3. 2 маленьких запроса легче понять, и исрпавлять в них ошибки, и менять чем один большой и сложный запрос.
Если же будут тормоза, то подумаю над реализацией менеджера через доп. таблицы — для каждого "набора полей" своя табличка, сделать единый интерфейс управления "наборами полей" (расширение аттрибутов через alter table). Каждый аттрибут будет хранится в столбце, что избавит от лишних AND в селектах.

=) знаете есть одна замечательная англоязычная поговорка,
"Keep it simple!" её часто перефразируют в "Keep IT simple!"
что звучит уже как "делайте ИТ проще" , я придерживаюсь такой идеалогии что надо делать как попроще,..
и с первого взгляда ваше предложение выглядет как черезмерное усложнение,..
я уверен что существует более простое и эффективное решение.

Вы все же решили отказаться от идеи ClientSide приложения для админа?
C момента реализации админки через ClientSide ПО (это было довольно давно) еще не нашел плюсов в сторону back-office, кроме как возможночсть редактирования без скачки доп. ПО.

по факту, да приложение не написано, но признаюсь меня не покидает мысль о его написании,.. и чем больше я парюсь с js тем больше мне хочется сесть за делфи.
но!
понимаете тут есть одно больше но, =) когда я начинал писать все это я был
матерым пользователем виндоус 2000 и никаких других альтернатив не признавал,
но теперь я прекрасно работаю под suse 10.1 котороая переплевывает ещё не вышедшую висту, .. =)
я думаю что через пару лет рынок ОС будет реально рвать на куски, когда линукс покажет свою мощь,.. шас происходит довольно большая миграция на линукс(в качестве десктопа) в среде технарей,и это помоему просто предвещает больщие перемены,..
ведь например пару лет назад линукс был для меня совершенно не юзабельный как десктоп,.. а шас наоборот - отлично!.
так вот, я к чему это все говорю,.. к тому что надо уже шас думать как бы так клиент написать чтобы он и под линуксом и под виндой работал,..
а ксул я пока не хочу вспоминать, уж слишкмо много горя я с ним хлебнул,..
эх надо поискать Kylix и посмотреть может можно чтото с ним сделать.

coldseed[досье]

Кстати, а что с идеей коммерческой CMS как было в самом начале?

переход на линукс это не только смена ос но и смена идеалогии,.. =)
когда цмс будет в приличном состоянии все будет открыто и бесплатно,

И еще монументальный вопрос: что в конечном итоге представляет ваша система как единое целое? это CMS, какой то особый API, framework или что то еще? Есть какая то схема системы?

это скорее framework набор классов,
вобще, ядро ничем кроме ввода вывода не занимается, вся работа выполняется модулями,
http://files.e43.org/kernel.png

а ядро только транспортирует данные от модуля к модулю и координирует их работу,
лучше всего рассмотреть на живом примере, вот например сайт
http://canadatransportation.com/
сейчас рассмотрим как получилась первая страничка,
вот трейс выполнения:

    [0] => kernel start
    [1] => actual config loaded
загрузка кнофига и перекомпиляция настроек если необходимо.
    [2] => kernel-module initialization - это единственный модуль котороый имеет доступ к переменным ядра,поскольку модули могут обращаться друг к другу, то както взаимодействовать с ядром они могут через такой модуль посредник.

загрузка обязательных модулей
    [3] => AddModule sql - просто класс обстракции бд
    [4] => AddModule log - класс для ведения логов
    [5] => AddModule locations
- класс который меняет среду выполнения, те это такой модуль который смотрит на REQUEST_URI и понимает что нужно сейчас будет загрузить, это замена GET в этой CMS GET не применяется вобще.
а на сайте каждый урл имеет свой номер, номер кодируется в виде букв например
http://canadatransportation.com/Alberta_trucking_companies_AwA.htm
"AwA"- обозначает какуюто цифру, 4 буквы хватает чтобы закодировать 65 тысяч урлов,
а 8 букв вобще на много урлов хватит, ...
все урлы регистрируются системой изнутри, поэтому хакеры не могут сами создавать совои урлы =). и таким образом както манимпулировать системой,..
и вобще это позволяет точно сказать какие странички есть в системе,
присваивание номеров облегчает кеширование, и вобще имеет массу плюсов.
например позволяет переименовывать страницы и делать грамотные редиректы,..
или например корретный отклик на удаленные страницы, а не просто 404.
и в принцепе в базе можно узнать все связи какя страничка на какую сслается,..
и сколько ссылок на каждой странице.

    [6] => AddModule metadata
модуль для создания правильных метаданных кук и Html Meta и вобще заголовков

    [7] => AddModule session
модуль - это просто класс для работы с сесиями,хранимыми в бд.
используется проверка IP чтобы предотвратить атаки основанные на краше кук.

    [8] => AddModule html
модуль который берет на себя некоторые типовые задачи создания HTML,
    [9] => AddModule modloader
этот модуль умеет подгружить динамические модули,
    [10] => AddModule config
модуль для всеяких действий с конфигрурациией сайта,

это большой список всяких прикладных модулей которые просто числятся в системе, но они будут загружены по первому требованию.
    [11] => DynModule bizdirectory
    [12] => DynModule templates
    [13] => DynModule virtual
    [14] => DynModule image
    [15] => DynModule webmail
    [16] => DynModule login
    [17] => DynModule metadata
    [18] => DynModule thumbnail
    [19] => DynModule seo
    [20] => DynModule cdirectory
    [21] => DynModule viewsource
    [22] => DynModule console
    [23] => DynModule content
    [24] => DynModule listing
    [25] => DynModule sitemap
    [26] => DynModule fs
    [27] => DynModule form
    [28] => DynModule rjabber
    [29] => DynModule dynfunc
    [30] => start of system run cycle
вот начало этапа 1 , каждый этап имеет какоето названия чтобы было понятнее
    [31] => start executning level (boot)
    [32] => RUN module[sql]->[connect]
только сейчас установили соединение,
    [33] => RUN module[locations]->[shift_location]
модуль разорбрал урл и заргузил нужную конфигурацию из базы(либо из файла)
    [34] => RUN module[modloader]->[run]
динамический загрузчик прочитал конфигурацию и загрузил пачку динаммческих модулей
    [35] => start executning level (system)
в этот раз никакой модуль не захотел быть загружен на этапе system, это потому что я не залогинен а такбы модуль сесии наверное тут бы сработал.
    [36] => start executning level (automatic)
запуск прикладных модулей
    [37] => RUN module[templates]->[run]
загрузка главного шаблона
    [38] => RUN module[templates]->[template_engine]
включение перехватчика HTML который будет собирать весь HTML произведенный разными модулями, и будет распихивать его в главный шаблон в нужные места.
    [39] => RUN module[province_directory]->[run]
модуль вывел сипсок провинций,
    [40] => RUN module[templates]->[template_engine]
а движек темплейтов перехватил HTML
далее будут работать разные модули,
но движек будет автоматически запускаться ядром после каждого из них,
и ядро будет перенаправлять аутпут каждого модуля во внутрь template_engine.
    [41] => RUN module[console]->[run]
    [42] => RUN module[templates]->[template_engine]
    [43] => RUN module[category_directory]->[run]
    [44] => RUN module[templates]->[template_engine]

    [45] => start executning level (shutdown)
    [46] => RUN module[seo]->[run]
когда прикладные модули закночили работу, запускается модуль который подправит
страничку чтобы она стала оптимизированна для поисковиков.
    [47] => RUN module[templates]->[template_engine]
    [48] => RUN module[metadata]->[send_metadata]
затем высылаются метаданные
    [49] => RUN module[templates]->[template_engine]
    [50] => start executning level (end)

    [51] => RUN module[templates]->[flush_page]
и в самом конце происходит выброс уже готовой страницы.
(но опятьже он не отправляется клиенту, физическая отправка происходит только вконце этапа, самим ядром)
    [52] => RUN module[session]->[save]
сохраняются какието изменения в сесси (если они вобще были)
    [53] => RUN module[metadata]->[send_headers]
отправка хеадеров,
    [54] => end of system run cycle
тут ядро завершает свою работу и какраз перед этим был вывод странички клиенту

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

те это CMS построенный на фреймворке,

спустя 15 часов [обр] coldseed[досье]

ну да, по сути настраиваемая программистом CMS на базе существующего framework'а.

У нас тут просто тоже стоит горячо проблема создания (и разграничения как программных единиц) продуктов таких уровней как:

  1. .framework (нижний уровень, контроль выполнения, подключения библиотек и программных элементов)
  2. .core (ядро, отвечает за информационные потоки между модулями и разграничение прав "процессов"). Нами создается несколько разных "ядер", работающих в пределах одного framework'а. Они имеют разные возможности и по разному оптимизируют информационные потоки в зависимости от конкретной задачи.
  3. .CMS (набор модулей для работы с конкретными блоками вроде новостей, статей и так далее.)
  4. .solution (решение. на базе всего вышеперечисленного, т.е. скажем, если смотреть на новости, то сюда входит решение для работы с новостной лентой, в которое входит соответствующий блок CMS, а также визуальный интерфейс для работы с таким блоком и механизм настроек соответствующего блока CMS)
  5. .business solution (бизнес-решение. комплекс, построенный на всех вышеперечисленных механизмах, оптимизирует работу какого то конкретного бизнес-процесса, автоматизируемого сайтом)
  6. .project (проект, в нем может использоваться сочетаний нескольких бизнес-решений. Самый верхний уровень. Получается в результате простой настройки нижележащих уровней)

все блоки от 1 до 6 построены "друг-на-друге"... т.е. "6) проект" содержит себе все необходимые "business solutions" для решения конкретных поставленных задач и так далее ниже по цепочке...

Так вот...
Планируется ли ваша система к доработке тоже до некоторого законченного состояния, которое могло бы быть использовано студиями и/или ИТ-отделами заказчиков...

или даже просто контент-менеджерами компаний (если продукт представляет готовое решение)?

спустя 8 дней [обр] lance10t[досье]

@Планируется ли ваша система к доработке тоже до некоторого законченного состояния, которое могло бы быть использовано студиями и/или ИТ-отделами заказчиков...@
# .solution # .business solution # .project
я такими понятиями вобще не оперирую,
но система разрабатывается именно как професиональный инструмент,..
те , я недавно понял почему так трудно делать сайты на этих распространенных цmс,..
потому что изначально они делаются для людей которые ниче не знают в пхп и хотят себе сайт приличного качества,
те например таже мамба, у них там девиз типа "сила в том чтобы попроще"
а кому спрашивается попроще??.. тем кто не знает как писать на пхп?..
это да.!.. для них эти скрипты самоте то что нужно,..
а веб компаниям и професионалам нужно другое,..
мне например мамба мешает частенько, там например статистика встроена, какаято убогая, нафига она там поумолчанию ставится?..
може я бы мог клиента развести и за дополнительные бабки ему включить эту статистику,..
и вобще в мамбе много лишнего, все сделано на тормозном гуи...
надо человеку формочку поменять, а у нас с ним контракт например что изменения 20 баксов в час..
так я не хочу тыкать мышкой в админке, она мне не нужна,..
те все это меня порядком достало,..
и система будет(уже есть) такая модульная что если у человека сайт примитивный на 10 страниц то система и без бд заработает, просто я не хочу тратрить время на создание очередной базы для ханения 10 страниц контента,..
также поскольку все в системе выражено через файловую систему, я сделаю скриптовый язык, чтобы можно было писать инсталяционные скрипты,
те в идеале я вижу работу с системой селдующим образом:

надо сделать сайт, и есть стартовое задание,

  1. копирую пхп скрипты,
  2. все никакой инсталяции все сразу работает, ядро запущено никаких модулей, только консоль(которая через браузер вызывалась)
  3. я выбираю подоходящий шаблон для сайта ,(не дизайн а шаблон, например "тупой сайт из 10 страниц")

шаблон выглядте так:

addModule meta // просто метаданные
addModule content // модулть для статей,
addModule gzip // сжатие
addModule forms // форма мылилка
addModule editor // гуи редактор для контента
addModule simpleauth //простой аус без сесий, чтобы можно было логинится и редактировать
// указал какие модули понадобятся в сайте

"my stupid web site"  >> module/meta/title // записал переменную которую будет юзать модуль метаданных
cd /module/content  // перещел во внутрть модуля контент
mkdir aboutus // создал статью с урлом "aboutus" 
file 'artcle1.html' >> aboutus/content  //содержимое вытянул из файла  artcle1.html
"About Us" >> aboutus/title //установил заголовок
cd /module/menu //зашел в модуль меню
mkdir mainmenu // создал пусте меню
cd mainmenu
ln -t /module/content/aboutus "Click here to read about us"  // создал ссылку которая ссылается на эту статью

понимаете?. вот таком духе, сделть полностью скрипт который будучи запущеный с консоли создаст сайт,
и если надо чето быстро поправить то в консольку быстро сбегал и поменял что надо,,,.
скрипт этот будет видимо гибридом между SQL и SHELL и наверно также и BATCH команды будуь поддерживаться...


конечно гуи будет , я его тоже делаю =)..
пока все мне пора ити, я скоро ещё чето напишу!

спустя 4 часа 28 минут [обр] lance10t[досье]
небольшая заметка по поводу, гуевых компонент,
я написал 2 компонента, дерево и таболицы, но я думаю что это было ошибкой,..
надо перепесать и сделать 1 компонент - таблицу-дерево, ..
типа такого
http://img135.imageshack.us/img135/3872/screenshothb1.png
видите это гибрид и таблица и дерево и если надо он может работать и как простое дерево и как обычная таблица,..
PS заодно на линукс полюбуйтесь =)
спустя 11 часов [обр] coldseed[досье]

Ну на самом деле то о чем я говорил тоже самое. Разработчики используют то, что им нужно на более низком уровне, чем те, кто хочет получить сайт, не зная php или asp.net. Совершенно верно, что для разработчиков, которые разбираются всегда удобнее какой нибудь всеобъемлющий API, но для пользователей удобнее GUI. Причем GUI, "натянутый" сразу на ядро пользователи использовать не смогут, т.к. без разницы где по сути выставить системный параметр, непонятный юзеру - в админке или в файле настроек вручную.... для этого и делаем вышележащие уровни "бизнес-процессов", "решений" и так далее... т.е. пользовательские контексты.

А на нижнем уровне принцип такой - все, что нельзя сделать на 100% универсально, сильно не запариваясь, или хотя бы близко к универсальному - лучше вообще оставить для ручного изменения разработчиками.

Я думаю, дальнейшим развитием вашей системы вполне возможно и такое

спустя 29 дней [обр] Bers[досье]
Здравствуйте! Отличный топик! 8)
Читаю его вот уже два месяца. Мне необходимо написать свою ЦМС (к тому же и пхп я изучать начал исключительно в связи с ее написанием, то есть не так давно) Поэтому возникает множество вопросов.
 За основу ЦМС была взята предложенная Вами архитектура, на мой взгляд она очень хороша в плане расширяемости и т.д. А так же я реализую некоторые идеи выше изложенные. Уже реализовано:
- ядро с кучей функцией, получилась операционная система для модулей - факт 8), у каждого модуля своя память, уровни привелегий на доступ к системным функциям и тд
- модуль по работе с урл, урлы разгребает, составляет план загрузки модулей на сайт и тд. идея с регистрацией урлов отличная,потом реализую обязательно
- модуль про работе с базой данных mysql
- в догон написан менеджер опций и класс реализующий идею sql-кварка
Пришла очередь работы с шаблонами 8)
Вы собирались описать работу автосборщика данных(то есть это именно тот механизм который понимает куда какие данные заливать и в какой последовательности, откуда их брать и тд, и куда их собственно заливать как оформлена структура мекета страницы), и что-то этот момент был упущен. Если есть возможность опишите его работу, да и работу движка шаблонов в целом (за исключением уже описанного выше конечно же).
спустя 1 день 11 часов [обр] lance10t[досье]

Bers
мы сделаем ещё лучше...
вот исходники , это мой движек темплейтов, в режиме отдельностоящего модуля.

http://files.e43.org/sources/templates.tar.gz

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

для работы вам может понадобится функция file_put_contents
которую можете взять тут.
http://files.e43.org/sources/systemcases.php

когда вы заинклудите главный файл из своего скрипта то создать инстанс движка
надо вот примерно так
$ite=new templates('templates/','var/templates/');
первый параметр - это папка где искать темплейты (HTML).
а втотрой это папка куда скрипт будет складывать скомпелированные куски(естественно что надо право на запись).

учтите это, девелоперская версия, там есть законченные и нормально работающие куски и есть несколько мест которые в процессе написания....
так вот там есть методы которые касаются form так вот с ними не заморачивайтесь, можете грохнуть смело,..
все что нужно это select и render.
самое ценное там - это компайлер.
он разбирает HTML на самые мельчайшие составляющие...
и запускает необходимые плагины.
и потом как плагин чтотоs в хтмл поменяет
компайлер обратно соберет это в HTML.

примеры реальных темплейтов которые крутятся на сайте можете брать отсюда
http://www.canadatransportation.com/mod/cdirectory/templates/

по поводу автосборщика, он очень маленький
вот 80% его кода, тот самый код который определяет что куда попадет.
не в читывайтесь в этот код, он просто чтобы показать что его правда не должно быть много.

      if (isset($conf["module"][$source['instance']]['rawoutput'])&&$conf["module"][$source['instance']]['rawoutput']=='on') 
      {
         return ;
      }
      elseif (
      isset($bind[$source['instance']]))
      {
         @$this->template[$bind[$source['instance']]]["HTML"].=$output;
         return false;
      }
      elseif (
      isset($this->template[$source['instance']]))
      {
         @$this->template[$source['instance']]["HTML"].=$output;
         return false;
      }
      elseif (
      isset($bind[$source['name']]))
      {
         @$this->template[$bind[$source['name']]]["HTML"].=$output;
         return false;
      }
      elseif (
      isset($this->template[$source['name']]))
      {
         @$this->template[$source['name']]["HTML"].=$output;
         return false;
      }
      elseif (
      isset($bind['default'])
      &&isset($this->template[$bind['default']]))
      {
         @$this->template[$bind['default']]["HTML"].=$output;
         return false;
      }
      else 
      {
         
         // AXTUNG !!!... hiden module execution
         return false;
      }
      
      


   }

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

когда ядро создает инстанс этого сборшика
то сборщик говорит ядру

      $core['kernel']->controls('execute run');
      $core['kernel']->controls('cover each automatic template_engine');
      $core['kernel']->controls('cover each shutdown template_engine');
      $core['kernel']->controls('execute flush_page end');

суть в следующем автосборщик с помощю строк 2 и 3 заставляет ядро перенаправлять отпут от каждого модуля
к нему в метод template_engine
в данном случае в template_engine передается некая переменная $source - это не просто строка с HTML-ом.
это массив , в котором содержится описание что это за модуль насоздвавл аутпут, с какими он параметрам был запущен,... и конечно сам аутпут тоже прилагается.

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

когда модуль был запущен первый раз тогда он в память загружает главный шаблон сайта,..
$this->template=$this->select($conf['template'][$conf['UseTemplate']]['path']);

//эта конструкция $conf['template'][$conf['UseTemplate']]['path']
//она просто возвращет строку к текущему шаблону для сайта,
//например "/templates/currenttheme"

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

например в главном шаблоне я могу написать
<head _display='/module/metadata'></head>
так вот, когда(неизвестно когда именно) сработает модуль который называет сам себя metadata то , template_engine получет все что он создал,.. и увидет что типа переменная такая есть и аутпут туда и присвоит,..

есть ещё и другие правила присвоения, я могу наприсать в конфиге, что если например данных нету то по умолчанию - писать надо в переменную body.
можно вобщем какбы знаки регулирующие выставить, что какой модуль в какую переменную отправится...
может быть я в шаблоне определю например 3 зоны, left right center
тогда и в биндах пропищу куда именно перенаправлять аутпут,
например
bind mainmanu left
вот и меню попадет в левую зону..
примерно такая логика,. и она не сложенее чем код который я привел выше...
а в самом конце ...
страница флюшится вот так.

   function flush_page()
   {
      $this->render($this->template);
   }
спустя 4 часа 59 минут [обр] Bers[досье]

lance10t[досье]
Круто! 8) Теперь точно есть обильная пища для размышлений :) Спасибо!

Кстати, такой вопрос, судя по коду Вы до сих пор используете два глобальных массива conf и core, почему Вы не скрыли их в controls? Тогда можно было бы ввести разраничения на доступ к разным данным для модулей, например, и "хакерский" модуль не смог бы получить доступ к важной системной информации без особых на то прав (а права всех модулей которые ставит в очередь на загрузку модуль URLов савсем не особые :) (в моем варианте загрузку модулей осуществляет ядро)

спустя 1 час 24 минуты [обр] lance10t[досье]
да я вот подумал а. что такое?
""хакерский" модуль" это что значит???...
ктото вам на сайт зайдет и зальет туда модуль, и конфиг поправит чтобы он загрузился??..
те... я думаю что опасность для сайта исходит не от мифического хакерского модуля,..
а от XSS от SQL иньекций,.. от левых переменных подсунутых системе извне..
вот я сконцентрировал усилия по защите в облее горячих точках чем "хакерский модуль" =)
спустя 22 минуты [обр] Bers[досье]
lance10t[досье]
8)
Под хакерским модулем я подразумеваю, тот модуль, в котором так или иначе появилась какая то уязвимость, то есть какой-то прокол в нем есть, не важно какой, понятно что залить свой модуль исправить конфиг - это круто 8)
(Я просто исхожу из возможности, что в систему внедрен каким то образом инородный код. в принципе может в приложении к цмс это звучит наверно странно, просто я никогда не разрабатывал цмс раньше поэтому и подход такой 8)
Просто интересно, почему при нелюбви к GLOBALS Вы все-таки используете глобальные массивы, хотя их сокрытие практически вытекает из предложенной схемы хранения данных в функции controls.
спустя 2 дня 21 час [обр] lance10t[досье]

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

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

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

те это порочный метод, и порок теперь в том что если я хочу менять модуль метаданных, то мне придется ити в совершенно другой модуль,!!! модуль компаний и менять там метод записи во внешний массив.

так вот когда уже было написано 70% сайта я нашел ответ и частично его опробовал,..
и наверно буду его использовать..
метод заключается в следующем - в широковещательном сообщении...
те модули не пишут конкрето в какойто определенный модуль!..
они пишут свое мнение в некий общедоступный массив, но это не конфигурационный массив всей системы..
=)..
те я назвал этото модуль-массив - essence(суть)
у каждой станички есть суть,.. вот эту суть они туда и пишут,..
например на xpoint суть этой страницы что это thread 28649 "Пишу CMS (мысли вслух, концепции, идеи, решения)"..
и эта информация должна быть доступна всем модулям системы..
а не записана в память кактогото одного модуля..
те когда будет работать тот кусок кода который выводит все эти сообщения...
он должен записать в глобальный массив - примерно следующее
$essence['thread']['id']=28649;
$essence['thread']['title']="Пишу CMS (мысли вслух, концепции, идеи, решения)";
$essence['thread']['keywords']="Пишу CMS (мысли вслух, концепции, идеи, решения)";

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

вот например на транспортном сайте, есть разные страницы с разной сутью
суть но "сутей" немного

  1. провинция
  2. категория
  3. город
  4. компания

все, все многообразие страниц происходит от комбинациий этих сутей,.
есть странички про

  1. провинция
  2. категория
  3. провинция и категория
  4. провинция и город
  5. провинция, город и категория,
  6. компания, провинция, город, категория.
  7. поисковый термин.

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

спустя 4 часа 44 минуты [обр] lance10t[досье]

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

  1. выполнение произвольного sql - инекция.

(приводит к полному контролю над сайтом)
потому что можно завести нового юзера с административными правами.

  1. эскалация привилегий, - подмена переменных,..

(приводит к выполнению некоторых администранивных функций)

  1. upload атака,- залили файл и запустили

(тоже полный контроль)

  1. xss - атака направленная на администратора.

(очень подло, но теоретически имеет тотже эффект что 2 и иногда 1)

атака на sql бывает в тех случаях когда в коде создается sql запрос,..
$sql='select * from content where id='.$id;
...
чтобы избежать такой атаки ,90% запросов в системе происходят через интерфейс к базе,..
те через этото класс который я написал(про него уже рассказывал)
$sql->content['id']=$id;
$result=$sql->get();
вот видите, конструирование запроса, осуществляется классом..
и он защищен,.. дело в том, что он знает какой тип данных у какого поля.
и сам проверяет, и если это строка то он слделает полное квотирование.
те вероятность пропустить какуюто глупую ошибку - снижается.
а оставшиеся 10% запросов, я могу хорошо проработать, ну зная что именно это и есть слабое место.

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

те в системе например все действия осуществляются из index файла,.
те если запускать любой другой файл - это безопасно, потому что во всех файлах - только декларации классов,
и никаких реальных вызоывов не осуществляется.
те даже нет проверки
if (!defined('SYSTEM')) die ('access denied');
потому что это не страшно если будет заниклужен просто класс.

про пункт 3, какнибуть потом напишу потому что это вобще отдельная история..

по поводу пункта 4, я стараюсь сделать, капитальное решение,.
которое закроет вобще последнюю дыру,..

те вобще дыр на сайте всегда 3 штуки
1 GET -дыра
2 POST -дыра
3 COOKIE -дыра
так вот ..
гет я считаю что закрыл, потому что не использую его переменные вобще.
(регистрация ID у урла все что осталось от гет)

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

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

вот посмотрите внимательно на исходный код этого шаблона
http://www.canadatransportatio......itcompany2/submitcompany2.html

это шаблон формы для регистрации новой фирмы..
вот он в действии
http://www.canadatransportation.com/info/submit.html
только прошу - не спамте меня,.. те не заполняйте все поля, вводите все что хотите кроме например email
а то я буду получать ваши тестовые "регистрации".

так вот по поводу шаблона
например там есть следующая строка,
 <input name="email" type="text" _require="email" _error="Please enter contact email" SIZE="70">
движок , понимает что это такое и что это значит...
я ему написал что в это поле ожидаю ввод емейла,.. а если будет ошибка то написать челвеку
"Please enter contact email"
и в коде, выполняю автоматическую валидацию всей формы сразу всеголиш одной командой,..
ведь шаблонизатор может посмотртеть в атрибуты _require и _check
<input name="website" type="text" SIZE="70" _check="url" _error="Please check your web address">
и не принять, например многострочное нечто, там где я ожидаю одну строку из нескольких слов,
те, я всегда пишу в шаблоне что я ожидаю от того или иного элемента формы.
и шаблонизатор гарантирует что какойто критический код будет выполнин лиш в случае если форма проходит валидацию.
внешне выглядит примерно так
$template_with_form= $template_engine->select('/form');
if ($cleaned_form_data=form($template_with_form))
{
// do something important

}

помимо валидации движок повышает юзабилити формы, ведь он сохраняет все значения
которые ввел человек, чтобы в случае ошибки не вводить снова,..
а у меня больше по этому поводу голова не болит, ведь все автоматика делает.
и также поскольку вся обработка поста происходит через 1 класс. я могу написать его очень аккуратно,.
те обращение к глобальному массива $_POST происходит лиш в одном месте.. в шаблонизаторе.
хотя какой он уже к черту "шаблонизатор" в таком случае.
вобщем прикладные куски кода они работают с тем что пришло не из ПОСТ
а с тем что лежит в $cleaned_form_data, а это уже туда скрипт записывает только если пройдена валидация.

те я уже это все реализовал, но оно не идеальное как я хочу и требует шлифовки.

и против кук, я сделаю строгий файрвол...
там надо будет "открывать порты" чтобы куки проходили...
а то видел я шутки такие когда народ почемуто куки не эскейпит, потому что они не "на поверхности",..

те я думаю что такие комплексные меры могут привести к повышению надежности и хакаустойчивости сайта.

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

спустя 21 час [обр] Bers[досье]
lance10t[досье]
;)
Вы не думали по поводу написания книжки "Создание CMS для чайников"? Будет пользоваться успехом 8)
Практически на 95% разобрался в исходниках шаблонизатора. Очень красиво с разборкой и сборкой тэгов.
Один механизм только остался не понятен (надеюсь не самый главный 8) С какой целью происходит деление аттрибутов на $priorityload и $processor?
Исключительно из организации очередности обработки?
спустя 45 минут [обр] lance10t[досье]

@Вы не думали по поводу написания книжки "Создание CMS для чайников"?@
=))).. сначала надо самому написать и перестать быть чайником в написании CMS.
я ведь по ходу дела сам учусь.

С какой целью происходит деление аттрибутов на $priorityload и $processor?
 Исключительно из организации очередности обработки?

да, именно для этого,..
потому что некоторые атрибуты, логически должны следовать в определенном порядке,.
вот представет если у одного тега
есть 2 атрибута
_repeat и _if
если "иф" проходит то надо крутить цикл.
но если не выставить приоритеты
то компилятор может написать вот так
for (...)
{
if ($show_tag)
{
....
}
}
видите это дебилизм- крутить цикл и каждый раз делать проверку "иф"

с приоритетами такого быть не может, компиляторв всегда будет делать "иф" поверх цикла
и код будет такой..
if ($show_tag)
{
for (...)
{
....
}
}
разумный.

спустя 34 минуты [обр] Bers[досье]

то компилятор может написать вот так
for (...)
{
if ($show_tag)
{
....
}
}

Этот код тоже может быть разумным, если $show_tag меняется с каждым проходом цикла. Как быть в этом случае?

спустя 12 часов [обр] lance10t[досье]
Этот код тоже может быть разумным, если $show_tag меняется с каждым проходом цикла. Как быть в этом случае?

дело в том что , в щаблон поступают уже статические данные, те кода выполняется Render.. массив уже не меняется.

но если нужно именно так, хотя это бывает очень редко...
можно написать вот
<rte _repeat='/array'>
<div _if='/showtag'>

<div>
</rte>

<rte> - это специальный тэг невидимка, он не генергрует ниакакого HTML а лиш создает PHP код в чистом виде,. можете в плагинах посмотртеь,. =)..
и это создаст именно такой вывернутый
for (...)
 {
 if ($show_tag)
 {
 ....
 }
 }

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

хотя какой он уже к черту "шаблонизатор" в таком случае

я вижу что то что делает "шаблонизатор" - это отлично!
он делает правильную обработку ПОСТ.
но затем я подумал,..
этоже противоречит самой архитектуре системы!
шаблонизатор занимается вводом выводом!...
и делает это хорошо и удобно -
отсюда вывод - архитектура ошибочна.

и тут до меня дошло как надо было сделать чтобы устранить это противоречие, это чисто логиеческое противоречие...

сразу опишу то что мне пришло.

система должна строится идеалогически целостно.
всегда должны соблюдаться постулаты заложенные в основу системы, иначе будет трещина и система сдохнет.
вот новая идеалогия
постулат 1
ядро занимается только вводом выводом информации между модулями и никто этим кроме ядра заниматься не должен.
постулат 2
модули четко разграничивают свои обязанности и не лезут в область которая принадлежит другому модулю.


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

это была ошибка слить их в одну кучу..
потому что они используются поразному.

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

он занимается следующим..

прочитал иноформацию из ГЕТ(не напрямую а через модуль урлов)
ввел информацию в БД (SQL-запрос)
прочитал информацию из БД (через модуль бд который отдаст массив)
ввел информацию в движок темплейтов (указал какой темплейт ему нужен)
прочитал темплейт (получил заготовку-массив)
СОВЕРШИЛ СВОЮ ЛОГИКУ (сделал чтото прикладное, те трансформировал чтото пришедшее из БД в шаблон)
ввел информацию в движок темплейтов (те передал ему массив который будет отрендерен)

вы уже заметили то что заметил я?...

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

теперь вспоминаем первый постулат.
там написано что ввод-вывод - это ядро.

так вот , я понял что если сделать как я шас напишу, то логически ничего нарушаться не будет, и система станет целостной.

надо так.

есть ядро, с плагинами ввода вывода
и есть прикладные модули.

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

тогда получается что прикладной модуль...

соврешает ввод-вывод общается с ядром..
но ядро уже интерпретирует каждое конкретное обращение на ввод-вывод с помощю соответствующего плагина.

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

вот общая схема
http://img47.imageshack.us/img47/4981/newkernelas5.gif

и теперь мне примерно понятно что надо сделать,..
надо развить идею враперов...

например чтение рсс-напрямую в пхп массив
read('rss://xpoint.ru/forums/development/analysis/thread/28649.rss');
типа такого,..
вывод рсс, например - в stdout
write('rss://',$my_array_with_rss_data);
работс с другими модулями
write('module://cache',$array_with_params_for_cache);

загрузка темплейта
%tpl=open('template://mainmenu');

вывод темплйта
write('template://mainmenu',$array_with_data);

чтение ПОСТ
$tmpl=open('template://mainmenu');
$form_data=read($tmpl);

чтение из бд может быть так.
$resource=open('SQL://SELECT * FROM POSTS');
$row=read($resource);


вот идея такая,.. те, то что тут написано это очень сырая идея, и её надо обдумывать, обмусоливать,..
и оттачивать,..
а я тут просто вывалил на форум то что крутилось в голове. не особр фильтруя
=) вобщем получили на выходе, не ядро, а СРЕДА уже =).

спустя 8 часов [обр] Александр aka Efreeti(3/111)[досье]
lance10t[досье]
  1. А нельзя ли вместо глобальной переменной использовать что-то типа gbl('name'), т.е. функцию? Во-первых, упрощается написание (нет необходимости писать постоянно global $modules), во-вторых - отсутствие косяков с тем, что забыли написать global ...
  2. Про широковещательное сообщение. Не проще ли предоставлять доступ к данным (типа $module->getInfo()), вместо этой сути. Да, в случае с essence можно не знать, где хранятся данные (в каком модуле), но с другой стороны это означает, что данные могут быть обработаны только с потерей предыдущих значений. Пример: модуль А хранит некие данные (и экспортирует их), модуль В берёт эти данные и обрабатывает (и тоже экспортирует). А, например, модуль С берёт то, что выдал В и дальше обрабатывает. Но если есть модуль D, которому нужны исходные данные - опа, он их не получит после работы В. Можно конечно ввести $essence['data']['new'] и $essence['data']['new'], но это повлечёт за собой изменение всех модулей, участвующих в работе с этими данными, что крайне плохо. Поэтому использование методов доступа (и прописывание интерфейсов) кажется мне более удачной идеей.
  3. Мне кажется не стоит на ядро возлагать ответственность по пробросу вызовов в другие (вспомогательные) модули. Вообще, такая унификация интерфейсов требует очень серьёзного проектирования, т.к. система теряет гибкость (всё идёт через "горлышко" ядра). Имхо стоит просто давать доступ к нужным модулям через $core->getModule('moduleName');.
спустя 5 дней [обр] Bers[досье]

Здравстуйте!
Столкнулся с такой проблемой. После того как шаблонизатор собрал HTML код страницы из шаблона, страница отсылается в броузер и он запрашивает картинки, которые прописаны на странице. После такого запроса скрипт выполняется соответственно еще раз - т.е. повторно.
файл .htaccess такой

Options +Followsymlinks
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?%{QUERY_STRING} [L]
</IfModule>

я так понимаю надо добавить строку, что бы данные файлы не обрабатывались index.php
RewriteRule \.(js|css|gif|jpg|png|swf|jpeg|doc|xls|ppt|zip|rar)$ - [L,NC]
Но тогда эти файлы не будут прочитаны в любом случае, ибо пути то вирутальные все.
и как это вяжется с идеей регистрации всех ссылок?
Может я чего не догоняю? ;)

спустя 2 часа 45 минут [обр] Bers[досье]
  1. Точно не догоняю, я сам разобрался.

Необходимо делать наверно так 8)
Header("Content-type: image/jpeg");
...
echo $Image;

те надо делать отдельный картиночный модуль.

спустя 13 дней [обр] Lee Sergey[досье]

Не обязательно. Я сделал у себя в обработчике шаблонов корректировку путей для src. Тогда она отсекается условиями RewriteCond и все работает хорошо. Кроме того, выделил 3 директории, которые независимо от ссылки редиректятся в рутовые. .htaccess получился примерно такой:
DirectoryIndex index.html

RedirectMatch (.*)(img)$ $1$2/

RewriteEngine On

RewriteRule (img)(.*)$ $1$2

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.html

спустя 3 минуты [обр] Lee Sergey[досье]
эээ.. index.php, а не html.
спустя 1 день 14 часов [обр] Gomez[досье]

Начитался я тут всего. Очень жестко. Половину идей автора не понял (скорее из-за невладения некоторыми вопросами)
Вот к чему я пришёл.
Из ВСЕХ CMS, которые есть на рынке нет НИ ОДНОЙ, в которой более-менее прилично была бы реализована работа с шаблонами.
А это одна из самых главных вещей (если не главная!)

Давайте разложим реально карты.

  1. Дизайнер отрисовал дизайн. верстальщик(или сам дизайнер) сверстал это всё в HTML.
  2. Надо БЫСТРО поставить cms И ВКЛЮЧИТЬ ЕЁ В ДИЗАЙН (за 1-2 часа максимум)!!!... Все реализации, которые я видел - я нашел как минимум не удобными и сделанными скорее для программеров а не для админов.
  3. CMS должна настраиваться как под продвинутого юзверя так и под секретаршу (ВЫ ДАЖЕ НЕ ПРЕДСТАВЛЯЕТЕ НАСКОЛЬКО СТРАННЫЕ ЛЮДИ ИНОГДА ЗАНИМАЮТСЯ НАПОЛНЕНИЕМ САЙТА). Более разумно задавать вид системы при создании нового пользователя (например добавляем помимо прав еще атрибут "продвинутый", "ламер") И для ламера Отключаем "Слишком сложные" функции... Такие как title, decription... имя файла страницы... обрезаем все "расширенные" возможности WYSIWYG-редактора до примитивных.

Но это лирика... Основная мысль такая...
CMS нужна... Но нужна она в разумных пределах.
Наиболее часто используемые модули: страницы; новости; каталог; голосование; поиск; формы; подписка; заказы (для интеренет-магазина) ну менеджер фотографий, ну можно еще 2-3 изобрести... ну и стандартные (устанавливаются всегда): журнал всех событий, журнал ошибок, управление пользователями, Шаблоны (главное как реализовать)
Да собственно и всё...
для 90% всех сайтов такая система подойдет, а остальные проще сделать "ТОЛЬКО ПОД клиента"...
И тратить 2 года ради сомнительного по целям проекта.

ГЫ :)
Я смотрю первый пост был опубликован аж в далеком 2004-ом...
Хотелось бы посмотреть на результат работы в действии. Там вроде как был намек на продажную версию через 2 года.. Но судя по тому, что все ссылки с примерами битые - проект сдулся :)

Ну подведу итог своей реплики...

  1. CMS должна иметь все необходимые для нормальной работы сайта модули (Это не обсуждается).
  2. CMS должна быть удобной в первую очередь для пользователя и для админа. Интерфейс админ части должен быть ИНТУИТИВНЫМ (тупая секретарша не должна учиться работе с админкой 2 месяца, мануал добавления новой страницы должен уместиться у неё на листочке бумажки в 3 пункта), а не как в большинстве CMS ужасать количеством своих функций ради универсальности. Главная универсальность это УДОБНАЯ работа с шаблонами.
  3. Должна мигом ставиться...

щас пишем свою:
ТЗ на все модули уже есть. Дизайн интерфейса (для ВСЕХ модулей) уже есть. WYSIWYG-редактор выбран - это innova - однозначно (после solmetra (использовался в старой cms), и остальных РЕАЛЬНО от неё протащился)... Теперь дело за программерами... И да поможет нам господь!!! Аминь!!! :))))))))))))))))))))))))))))

спустя 9 часов [обр] Александр aka Efreeti(3/111)[досье]
Gomez[досье]
А вы на ASP пишите?
спустя 1 час 3 минуты [обр] Lee Sergey[досье]

Gomez[досье]для решения второй проблемы есть простой выход: 2 админки. Одна для реального, продвинутого админа (или работника веб-студии) с максимум функционала (под программиста), вторая - для секретарши. В ней уже полный юзер-френдли, с обрезанием ненужных функций. Причем вторая админка может быть уже как и сам сайт, собрана с использованием первой и соотв. модулей.

А какой способ работы с шаблонами вы закладываете в свою CMS?

спустя 17 минут [обр] Алексей Севрюков(2/1280)[досье]
Надо БЫСТРО поставить cms И ВКЛЮЧИТЬ ЕЁ В ДИЗАЙН (за 1-2 часа максимум)!!!
Тут я с Вами не соглашусь, ибо некий функционал все равно реализовывать придеться. И вот если этот функционал относительно сложные и его много, 1-2 часа вполне может не хватить.
спустя 2 месяца 4 дня [обр] JC_Piligrim[досье]
Уважаемый lance10t[досье], расскажите, как продвигаются дела с проектом, на какаой он сейчас стадии, можно ли посмотреть демку?
спустя 1 месяц 22 дня [обр] Максим[досье]
Надеюсь будет продолжение? Не хотелось бы, чтобы на этом все и закончилось.
спустя 14 дней [обр] ask[досье]

lance10t[досье]
К сожалению, вышеприведенные ссылки не открываются.
Мне было бы интересно посмотреть на реализацию парсера-компилятора html-шаблонов и замены спецтегов условия и цикла (_if="...", _display="...", _require="...").

Да и вообще, обсуждение что-то затихло.

спустя 9 часов [обр] lance10t[досье]

прощу прощения за такое долгое отсутствие,...
по поводу "а что происходит?"
происходит следующее,...

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

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

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

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

в основу фреймворка положена идея о том что все web элементы можно представить в виде какихто
абстрактных нодов, и давать доступ к этим нодам по средствам xpath-подобных выражений,..
те, фактически мы делаем некое подобие файловой системы для скриптов,..
сейчас приведу пару примеров.

предположим у вас есть задача прочитать все значения из sql таблицы example
для этого в скрипте вам надо будет какбы открыть виртуальный файл.
$descriptor=open('/dev/db/local/example');
while ($=read($descriptor)) { };
те фреймворк представляет все свои части как файлы и папки внутри одного общего дерева,
и дает к ним унифицированный интерфейст доступа,
чтобы лучше понять идею вспомните FAR (filemanager)
фар дает унифицированный доступ например к фс,архивам,фтп,емейлам, и даже к реестру,
предаставляя все эти очень разные вещи в виде файлов и папок,... и даже позволяя копировать одно в другое.
примерно тоже самое и будет делать этот фреймворк...

например чтобы получить все поля из example у которых parent_id=1
нужно будет открыть следующий "файл"
$descriptor=open('/dev/db/local/example[@parent_id=1]');
while ($=read($descriptor)) { };

те как видете это чтото вроде фс у которой пути работают как xpath...
весь этот фреймворк будет очень дезинтегрированный!...
если например вам понравится какаято его часть - например встроенный шаблонизатор, или интерфейс доступа к бд, или даже генератор парсеров, то не составляет никакого труда зайти и выкопировать из системы и после include
вы сможете его использовать отдельно в своих скриптах,

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

те я решил обьеденить Input and Output в одном блоке,..
и вот почему.. потому что например когда от браузера приходит POST то чтобы его валидировать надо знать какая изначально была форма в шаблоне, и сверить её поля с тем что пришло, а это проще всего сделать во время компиляции шаблона,

те теперь этот шаблонизатор он создает не только хардкодный скомпелированный php код который рисует форму, но будет и создавать такойже харткодный кусочек php который проветет её валидацию в случае post.

Мне было бы интересно посмотреть на реализацию парсера-компилятора html-шаблонов и замены спецтегов условия и цикла (_if="...", _display="...", _require="...").

сейчас готового парсера нет,
но если хотите посмотреть на общие принципы разборки возьмите этот код

<?php
class BiosCompiler
{
    var $_currentTemplate='';
    var $ns=array();
    var $attributesregexp='`
    (?P<attribute>
     (?:(?P<namespace>\w+):)?
     (?P<name>\w+[\w-]*)
     (?:\s*=\s*(?P<quoted_string>(?P<quote>")(?P<string>.*?)(?<!\\\\)(?P=quote)))?
    )
    `Ssxi';
    var $xhtmlregexp='`
     (?P<main>
         (?P<tag>
             <(?P<tag_name>(?:(?P<tag_namespace>\w+):)?(?P<name>\w+[\w-]*))
                (?P<attributes>
                 (?>\s+
                    (?P<attribute>
                     (?:(?P<attribute_namespace>\w+):)?
                     (?P<attribute_name>\w+[\w-]*)
                     (?:\s*=\s*(?P<quoted_string>(?P<quote>")(?P<string>.*?)(?<!\\\\)(?P=quote)))?
                    )
                 )+
                )?\s*
            (?:
             /> # short tag
             |  # or full tag with inner_html
             >(?P<inner_html>(?>(?P>main))*)</(?P=tag_name)>
            )
         )
         |
         (?P<skip_tag>
             (?P<text_node>[^<]+)
             |
             <!(?P>name)(?>\s+(?:(?P>attribute)|(?P>quoted_string)))*\s*>
             |
             <!--.*?-->
             |
             <\?(?:php)?.*?\?>
         )
     )
    `Ssxi';

    function BiosCompiler()
    {

        $this->_load_namespaces();
    }

    function _report_parse_error($errors,$template)
    {

        $offset = 0;

        foreach (explode("\n", $template) as $i => $line) {
            $lines[$i] = array(
            'text' => $line,
            'offset' => $offset
            );
            $offset += strlen($line) + 1;
        }


        echo '
<pre style="background-color:#FFFFCC;">
XHTML parse error ('.$this->_currentTemplate.')
------------------------------------
[line][backtrace...]
';
        $depth=0;
        $highlight_error=false;
        foreach ($errors as $ernum => $error) {
            if ($error[0]{0}=='/') {
                if ($depth>0) $depth--;
            } else
            $depth++;

            if ((isset($errors[$ernum+1]) && $errors[$ernum+1][0][0]=='/' && $error[0][0]!='/')||$highlight_error) {
                // error extremum

                $highlight_error=!$highlight_error;
                $error_line=$lines[$error['line']-1];

                if (substr_count(trim($error[0]),"\n"))
                $elines=array_slice($lines,$error['line'],substr_count($error[0],"\n"));
                else $elines=array();

                foreach ($elines as $value) {
                    $error_line['text'].="\n".$value['text'];
                }

                $error_highlight['pre'] = substr($error_line['text'], 0, $error[1] - $error_line['offset']);
                $error_highlight['error'] = substr($error_line['text'], $error[1] - $error_line['offset'], strlen($error[0]));
                $error_highlight['post'] = substr($error_line['text'], $error[1] - $error_line['offset'] + strlen($error[0]));

                $linemarker=sprintf('<b    style="background-color:#CCFF66;">[%4.4s]</b>',$error['line']);
                echo

                $linemarker
                .'<span style="background-color:#EDED99;">'
                .htmlentities($error_highlight['pre'])
                .'<span style="background-color:#FF9933;">'
                .str_replace("\n","\n".'<b style="background-color:#CCFF66;">      </b>',htmlentities(($error_highlight['error'])))
                .'</span>'
                .htmlentities($error_highlight['post'])
                .'</span>'
                ."\n";

            } else {
                echo
                sprintf('<span style="background-color:#CCFF66;">[%4.4s]</span>',$error['line'])
                .str_repeat(' ',$depth).htmlentities('<'.trim($error[0]))
                ."\n";
            }
        }
        echo '</pre>';
    }

    function _parse_template($template)
    {

        preg_match_all($this->xhtmlregexp,$template,$tags,PREG_OFFSET_CAPTURE);
      
      $prev_match = array('', 0);
        $errors = array();
        $linenumber = 1;
        $matchedlength = 0;

        foreach ($tags['main'] as $match) {

            if (strlen($prev_match[0]) + $prev_match[1] != $match[1]) {
                $match['line'] = $linenumber;
                $errors[] = $match;
            }
            $prev_match = $match;
            $linenumber += substr_count($match[0], "\n");
            $matchedlength += strlen($match[0]);
        }



        if (count($errors)) {
           // FANCY ERROR REPORTING
            $this->_report_parse_error($errors,$template);
            return false;
        } elseif (strlen($template)!=$matchedlength){

           // real shit
         // onse i will set another error detector, whitch will handle that;
                   echo '
<pre style="background-color:#FFFFCC;">
XHTML parse error ('.$this->_currentTemplate.')
------------------------------------
Sorry, due to the PHP limitation of PCRE regular expression recursion depth
I was unable to detect the exact place of error, it doesn\'t let me parse the template.
you should check the lower levels of nested tags to enshure their consistency.

HINT: you should avoid using such deeply nested templates
"merge" tag can help you simplify the template by splitting it apart.
</pre>';
          return false;

        }
        
        $nodes=array();
        foreach ($tags as $key => $set) if(!is_numeric($key)) {
            foreach ($set as $i => $value) {
                if ($value!=='')
                $nodes[$i][$key]=$value[0];
            }
        }

        $tags=array();

        foreach ($nodes as $i => $node) {

            if (isset($node['skip_tag'])&&strlen($node['skip_tag'])) {
                 $tags[]=array('html'=>array($node['skip_tag']));
                 continue;
            }

            $tag=array
            (
            'html'=>array(
            'pretag'    =>'<',
            'tagname'   =>$node['tag_name'],
            'attributes'=>array(),
            'prehtml'   =>'>',
            'inner'     =>'',
            'posthtml'=>'</',
            'closetagname'=>$node['tag_name'],
            'posttag'=>'>',
            ),
            'ns'=>$node['tag_namespace'],
            'attributes'=>array(),
            'data'=>'',
            'intera'=>'',

            );

            if (isset($node['attributes'])){
                preg_match_all($this->attributesregexp,$node['attributes'],$attributes,PREG_SET_ORDER);
                foreach ($attributes as $attribute) {
                    $tag['attributes'][$attribute['namespace']][$attribute['name']]=$attribute['string'];
                    $tag['html']['attributes'][$attribute['namespace']][$attribute['name']]=$attribute['attribute'];
                }
            }


            if (!isset($node['inner_html'])) {
                $tag['html']['posthtml']=$tag['html']['closetagname']=$tag['html']['posttag']='';
                $tag['html']['prehtml']='/>';

            }

            $tags[]=$tag;

        }






    }

    function _load_namespaces()
    {
        $homedir=dirname(__FILE__).'/';

        $handle=opendir($homedir.'ns/');
        while ($file = readdir($handle)) {
            if ($file == "." || $file == "..") continue;
            if (file_exists($homedir.'ns/'.$file.'/ini.php')){
                $ns_conf=parse_ini_file($homedir.'ns/'.$file.'/ini.php',true);
                $this->ns[$ns_conf['namespace']]=array('name'=>$file);
            }
        }
        closedir($handle);
    }

    function compileTemplate($template,$filepath,$output)
    {
        $this->_currentTemplate=$template;
        $compiled=$this->_parse_template(file_get_contents($filepath));
    }


}
?>

и передайте во внутрь функции
 function _parse_template($template)
сам текст xhtml-а который вы хотите разобрать,..
оно декомпелирует теги,.. но учитите я не написал там одну строку которая будет вызывать
_parse_template рекурсивно для innerHTML каждого из тегов =)

учтите регулярное выражение - очень строгое оно не любит одинарные ковычки в атрибутах и не любит незакрытые теги
те если тег короткий то компилятор желает его видеть вот с такой концовкой /> а не просто >
это сделано специально.

вобще весь разбор xhtml осуществляется одним большим регекспом который можете наблюдать в переменной $xhtmlregexp
этот регекст просто матчит весь xhtml рекурсивно сам в сбе и самже контролирует правильную вложенность тегов.

сборку тегов я доделаю сейчас после отправки этого сообщения,..
те парсера там кот наплакал - его всего несколько строк,.. весь парсер занимает 1 экран, а самая большая функция это просто
для красивого вывода сообщения об ошибке с указанием возможного места ошибки =)..

если у вас возник вопрос зачем понадобилось переписывать шаблонизатор -
ответ простой,..

  1. чтобы сделать в нем поддержку xpath
  2. чтобы сделать в нем поддержку сложного слияния шаблонов, (это другое чем include)

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

  1. чтобы сдалать компилируемый валидатор форм.

(это собственно все чего нехватало в прошлой версии)


когда доделаю шаблонизатор я конечно его релизну.
вот тут будет документация
http://wiki.e43.org/iris:subsystems:bios

спустя 1 день 15 часов [обр] ask[досье]
lance10t[досье]
Насколько я понял, система секьюрити тоже реализована в виде plug-in.
Но в таком случае кто её подключает, инициализирует и использует её методы проверки доступа кого-либо к чему-либо?
Ядро? Каждый вызываемый модуль?
Теоретически эта система должна стоять над работой модулей и служить неким файрволом, отсекающим некорректные обращения и вызовы методов модулей к чему-либо.
На мой взгляд неправильно вызывать методы проверки безопасности из тела модулей, ведь тогда вся ответственность за безопасность ложится на каждый модуль.
спустя 7 дней [обр] ask[досье]
  1. Есть модули, которые пользователь может вызывать по выбору (напр: новости, гостевая и т.д.).
  2. Есть ядро, которому приходит команда на запуск определенного модуля.
  3. Модули могут пользоваться услугами плагинов. Т.е. модулю может понадобиться плагин для работы с БД, плагин для обработки изображений, плагин шаблонов HTML и т.д.
  4. Вызванный модуль может запросить данные (т.е. вызвать методы) у других модулей.
  5. Система безопасности тоже представлена в виде плагина, как и система обработки переменных REQUEST.

По логике вещей системы из п.№5 должны быть независимы от модулей, т.е. их должен вызывать и применять кто-то другой в иерархии приложения.
Кроме ядра - некому. Но встраивать их вызов в код ядра является не гибким решением, т.к тогда они станут его неотъемлеиой частью, а не независимыми плагинами.
Исходя из этого я принял решения описать в конфигурационном файле ядра те плагины, которые должны стартовать вместе с самим ядром по аналогии со службами (services) в windows. На мой взгляд - довольно точная аналогия. В принципе, эти системы можно и выделить в отдельный вид - "services". И пусть они будут вызываться только ядром и будут недоступны для запуска из модулей.
Тогда у service безопасности появляется возможность управлять доступом модулей к данным и другим модулям.

Остается вопрос, как указать системе безопасности, что модуль такой-то, обратившись к плагину БД, имеет право писать в таблицы А и Б и не имеет права читать табицы В и Г?

Ещё вопрос по п.№4: как организовать вызов одним модулем методов другого модуля (напр. модуль вывода главной страницы должен собрать данные из модуля новостей, модуля баннерокрутилки, модуля постройки меню, модуля статей и т.д.)?

спустя 4 месяца 26 дней [обр] Прохожий[досье]
Что там у вас происходит? :)
рассказывайте...
спустя 7 дней [обр] Леонид Сысолетин(0/14)[досье]
Посмотрите в сторону DAA, особенно про архитектуру.
Очень интересно, и принципы где-то пересекаются.
спустя 2 дня 4 часа [обр] halt.avmc[досье]
Неужели все?
Обидно, если такая система пропадет зря!
И можно ли где-нить еще посмотреть её в действии, кроме как на
http://canadatransportation.com/ ?
Powered by POEM™ Engine Copyright © 2002-2005