WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 ||

«ОРЛОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ДЕКАДА НАУКИ 2006 ФИЗИКО-МАТЕМАТИЧЕСКИЙ ФАКУЛЬТЕТ МАТЕРИАЛЫ СЕКЦИИ-СЕМИНАРА Языки программирования и технологии «Оберон»: ...»

-- [ Страница 2 ] --

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

Завершим затянувшиеся размышления высказыванием известного ижевского ученого и преподавателся Н.Н. Непейводы, сказанной, правда, по поводу университетского обучения, но в не меньшей степени применимой к школьному: "Чтобы подготовить хороших специалистов (программистов), нужно готовить аналитиков. Чтобы попасть в цель, нужно целиться выше це ли. Все равно не более 20% [учащихся] станут аналитиками, но оставшиеся станут специали стами именно того класса, который нужен российским фирмам".

История и перспективы развития отечественных разработок в области СУБД (обзор) Рюмшина О. А.

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

Проблема эффективной автоматической обработки данных особенно остро встала к кон цу 60-х: возможности «бумажной информатики» были исчерпаны. Вслед за идеей хранения данных в электронном виде появилась проблема их структурирования, а также быстрого досту па к нужной информации и сбора статистических сведений. Поэтому с конца 60-х годов XX в крупнейшие научные коллективы страны задумались над вопросом создания эффективной мо дели данных и ее практической реализации. В то время развитие вычислительной техники на чало набирать высокие темпы во всем мире, и в этом отношении СССР был одним из первых.

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

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

ОКА. Основана на иерархической модели. Рекомендовалась в качестве инструмента для анализа производственной деятельности комбината «Правда» (1976 г.) [1]. Здесь же в качестве альтернативы предлагалось использовать и другие отечественные СУБД – «Кама» (телемони тор Института кибернетики АН УССР), «Набоб» (ВГПТИ ЦСУ СССР, конец 1970-х гг., сетевая типа CODASYL), «Сиод», «Банк» (Пермский НИИУМС), «Синбад» (МНИПИ АСУ ГХ) – менее известные ныне. Здесь же можно вкратце упомянуть и другие разработки - «Дисод» (НИИ «Восход»), «Ребус» (Всесоюзный научно-исследовательский институт непромышленной сфе ры), «Седан» (Советско-болгарский институт «Интерпрограмма» в Софии), «Вера» (реляцион ная СУБД, Министерство легкой промышленности Латвии), «Диамс» («Диалоговая многотер минальная система», представляет собой аналог американской СУБД MUMPS для СМ ЭВМ).

«Ока» и «Дисод» имели чрезвычайно развитое окружение, функционально значительно более богатое, чем у систем-прототипов. [2] ИНЭС. Иерархическая СУБД. Создана во ВНИИСИ АН СССР (ныне - Институт систем ного анализа РАН) в конце 70 гг. В конце 80-х получила широкое распространение. Была уста новлена более чем на 2 тыс. крупных предприятий бывшего СССР [3]. В ИНЕС впервые среди иерархических СУБД применена идея самоописываемости баз данных, предложенная ранее для реляционных систем [2]. На ней реализовано более тысячи крупных проектов. Сейчас эта база перенесена на персональные компьютеры, и под названием «Ника» принадлежит отечественной компании Cognitive Technologies [4].

МИРИС. Поддерживает двухуровневую иерархическую схему. Использует так назы ваемый внутренний системный номер записи, не меняющийся при модификации файлов, что позволяет строить индексы, не зависящие в некотором смысле от состояния файла. Позволяла использовать разномашинные комплексы. [5] Применялась для создания и дальнейшего сопро вождения библиотечных информационных баз данных. Применялась в образовании – легла в основу лабораторного практикума на кафедре вычислительной техники института точной ме ханики и оптики в Ленинграде (ныне – СПб ГУ ИТМО) (1988 г.) [6].

КВАНТ. Поддерживает двухуровневую иерархическую модель данных. Была создана для использования на ЕС ЭВМ под управлением ОС РВ [5].

СЕТЬ. Основана на сетевой модели данных (откуда и название). Обладает возможно стью указывать вид включения и исключения записей-членов в набор [7].

