Во-первых, глаз режет обилие ЗАПРОСОВ и циклов(){ рядом с ними...
Во-вторых, кол-во уровней списка заданно заранее. На деле оно может быть любым. Как его определить?
В общем что не так и как придти к решению прошу рассказать  Все найду, все прочитаю, все исправлю, если бужду знать.
P.S. Достаточно ли я привел кода? echox("<ul>",10) выводит 10 раз тег ul. Этот файл инклюдится_однажды, все необходимое уже включено.

да, обилие запросов режет глаз

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

т.е. для пункта 2.3.3, это 


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



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

bars80080, спасибо за ответ!


Ну у меня вроде бы как раз так.



В общем это экспертная система, а дерево выводится в ее админке. И это не простое дерево 
Экспертная система представляет из себя 5 таблиц. Первые две к делу не относятся (это вопросы questions(qid,qtext) и q2s(qsid,qid,sid) - соотнесение вопросов и утверждений).

Далее третья таблица statemnts(sid,stext) - утверждения, и последяя productions(pid,s1id,s2id,sid) - связи между утверждениям.
Связи между утверждениями(условия) в таблице productions хранятся в таком виде. Если Если s1id==1 и s2id==1, то  sid==1 (другими словами: если утверждения A и B верны, то утверждение C тоже верно).



Дело просто в том, что у меня начало немного другое. Сначала я ищу и вывожу финальные выводы из таблицы statements. Финальные - это те, которые удовлетворяют условию

т.е. не встречаются на месте утверждения A или на месте утверждения B в таблице productions. А уже потом последовательно все A и B для предыдущих C.

Отличный пример кода, чтобы показать как не надо программировать!
Тут есть и невнятные идентификаторы(имена функций, переменных, столбцов в БД), и низкоуровневое общение с БД, и сырой SQL, и вложенные циклы, и "магические"(читай: непонятно нафиг нужные) действия типа "выводит 10 раз тег ul" вокруг одного единственного элемента li, и "глобальная" переменная $levels, и навязчивый JavaScript, и смешение бизнес-логики с отображением. 
В общем, если развёрнуто записать все замечания к этому коду, то получится целая книжка. Впрочем книжка на сходную тему(по критике большего количества таких же неудачных примеров кода) уже есть, когда прочитаешь, обращайся за дальнейшими советами...  

source777, большущее спасибо!!!   Если бы вы написали книгу на русском электронном языке, я бы ее купил бы первым! 
Позвольте вступить с вами в диалог. Мне необходимо раскрыть несколько моментов для понимания.


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


А вот про это есть в книге? Мне это очень интересно, т.к. я слышал много мнений, а своего не выработал. Пишу как получится (одинаково для всего web-приложения).

Тут я могу заблуждаться. Но я считал, что список 1, 1.1, 1.1.1 должен быть таким в HTML:

Если нет, то поправьте пожалуйста прямо сейчас. Вроде бы основывался на знаниях полученных в HTMLbook.ru.
Или вы имеет в виду что-то другое? Алогоритм? Тогда уточите пожалуйста, а то я не понял вас.


А как лучше поступить? Не понял.



P.S. Очень рад, что вы не сказали, что вместо

Надо писать такой нечитаемую и сомнительно красивую хокку:

Ибо якобы это не соответствует вселенским стандартам. 

Такое , наверное, даже валидацию не пройдет... В ul может вставляться только li и никто более. Такая-же песня, как с таблицами, строки-ячейки. 



Это сообщение отредактировал(а) ksnk - 24.5.2009, 23:16

Вот это совершенно правильный с точки зрения валидатора код

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

Ну если никому свой код не показывать, то можно и так, если тебе понятно... А вот если ты хочешь уметь работать в команде или получать быструю помощь на форумах, то придётся тебе научиться правильному именованию. На этот счёт есть несколько весьма популярных конвенций, но одна идея встречается во всех: идентификатор должен раскрывать смысл, стоящей за ним сущности любому человеку, даже далекому от программирования, но знающему английский язык. Поверь, никому не охота разбираться что значит "print_statement", "rProductions", "s2id", "statement0", "level10", "stext", etc. И даже твои объяснения на этот счёт никому не интересны. Код, для объяснения которого надо написать комментариев в два раза больше, чем кода, это уже не код, а силос для интерпретатора/компилятора! Подобная схема именования уменьшает твои шансы получить бесплатную помощь в десятки раз.


нет, правильный вариант привёл Photon.


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

как расставлять скобки - это далеко не самая важная дилемма.

Если задуматься над этими недочетами, то что-то я даже и не знаю как вместо этого называть перменные и таблицы в БД. Надеюсь после прочтения книги все придет.

А как надо называть таблицу, где хрянятся связи между таблицами questions и statements? (один к одному) Я решил q2s, но похоже это неудачная идея.

Добавлено через 1 минуту и 59 секунд
То же самое: я следовал таким рассуждениям, если в таблице можно создать столбец sid (statement id), то если их два типа, то будет s1id и s2id.

Добавлено через 2 минуты и 28 секунд
P.S. Вообще предчувствую что все мои вопросы излишны и придется месяц читать книгу.

Для связи 1 к 1 вообще промежуточных таблиц не надо, RTFM по теории баз данных. А связующие таблицы для связей многие ко многим принято называть либо questions_statements, либо QuestionsStatements в зависимости от того какой стиль используется для именования таблиц underscore или CamelCase. Любой другой стиль именования в данном случае будет не очевиден.

Кстати что за идентификатор такой неудачный "statements"? У любого программиста какая первая ассоциация с этим словом? if-statement, statement block и т.д. Ты же не транслятор пишешь... Или дальше "productions", что за производства такие, хз.

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

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


Можешь прямо с 11 главы и начать!


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

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

Questions
NewStatements
QuestionsNewStatements - может лучше комбинировать стили? - Questions_NewStatements

А есть такой стиль? - newStatements, questionsNewStatements (первая буква маленькая)



Ну можно сказать, что сравнение подходящее. Потому что у меня это два условия. Если выполняется A и выполняется B, то C. s1id, s2id и sid соответственно. Это я не спорю, а спрашиваю. Что думаете?


Сложность в том, что я когда садился за разработку и делал таблицы в БД я не знал точной структуры своего кода и алгоритма. Я только знал что-то вроде такого:
Прямой ход (фронт-энд): "
1. ну задает вопросы; 
2. ну потом по номеру вопроса устанавливает верность утверждения; 
3. ну делает выводы из двух утверждений для опредления верности третьего утверждения;
4. ну если третье утверждение НЕ встречается в других строках таблицы продукций(это термин дал научный руководитель), то оно 
5. финальное - помечаем как финальное;
6. ну, что, кончились вопросы? Выводим все финальные утверждения"

Админка(основной г...-код приведен в первом посте): 
1. выводим все финальные утверждения (те самые С, удовлетворяющие п.4 фронт-энд)
2. после всех финальных выводим причинные утверждения (те самые A и B)
3. выводим вопросы для тех утверждений, верность которых устанавливается засчет вопроса".

Но даже теперь написав г/код я не могу сформулировать так, чтобы ребенок или просто не программист хорошо понял. Кстати как формулировка 1-6, 1-3? Нормальная или очень плохо?

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

не лучше.

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

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


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

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

А что еще буде в такой таблице кроме statement_id?

Добавлено через 3 минуты и 42 секунды

Преподаватель три раза мне уточнял что нужно сделать. Первый раз вообще почти все переложил на меня. Потом подробнее. Третий раз более менее алгоритм (но на словах и в виде примеров А В С). В итоге я три раза делал эту экспертную систему и переписывал код с нуля заново тоже три раза (и прямой ход и админку).
Мне не понятно как можно полностью представлять себе структуру, когда только в процессе программирования выясняются тонкости работы с сессиями (а там именно я храню результаты работы экспертной системы).

Добавлено через 6 минут и 13 секунд
Или тот же JS в админке. До разработки я очень слабо себе представлял принцип использования JS в приложениях. И лишь только сейчас кое-что стал понимать.

Тонкости в при проектировании тебя вообще не должны интересовать, пойми сначала что нужно сделать! А как сделать - это дело техники.

А я откуда знаю? Я вообще с твоим ТЗ не знаком... Почитай что выдаёт Google, может тогда поймёшь что ты пытаешься сделать...



Ну и ещё 100 раз перепишешь с таким подходом. Ты что про ООА/П никогда не слышал?

ООА/П - это объектно-ориентированная архитертура / проектирование?
Если да, то слышал и начинал читать про паттерны. Но меня смутило то, что отношение к PHP не имеет никакого (там только по C++(никогда не програмировал на нем, только слышал), SmalTalK(впервые слышу).
Читал по PHP про паттерны проектирования и не понял какое это имеет отношение к дейстивительности. Все примеры покзались оторванные от реаьности реальных задач. Я понимаю, что это может быть не правдой, но пока я в этом убедился. Может быть я далеко не про все паттерны проектирования читал, но я еще не нашел такой задачи, где бы они были применимы (ни на JS, ни на PHP кстати).

P.S. У нас в группе задание по сложной экспертной системе (простую как и все одногрупники я уже сделал, причем в начале семестра) выполняют еще три человека. И никто из них даже не читал про патерны проектирования и вроде бы те из них, кто программирует на PHP не применяюсь ООП. Это я к тому, что у меня перед глазами даже примеров нет к которым надо стремиться.

Добавлено через 5 минут и 14 секунд

Я бы с удовльствием начал с теории, а закончел бы правильно спроектированной и лаконично скодированной системой. Но ТЗ нам не давали, а только сказали предложить свою систему с учетом некоторых требований (требования относительно конкретные - от А и В зависит С и т.д., но не достаточные для формирования ТЗ). Тем более что на создание ЭС дали месяц. А тепреь и вовсе неделя остается (но я уже сделал 90%).

Значит вывод какой? Я заканчиваю это г/ЭС и потом летом уже занимаюсь программированеим серьезно, а не на урвоне ВУЗа?

Это сообщение отредактировал(а) Win MK 32 - 26.5.2009, 16:32