Yarik Voronov

1. простой вариант. создать ассоцативный массив в отдельном файле подключаемом include. //menu.php.inc $Menu = array ( "1" => array ( "name"=>"Главная", "file" =>"index.php" ), "2" => array ( "name"=>"Контакты", "file" =>"contacts.php" ), /*. . .*/ "60" => array ( "name"=>"Шестьдесят", "file" =>"60.php" ) ); в дальнейшем редактировать этот файл. а в основном подгружать этот массив и по номеру в списке доставать нужную информацию. 2. оптимальный вариант. организовать аналогичную таблицу в базе данных. и получать запросом только необходимую инфу. ПС, ППС: Более детально смотреть манулы и учебники по работе с массивами и базами данных

точно не определено в каких поисковиках искал человек... Копирование таблиц MySQL

mario, есть вариант: 4 таблицы + продуманный SQL. определимся что есть статичная информация, что есть модель взаимосвязей. Города и Страны - это статичная информация - заносим ее в 2е таблицы и не паримся больше: Таблица Страны idс | Name Таблица Города cid | idc | Name Теперь модель взаимосвязей: Таблица Тип/Подтип tid | parent_id | Name Таблица TypeCityMap mid | tid | parent_id | cid Выборка SELECT TypeCityMap.tid TypeCityMap.mid, Города.name, Страны.name FROM TypeCityMap LEFT JOIN Города ON TypeCityMap.cid = Города.cid LEFT JOIN Страны ON Города.idc = Страны.idc ORDER BY TypeCityMap.tid, Города.name результат кладем в ассоциативный двумерный массив 1 c ключом tid: array ( [tid] array ( [0] array ( mid, city, country ) [1] array ( mid, city, country ) ) ) так как информация типов разнородна то придется сделать еще один запрос (самый нужный) SELECT * FROM Тип/Подтип ORDER BY Тип/Подтип.parent_id DESC, Тип/Подтип.tid DESC результат кладем в двумерный массив 2 с ключом первой вложенности tid: array ( [tid] array( [0] = typename [1] = parent_id ) ) далее надо раскидать массив 2 в модель дерева. можно сделать на массиве используя рекурентный вызов функции модель на массивах (массив 3): array( [tid] array( // parent_id то же имеет номер в поле tid [tid] array( [tid] array( [пусто] ) ) ) Собственно алгоритм: идем по массиву 3, беря информацию из массива 2, как только попадаем на "пусто" - обращаемя к массиву 1. сделать можно, используя рекурентный вызов функции. PS: зная номер mid таблицы TypeCityMap мы можем собрать нужную цепочку PPS: не только. см классы РНР

Есь еще вариант, кроме session и get. cookie + serialize() / unserialize(). и можно надумать множество вариаций. 2 Veseloff Это относиться к теории экспертных систем и искуственного интеллекта (основопложник теориии фреймов М.Минский). Используется для описания стереотипных знаний/ситуаций как структур. Примерный аналог РНР - класс.

когда Вы пишете руками тег кирилицей, то браузер отправляет кирилицу в кодировке своей ОС. потому что еще не получил заголовок с кодировкой, в которой работает сайт. приведу вам пример алгоритма когда вы работаете в однобайтовой кодировке скрипта, получая запрос в мультибайтовой. Модифицировать алгоритм для частных случаев я думаю Вам не составит труда. /** * скрипт сохранен в windows-1251 */ $RU = urldecode( $_SERVER["REQUEST_URI"] ); $myScriptCharset = "windows-1251"; if ( !preg_match("/[а-я]/i", $RU ) ) { /** * mb_detect_encoding () * только для мультибайтовых кодировок * подробнее http://www.php.su/functions/?cat=mbstring */ $thisCharset = mb_detect_encoding( $RU ); $RU = iconv( $thisCharset, $myScriptCharset, $RU ); header( "Content-type: text/plain; charset=$myScriptCharset" ); header( "Location: $RU" ); exit(); } header( "Content-type: text/html; charset=$myScriptCharset" ); echo urldecode( $_SERVER['QUERY_STRING']); echo "<pre>"; var_dump( $_SERVER['QUERY_STRING'] ); echo "</pre>"; phpinfo(32);

Возможная причина проблемы. Bolmazov, Вы в своих скриптах используете функцию открытия постоянного соединения с базой. Такое соединение остается открытым после завершения скрипта, если Вы такое соединение не закрыли явно. Используется когда следует "гонять" очень большой объем трафика м/у приложением и базой.

2 -=PSU=- не пропрет у него этот класс: public $rezult;. wsh постоянно будет перезаписывать эту переменную в процессе выполнения своего алгоритма, как и раньше было. там надо что-то типа return $result где $result внутренняя переменная функции, перед каждым запросом чистая. По хорошей логике класс БД должен получить запрос, получить тип ответа, выполнить запрос, отформатировать результат и отдать его, не запоминая. А вот "то что" запросило должно распорядиться с этим результатом как требует "этого чего-то" логика.

Я как и homm предлагаю включить мозг, а не ждать натс. Ты привел конкретный пример я выдал конкретный ответ. Если у тебя 10 запросов и после каждого запроса есть готовый результат то его надо отдать клиенту. если это 10 запросов связывающих 10 таблиц базы данных то проще сделать один "трехэтажный" запрос, и не пренебрегать функционалом базы данных. это мое имхо: есть и плюсы и минусы трехэтажных запросов. но это не относиться к теме. Так же если например 5 таблиц базы данных связывают информацию одного объекта (меню например) а другие 5 другого (информация о контенте) то это два разных объекта. соответственно два разных класса, наследники третьего: работа с базой данных (например). причем экземпляры этих первых двух классов (конечные объекты) не пересекаются в родителе (не имеют общих переменных - т.е названия переменных одни и теже. но физическое адресное пространство разное). Вообще наследовать класс базы данных не есть хорошая логика - так как в 99% случаев требуется лишь один экземпляр этого класса для работы приложения, а не реализация этого класса во множестве других, т.е множество других экземпляров класса базы данных (10 потомков класса создат 10 соединений с БД, умножая на среднее количесво юзеров сайта, получаем нагрузку канала передачи данных; хотя приложение выполняется последовательно, но есть небольшой лимит времени в течение которого существует открытое соединение, ессно дело если ручками его не закрывать). vvsh, если у тебя не получается вникнуть в ОПП на абстрактных процессах, используй материальные: приготовление кофе, например. Чашка, ложка, турка, кофе, сахарница и т.п - это объекты, с определенным интерфесом доступа к своим свойствам. Рецепт кофе: "Кофе по турецки" - это модель. Ты сам - это контроллер, который связывает объекты, их свойста и их методы с моделью для получения результата (представление): попить кофе по турецки. Так что возьми листочек бумаги и коды подейшь пить кофе запиши всю последовательность действий над объектами и их свойствами, сгруппируй, проанализируй, обобщи в классах (шаблонах объектов) и получишь "приложение" кофепития

ня, ня, ня и т.д. долго врубался в час ночи в исходный код. ня. если это то, что надо выбрать из одной таблицы данные по полю другой, то это, как вариант SELECT table2.* FROM table2 LEFT JOIN table1 ON (table2.field2 = table1.field) WHERE table1.field IS NOT NULL; кстати слегка модифицированный пример из манула MySQL Или первый результат записывать в переменню класса наследника, которая не меняется в процессе работы дальнейшего алгоритма.

перед всеми спец символами форматирования строк такими как например \n, \t, \r надо добавить еще один обратный слэшь: \\n, \\t, \\r. тогда будет пониматься что это обратная слэшь + буква. такую замену можно осуществить тем же str_replace() или preg_replace(). соответственно когда осуществляется импорт бэкапа надо делать все наоборот. регуляркой, имхо, удобнее, можно в качестве входных параметров поиска и замены использовать массивы.

Посмотрел. но немного не то, что хотелось бы увидеть. Видимо я сам плохо разъяснил, что нужно. Объясняю в чем подвох моего ТЗ. SC однозначно имеет преимущество когда нужно работать динамически со статичным контентом (набором элементов дерева полученных один раз при загрузке страницы). Но мне не понятно как SC поведет себя при работе динамически с динамическим контентом. Например, расширим ТЗ таким образом: 1. Форма авторизации. после успешной проверки данные должны быть переданы AJAX на сервер. Полученный ответ может быть трех типов: ок + резюме по пользователю + кукер, false (авторизация не удалась), bun + причина отказа. Первый тип ответа должен быть выведен в правой части страницы в виде таблицы (имя, ник, дата регистрации, последний раз был). Второй тип ответа должен быть выведен как системный алерт с активацией формы авторизации (активация предполает все уже описанные действия со второй формой) Третий тип ответа должен быть размещен в области системных сообщений с изменением цвета фона. Форма должна быть очищена (или заменена на кнопку "Logout" - для усложнения) при успешной авторизации. 2. Форма подписки. Если пользователь залогинился - просто подписать на данный контент, отправив методом AJAX уникальный идентификатор контента. Если пользователь не авторизован - предложить авторизоваться, выведя системный алерт с сообщением и активировав форму авторизации. примечание: проверка на авторизованность проверяется наличаем или отсутствием кукера с определенным заранее именем (или динамически определенным - если хочется усложнить) И наверно хватит "расширений". Все эти расширения реализовывать на SC я не предлагаю. Просто поясняю свой "угол зрения", с которого рассматривал пример 7 и все другие: то что ноды (формы) могут не быть размещены в одном контейнере; то что системный алерт может быть заменен на его эмуляцию html; сколько уникальных обработчиков событий надо внедрить; нужно ли переписывать валидатор форм в каждом конкретном случае (состояние окружающих нодов и произошедших событий); сколько имен состояний надо определить; сколько нодов и их атрибутов sc потребуется переписать вручную. Подозреваю, что одним блокнотиком я не обойдусь через пару дней работы. Хочу акцентировать: я не пытаюсь доказать что SC плох. я пытаюсь определить его возможности. А если следует во втором таббере показать по нажатию на к.-л. таб тот контент, который зависит от состояния первого таббера? Что-то не понятно, что имелось в виду под "Именно это нужно в интерфейсах". Если программирование процедур, без инкасуляции конкретных методов, то привожу свои рассуждения. А зачем собственно нужны разные названия методов для операций одного типа? У таббера есть метод "открыть" (показать вкладку) у коментария есть метод "открыть" (показать содержимое), у галереи картинок есть метод "открыть" (показать соответствующую картинку крупным планом). Примечание: галерея, таббер, коментарий существуют одновременно на странице. Понятнее реализовать на мой взгляд типизированный интерфейс. В обыденной жизни мы же говорим "открыть холодильник", "открыть дверь", "открыть кран с водой", "открыть пакет сока", предполагая под этим совершенно разные действия, с разными условиями окружающего мира в конкретный момент времени. С точки зрения ООП: [Холодильник].открыть(); [Кран с водой].открыть(); [Пакет сока].открыть(); [Дверь].открыть(); З.Ы.: sorrow, не стоит отвечать сразу. я тоже человек занятой.

Ну мне лично идея SC нравиться. Хотя она и не лишена недостатков. Один из них насколько я понял после изучения манула - это невозможность задать одни и те же имена состояний для разных объектов, даже для разных экземпляров одного и того же класса. Хотя слова "объекты и классы" в контексте SC употреблять было бы несколько ошибочно. Так как здесь в большинстве своем идет программирование процедур, без инкасуляции конкретных методов: на команду "голос!" хотелось бы чтобы собака лаяла, а кошка - мяукала) То есть, проще говоря, надо набраться фантазии и блокнотиков чтобы не забыть и не перепутать имена состояний и их обработчики. На мой взгляд такая проблема решается просто - объект globalStateController можно сделать двумерным: globalStateController.[AbstractObjectName].States={"state_name":"state_val"}. s0rr0w, Вы просили что-то нетревиальное. Предлагаю. Мне просто интересно как это будет реализовано в SC. Свою реализацию прикрепил. Итак, тазик. 1. Создаем две формы. В первой одно поле типа текст для ввода адреса электронной почты. Во второй, два поля: одно типа текст ("логин"), другое типа пароль ("пароль"). Каждая из форм содержит кнопку типа "сброс" и типа "сабмит". Создаем контейнер вверху страницы для системных уведомлений (например, div) 2. Каждая форма проверяется по нажитию кнопки сабмит своим валидатором (можно одним и тем же) на пусто не пусто в каждом поле. Все поля конкретной формы обязательны к заполнению. 3. Логика по нажатию кнопки "сабмит": если в какой либо форме найдены ошибки - должен быть выведен системный алерт со списком всех ошибок, поля с ошибками должны быть подсвечены, область системных уведомлений должна быть очищена. Данные на сервер не должны быть отправлены. Соответственно если в данный момент подсвечены поля другой формы они должны быть переведены в обычное сотояние. Данные не должны быть сброшены. Если ошибок не найдено в области системных уведомлений должно быть выведено уникальное объявление (Например: "Форма 1 Ошибок не найдено"). Данные проверенной формы на сервер не отправляются. Если подсвечены поля другой формы они должны остаться подсвеченными. 4. По нажатию кнопки "сброс" поля конкретной формы очищаются, область системных уведомлений очищается, если поля формы подсвечены, то они переводятся в обычное состояние. Моя реализация основана на применении технологии Observer - Mediator - Controller. Когда-то читал сабж на сайте Артемия Лебедева "Слабое связывание компонентов в JavaScript. Произвольные события". В кратце суть технологии. В процессе выполнения задачи каждый объект может иметь несколько состояний. Эти состояния именуются. Как только к-л состояние возникает, вызывается метод notify() данного объекта, который оповещает всех подписавшися (observers) на это состояние данного объекта. Mediator - отдельный программный код подписки для каждой конкретной ситуации. Лан, тут все пишут сколько на это ушло времени... В данном случае 3 минуты. На продумывание "тазика" - 15 минут. Ессно дело все это без учета того, что основные классы были мной оформлены и переработанны более полугода назад. OI.utf8.rar

<?php echo $_SERVER['DOCUMENT_ROOT'].dirname(__FILE__);?>

2 Mihahail, JS - это не только document.write(); <script type="text/javascript"> var newCODE='<br><table><tr><td><fieldset style="border: 1px solid #494949"><legend>Миничат:</legend>$CHAT_BOX$</fieldset></td><td>' + informer() +'</td></tr>', element; siteDIVs=document.getElementsByTagName("div"); ..... </script> function informer () { return "<div style=\"border-bottom: 1px solid black;\"><a href=\"http://aonmap.ru/forum/11-27-0-17\">Гро'гот, Орк Наемн</a></div>"; }

2 ekklesiast. имхо: для параноиков. в 99% случаев используется для взлома уязвимость конкретного алгоритма, а не то как будет назван файл с этим алгоритмом. то есть без разницы как назвать, смысл в том, что уязвимый скрипт сервером выполняется, а соответственно можно сделать пакость. С другой стороны - раз такой сабж опубликован, значит взломщик - осведомлен. и ему потребуется чуть больше времени.