ПАРМА. Сетевая СУБД типа CODASYL для платформы ЕС ЭВМ с операционной сис темой ОС ЕС. Была создана НИИУМС (г. Пермь). [2] СЕТОР. Сетевая СУБД с двухуровневой схемой. В свое время являлась одной из наибо лее развитых по модели данных среди систем для малых ЭВМ. Имела средства ведения систем ного журнала, восстановления БД, мультизадачный режим работы и др. преимущества. Суще ствовал ее вариант для микроЭВМ (в ОС РАФОС – Unix’оподобной отечественной ОС). Предъ являла сравнительно меньшие требования к памяти. [5] КОМПАС. Опирается на сетевую модель. Разработана в ВЦ АН СССР. Выполнение проекта в плане фундаментальных исследований без давления жёстких заданий и сроков позво лило ее участникам сосредоточиться на достижении максимальной эффективности и универ сальности всех компонентов системы. В частности, были выбраны трудные в реализации, но наиболее удобные для пользователя варианты: претрансляторы для всех активно применяемых языков программирования вместо CALL-интерфейсов, компилятор программ загрузки и моди фикации данных для произвольных форматов ввода вместо стандартного или настраиваемого загрузчика данных и пр. В процессе разработки были замечены ограниченность и неоднород ность предложений CODASYL, в связи с чем выдвигались многочисленные предложения по улучшению основной модели системы, часть из которых была реализована. С появлением функционально полной промышленной многомашинной версии системы, в значительной сте пени ушедшей вперед от предложений CODASYL, возникла необходимость сформулировать новое состояние модели данных – была воплощена согласованная концепция, определившая общие перспективы и конкретные направления дальнейшей разработки. [5] Ей присущи сле дующие свойства, которые позволяют обеспечить быстрый поиск в пределах нескольких секунд независимо от объема базы данных (БД):

• множество точек входа в БД, что позволяет начинать поиск практически с любого мас сива;

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

• возможность организации поиска по кратчайшему пути;

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

Помимо сказанного, система КОМПАС была разработана как для ЕС ЭВМ, так и для СМ ЭВМ, что сделало возможным создание оперативной системы на базе многомашинной ассо циации с разными типами ЭВМ. [8] С использованием СУБД «Компас» был построен топлив ный архив для оперативного получения информации справочного характера по параметрам эксплуатации исследовательского реактора ВВР-М [9].

ФОБРИН. По модели данных можно отнести к реляционным системам, если не рас сматривать средства манипулирования данными как составную часть модели. Обеспечивает создание и поддержку словаря данных системы, поддержку библиотеки процедур на языке сис темы, ввод, обновление, обработку данных, вывод отчетов. [5] БАРС. Относится к классу реляционных СУБД. Архитектура и языковые средства близ ки к Ingres. Ядро написано на Assembler’е, что позволяло иметь к нему доступ из разных языков программирования. Поддерживала различные физические способы хранения отношений, ис пользовала текстовые данные переменной длины с экономным хранением и концепцию внут реннего идентификатора кортежа для повышения эффективности доступа к данным. В ней был применен принцип самоиспользования для описания структуры БД. [5] ПАЛЬМА. Семейство совместимых реляционных СУБД. Создано в Институте киберне тики АН УССР для платформ ЕС ЭВМ, СМ ЭВМ и IBM-совместимых персональных компью теров. [2] ИНТЕРЕАЛ. Семейство совместимых реляционных СУБД для различных программно аппаратных платформ. Разработано в Воронежском СКТБ «Системпрограмм». [2] ИНТЕРБАЗА. СУБД общего назначения (так называемая смешанная), поддерживающая сетевую и реляционные БД. [10] НИКА. Создатель – отечественная компания Cognitive Technologies. Представляет собой иерархическую базу данных, легко интегрирующуюся с Web. Для работы с ней и управления ею вполне достаточно браузера, Web-сервера и собственно базы данных. Поддерживает доста точно мощный язык запросов, который позволяет выбирать из базы различные объекты, нала гая при этом определенные ограничения как на родителей объекта, так и на его потомков. При чем отобранные данные выделяются в отдельное дерево, которое в дальнейшем можно исполь зовать как самостоятельный объект. «Ника» также позволяет в любой момент изменить струк туру базы или состав любого объекта. Используется компанией в некоторых своих программ ных продуктах в качестве встроенной СУБД, в частности, в архиве «Евфрат». В качестве одного из примеров использования СУБД «Ника» можно привести Web-сервер Государственного ис торического музея. [4] ЛИНТЕР. Создана научно-производственным предприятием «Релэкс» (Реляционные Экспертные Системы), Воронеж. Примечательной особенностью системы является разработка комплекса средств защиты СУБД ЛИНТЕР и сертификация в 1997 году Гостехкомиссией Рос сии ее соответствия на 2-ой класс по показателям защищенности от несанкционированного дос тупа к информации. Обеспечивает защиту данных в условиях распределенной обработки. На данный момент столь высокий уровень защиты информации не обеспечивает ни одна из СУБД!

[11,12] ODB-JUPITER. Объектно-ориентированная СУБД – первая из подобных в России. Соз датель – научно-производственный центр «Интелтек Плюс». На её основе создана полнотексто вая информационно-поисковая система «ODB-Text» (поддерживающая механизм OLE) – мощ ный программный комплекс, с помощью которого можно создавать электронные версии доку ментов, использующихся в документообороте предприятия. Таким образом, становится воз можным создание архивов документов сложной структуры, объединяющих текст, фотографии, изображения, видео- и звуковые фрагменты. Обеспечивается контекстный поиск, поиск смы словых понятий и поиск по запросам на естественном языке. [13,14] ОМЕГА. Теоретический проект Челябинского государственного университета. Парал лельная СУБД для кластеров, основанная на реляционной модели данных (при этом предусмат ривается поддержка объектов сложной структуры с сохранением функциональности, присущей реляционной модели). [15] Представляют интерес и оригинальные авторские теоретические разработки, такие, на пример, как представленная в работе [16] реляционно-иерархическая модель данных с элемен тами объектно-ориентированного подхода.

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

Литература 1. Берс А.А., Поляков В.Г. Системный анализ производственных процессов по выпуску газеты «Правда».

2. Когаловский М.Р. Энциклопедия технологий баз данных. М.: «Финансы и статистика», 2002. Источник: Корпоративный сервер Издательства «Открытые Системы», журнал «Открытые системы», #01/2002, постоянный адрес статьи:

http://www.osp.ru/os/2002/01/066.htm.

3. Российская газета, 16.05.2003. Артем Коновалов. Побеждает союз науки и бизнеса // Минсвязи России подвело итоги конкурса по ФЦП «Электронная Россия».

4. Валерий Коржов, 26.11.2000. Computerworld #44/2000.

5. Программное обеспечение информационных систем (сборник статей). М.: «Наука», 1989.

6. http://cs.ifmo.ru/department/history/table/.

7. www.rus-lib.ru/book/28/ps/04/.

8. Муромский А.А., Туляков К.В. Организация справочной системы на основе сетевой системы управления базами данных.

9. Исакас И.Э., Панева Г.В. Построение топливного архива с использованием СУБД «Компас». Препринт ЛИЯФ-1366, Л., 1988.

10. Бипгтпнер Ю. Интербаза — система управления базами данных нового поколения // Вычисл. Техника соцстран. Вып. 26.

11. www.relex.ru.

12. www.citforum.ru/products/relex/made_in_russia/.

13. Андреев А. М., Березкин Д. В., Кантонистов Ю. А. Среда и хранилище: ООБД. Обзор по объектно-ориентированным базам данных, включающим средства разработки. Мир ПК #4/98.

14. http://www.inteltec.ru/publish/themes/objtech.shtml.

15. Соколинский Л.Б., Цымблер М.Л. Проект создания параллельной СУБД Омега на базе суперкомпьютера МВС-100/1000.

16. Ермаков И. Е. Реляционно-иерархическая модель управления данными ORIENT //Сборник трудов Первой международной научно-практической конференции «Современные информационные технологии и ИТ-образование». – М.: МАКС-ПРЕСС, 2005.

Модульно-Странично-Блочная cистема создания и управления динамическим WEB-сайтом Поляков Е.Г.

1. Введение Одними из ключевых решений для современных Интернет проектов являются техниче ские решения, то есть системы управления сайтом. Логически их можно разделить на системы управления наполнением ресурса, так называемые Content Management System (CMS) и про граммы для продвижения, ведения, мониторинга и анализа статистики.

Нами предлагается новая концепция построения, создания и управления динамическими WEB-сайтами, а также CMS-системами – это Модульно-Странично-Блочная система или со кращенно MPBS (Module Page Block System).

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

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

2. Показатели, характеризующие MPBS Существует ряд характеристик, учитываемых нами при создании MPBS.

Универсальность системы — показатель применимости продукта для решения различ ных задач. Например, возможность использования данной платформы для разработки электронных СМИ, онлайн-магазинов или промо-сайтов.

Гибкость архитектуры — наличие возможности изменять структуру сайта, данных, в том числе:

• возможность редактирования шаблонов дизайна;

• наличие API–интерфейса для разработки приложений;

• модульно-блочная структура подключения объектов/функционала;

• возможность быстрой перенастройки сайта.

Функциональные возможности:

• формирование динамической структуры сайта;

• поддержка многоязычности сайтов.

Возможность создания функциональных блоков — создание стандартных и специфиче ских функциональных блоков в системе, таких как:

• новостная лента;

• каталог товаров;

• гостевая книга;

• опрос;

• формы для обратной связи.

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

3. Терминология Введем некоторые базовые понятия, которыми будем оперировать далее при построении MPBS.

Класс – множество объектов, имеющих общую структуру и общее поведение.

Шаблон – принцип построения части WEB-страницы, или ее целиком, описанный с по мощью языка HTML и содержащий параметр: “Что на что менять” в фигурных скобках (обо значим для удобства). В одном шаблоне может быть реализовано бесконечно много параметров “Что на что менять”. Параметр “Что на что менять” может содержать вложенную структуру па раметров, иметь вид иерархической структуры, а также включать в себя другие шаблоны или самого себя (рекурсия). Шаблоны используются, как составная часть классов блоков или стра ниц.

Конечное отображение – HTML-код, состоящий из одного или нескольких отдельно взаимосвязанных частей шаблонов и полученный в процессе парсеровки (замены) параметров “Что на что менять”.

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

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

Программный код – код, написанный на языке PHP 5.

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

Система связей – правила представления внутренней информации на сервере и ее ото бражения пользователю посредством MPBS. Ее можно представить в виде:

[название модуля].[ключ страницы]?<набор необязательных параметров Имя1 = Значение1 & … & ИмяN = ЗначениеN >.

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

Здесь пунктирной стрелкой обозначена фраза “запрос данных” или “передача управле ния элементу”, а сплошной – фраза “получение результирующих данных”.

Конечное ото бражение Контроллер Модель Конечное ото бражение Браузер пользователя Схема Из схемы можно сделать следующие выводы:

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

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

Контроллер выступает в роли “клея” между конечным отображением и моделью, сосредоточивая в себе бизнес-логику сценария;

• с точки зрения браузера конечные отображения вторичны, контроллер первичен;

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

5. Структура MPBS MPBS состоит из нескольких базовых классов:

Класс блоков – множество минимальных единиц построения и отображения информа ции в MPBS, носящих название функциональные блоки, реализованных с помощью исполняе мого файла и шаблона. Функциональные блоки также могут быть использованы для обработки информации на сервере, передачи параметров в MPBS. Пример: новостная лента, опрос и т.д.

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

Элементом класса страниц является функциональная страница. Логически данную функциональную страницу можно разбить на три части: верхняя, главная и нижняя. Централь ная часть наиболее важна для нас. В ней происходит взаимодействие контроллера с моделью и с конечным отображением. Покажем класс страниц на схеме 2.

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

Схема Класс страниц Мн-во Мн-во функциональных страниц функциональных блоков Мн-во Шаб лонов по строения чер тежа блоков Конечное отображение всей стра ницы Отображение блоков на странице Главная часть Шаблон Функциональная Верхняя Конечное страница часть отображение части стра Исполняющийся ницы файл Нижняя часть Класс модулей – является верхним уровнем MPBS, состоит из множества модулей, в свою очередь, состоящих из функциональных страниц, реализованных в классе страниц и взаи мосвязанных друг с другом, и исполняемого файла – контроллера текущего функционального модуля, в котором заключен код бизнес-логики взаимодействия между страницами, а также со держит в себе программный код, позволяющий создавать и развивать многофункциональные проекты.

Модуль как элемент класса модуля имеет параметр: “главная страница”, данная страница будет иметь по умолчанию значение index.php.

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

6.Принцип построения MPBS Система строится таким образом, что сначала загружается в область памяти модель(ядро данной системы), выполняется инициализация базовых классов MPBS, начальных параметров системы, таких как название базы данных с которой работает данная система, пользователь и пароль, обладающие правами записи, чтения и удаления записей из БД, указание директорий где содержатся подключаемые исполняемые файлы модулей, страниц и блоков, и т.д.

Следующим шагом является непосредственная начальная работа или состояние кон троллера. Контроллер, используя SQL-запросы к базе данных (название БД, имя и пароль пользователя, получены в начальных параметрах системы), получает динамическую информа цию о сайте. Туда входит информация о зарегистрированных в системе :

• название и внутреннее описание параметров функциональных блоков и функцио нальных страниц;

• название и внутреннее описание параметров модулей;

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

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

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

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

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

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

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

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

И наконец, последнее действие контроллера – получение конечного отображения и его переда чи браузеру.

Литература 1. Д. Котеров, А. Костарев. PHP 5.С-П.: БХВ-ПЕТЕРБУРГ.

Pages:     | 1 ||



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.