Asp названия разделов и пути


Содержание

Как указать путь к файлу для работы

21.11.2020, 01:39

Как правильно передать путь к файлу корневого каталога
Реализую в своей веб-службе возможность по нажатию кнопки запускать exe-файл на сервере.

Как правильно указать путь к базе в строке коннекции?
Привет всем! Выложил defoult.asp на бесплатный хостинг ( допустим.

File Uploading (или как получить полный путь к файлу на клиенте)
Приветствую Вас. У меня ситуация следующая: Необходимо загрузить файл с клиента на сервер (в БД).

Как узнать абсолютный путь к файлу index.htm в ASP-ишке?
Подскажите плиз как реализовать следующее: есть путь http://host/dir/index.htm как узнать.

Как «скрыть» путь к файлу картинки?
Есть скрипт, который в зависимости от значения некоторой переменной выдает картинку. Например, x=1.

Статья: Представление в Internet содержимого каталога средствами ASP

Представление в Internet содержимого каталога средствами ASP

В этой статье я на примере расскажу, как используя ASP (Active Server Pages) можно построить содержимое каталога Web аналогично тому, как это выглядит на FTP сервере.

Постановка задачи: На Web-сервере есть каталог, например: C:\InetPub\wwwroot\user1. Пусть данный каталог имеет несколько вложенных каталогов и набор файлов в этих каталогах. Примерная структура папок представлена на Рис. 1.

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

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

Результат должен выглядеть примерно следующим образом:

Находимся в папке C:\Inetpub\wwwroot\user1\folder1\subfolder2:

На данном скриншоте показан пример меню. Страница menu.htm разделена на два фрейма. В левом фрейме находится файл list_files.asp, а правый фрейм используется для отображения файлов, ссылки на которые находятся в левом фрейме. В левом фрейме можно свободно перемещаться по папкам. Т.о. можно организовать меню пользователя.

Решение: Ключ к решению данной задачи — это использование MicrosoftR Scripting Library. Нас будет интересовать такой объект этой библиотеки, как FileSystemObject. FileSystemObject предоставляет объектную модель доступа к файловой системе. Далее, пользуясь средствами языка написания сценариев VBScript, выполняемого на Web-сервере, можно написать одну ASP-страницу, которая будет выполнять всю работу. Итак, приступим.

Листинг файла list_files.asp:

‘Отключаем кэширование страницы

If StrComp(CStr(arr(i)), CStr(arr(j)), vbTextCompare) «» Then

‘Ищем последнее вхождение символа разделителя каталогов «\»

‘Получаем имя каталога верхнего уровня

Response.Write »

» ‘Вывод HTML

‘Для украшения используем графический файл open.gif — изображение открытой папки.

Response.Write »

«

‘Основной цикл вывода названий каталогов

For i = 0 To UBound(arr)-1

Response.Write »

«

Response.Write »

«

‘Заменяем «\» на «/» для использования в URL

‘Атрибут target нужен для указания ссылки на фрейм

Абсолютный и относительный путь к файлам

Категории блога

При разработке сайта часто приходится прописывать пути к файлам, ссылки на документы, страницы.
В книгах по компьютерным технологиям можно часто встретить употребление терминов абсолютного и относительного пути к файлам. Часто автор не разъясняет, что означает тот или иной путь. Читатель, соответственно, путается, когда автор в последствии говорит об использовании абсолютного и(или) относительного пути.
Допустим, у Вас есть сайт и Вам нужно создать гиперссылку(ссылку) на одну из страниц сайта. Здесь нужно выбрать какой использовать тип пути: относительный или абсолютный.

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

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

Оглавление

Абсолютный путь

Когда ссылка представляет из себя полный URL файла или страницы, это и есть абсолютный путь. При этом в адресе должен присутствовать используемый протокол. Например, http://www.uamedwed.com — это абсолютный путь к конкретному веб-сайту. В данном случае абсолютный путь к главной странице моего блога. Где протоколом является http, а www.uamedwed.com доменом(именем).

Если указывать ссылку на католог, например http://yourdomain.ua/web/ то будет загружаться(отображаться) индексный файл. Это правило применимо в основном к статическим сайтам. Так как при использовании языка программирования можно создать внутренний роутинг. Индексный файл обычно представляет из себя файл с именем index.php, index.html, index.phtml, index.shtml. Для того что бы использовать другой индексный файл, нужно создать в нужной директории файл с именем .htaccess, и в нем прописать некоторую директиву. Изменение и создание файла .htaccess, как и роутинг с помощью языка программирования, выходит за рамки этой статьи.

В основном абсолютный путь используется, тогда, когда нужно сослаться на другой сайт. Иными словами если Вы хотите отправить посетителя на другой сайт, то нужно использовать абсолютный путь. Хотя, такой путь можно использовать и на собственном сайте. Но многие придерживаются того, что ссылки внутри сайта должны быть относительными.
Использование абсолютного пути может повлечь за собой некоторые проблемы. Например при переносе сайта с локальной машины на сервер(это в том случае, если вы использовали на локальной машине адреса в виде http://localhost/sitename.ua/…). Трудности могут возникнуть, тогда, когда появится необходимость в смене домена(имени сайта). Хотя, все эти трудности решаемы, но на них придётся потратить некоторое количество времени.
Когда есть минусы, значит должны быть и плюсы. Возьмём к примеру такую ситуацию, как кража контента с вашего сайта. На практике я уже не раз убедился в том, что текст воруют целиком, при этом не оставляя обратной ссылки на оригинал. Так вот, при использовании абсолютных путей, можно получить обратные ссылки с сайта, на котором находится сворованный контент. Но это только в том случае если у Вас внутренняя перелинковка осуществлялась с использованием абсолютных путей. Хотя это не всегда работает, но я уже не раз замечал появление ссылок с чужих сайтов, на которых был расположен мой контент.

Немного отступив от темы хочу вкратце рассказать про то что такое URL.

Каждая веб-страница или документ в сети Интернет имеет собственный уникальный адрес, который и называется URL.
URL — единообразный локатор (определитель местонахождения) ресурса. Расшифровывается URL как Uniform Resource Locator(унифицированный адрес ресурса). Можно так же встретить и такую расшифровку как Universal Resource Locator(универсальный локатор ресурса). Этот способ записи адреса стандартизирован в сети Интернет. Более общая и широкая система идентификации ресурсов URI постепенно заменяет термин URL.
URI — это символьная строка, которая идентифицирует какой-либо ресурс: документ, файл, и т.д. Конечно, здесь подразумеваются ресурсы сети Интернет.

Относительный путь

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

Путь относительно документа

Именно путь относительно документа используется чаще всего. Такие ссылки ещё называются локальными. В основном такой путь используется тогда, когда текущий и связанный документ(страница) находятся в одной директории. Если переместить документ в другую директорию, то путь(ссылку) придётся менять. Хотя можно ссылаться и на документы(страницы) из других директорий. Для этого путь прописывается от текущего документа до целевого документа(страницы). При этом путь относительно документа должен задаваться в зависимости от структуры директорий.
Возьмём к примеру простейшую структуру статического сайта.

Предположим, что каждое изображение в каталоге images нужно вставить в соответствующие страницы home.html, products.html, contact.html. Для того что бы вставить изображение к примеру на страницу «home.html», нужно прописать путь, где расположено изображение. Если использовать путь относительно документа, то нужно будет прописать в коде страницы следующее:

Этот код для вставки изображения на страницу — неполный. Так как он не содержит нескольких важных атрибутов, таких как ширина, высота и др. Атрибут src, здесь служит для указания пути к файлу. Здесь опущены все остальные атрибуты, так как они сейчас не столь важны. Главное сейчас, что бы Вы имели представление о том, как выглядит путь относительно документа.
При использовании путей относительно документа отсутствует часть абсолютного пути. Часть абсолютного пути, здесь усекается, как для текущего документа(страницы), так и для связанного. Здесь используется только та часть пути, которая всегда меняется.
Напомню ещё раз про то, что при использовании пути относительно документа, нужно учитывать исходное расположение файлов.

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

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

Как видно из приведённого выше кода, к пути теперь добавилось следующее: ../. Как раз эта последовательность символов ../ и служит для перехода на одну директорию(уровень) выше в иерархии каталогов. Путь в вышеприведённом коде можно прочесть так: «Перейти на один каталог выше(назад), зайти в директорию images и взять от туда файл products.png«.
Если ../ означает переход на одну директорию(уровень) выше в иерархии каталогов, то символ / обозначает переход на один уровень ниже.
Последовательность символов ../ можно использовать в пути неоднократно. Например, если файл products.html переместить в три директории вложенные в друг друга, то нужно будет использовать следующий код:

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

Путь относительно корня сайта

Вы наверное уже поняли что пути относительно документа используются очень часто. Но при их использовании существует одна проблема. Которая заключается в том, что при смене структуры директорий, пути придется менять.
Но такая проблема решаема при использовании путей относительно корня сайта. Где путь указывается от корневой директории до документа.
Все пути относительно корня сайта начинаются со знака /. Только здесь, в отличии от путей относительно документа этот знак используется для указания корневой директории. Потому, что он используется в начале пути.
Путь относительно корня сайта позволяет перемещать некоторые файлы, без ущерба для ссылок. Этот тип пути Вы сможете использовать только на web-сервере в интернете, или на web-сервере расположенном на локальной машине.

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

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

Например, /images/products.png обозначает, что файл products.png находится в папке images, которая расположена в корневом каталоге.

Самый простой способ определить корневой относительный путь — взять абсолютный и отбросить http:// и имя хоста.

Пример
Иногда бывает нужно, что бы информацию одной страницы использовали другие страницы сайта. Часто это делается для того что бы сократить количество повторяемого кода на каждой странице. Допустим есть файл _contact.html, который содержит информацию о телефонных номерах, e-mail и содержит изображение contact.png. (Пускай это будет небольшая таблица, которая будет располагаться на каждой странице сайта.)

Следующий код предназначен для вставки изображения «contact.png».

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

Я надеюсь, что Вы уже знаете какой тип пути использовался в вышеприведённом коде. Если нет, тогда посмотрите приведённое выше определение пути относительно документа.
Теперь, когда посетитель зайдет на такие страницы сайта как home.html, contact.ntml, он увидит прекрасно отображаемую страницу. В каждую из которых вставлен файл _contact.html, в который, в свою очередь, вставлено изображение contact.png.
Другими словами зайдя, к примеру, на страницу home.html, происходит следующее: «Выполняется код основной страницы home.html. Затем вставляется и исполняется код страницы _contact.html. Код страницы _contact.html, говорит что нужно перейти в директорию images и взять от туда изображение contact.png«.
Если опустить сам код для вставки, то все работает отлично. Но вот если запустить страницу products.html, то произойдет ошибка. Так как код будет пытаться найти директорию images и файл contact.png в директории products. Но такой директории там не существует, из за чего собственно и возникает проблема.
Становится ясным, что использовать путь относительно документа здесь нельзя.
Конечно здесь можно использовать абсолютный путь. О плюсах и минусах данного подхода я говорил выше.
В общем говоря, это одна из ситуаций, когда нужно использовать путь относительно корня сайта. При использовании пути относительно корня сайта, ссылка будет всегда начинаться с корневого каталога(корня сайта). Такой тип пути позволит использовать код для вставки, например изображения, независимо от иерархии сайта, и его директорий.
Использование пути относительно корня сайта в вышеприведённом примере, позволит избежать проблем, со вставкой изображения. Потому как независимо от того где будет использовать такой тип пути, он всегда найдет указанный в нем файл.
Путь относительно корня сайта, очень похож на путь относительно документа. Для того что бы создать путь относительно корня сайта, нужно добавить символ / в начало пути.


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

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

Компания ASP Linux и ее дистрибутивы

История компании ASPLinux и одноименного дистрибутива началась в январе 2000 года в Долгопрудном, в Московском физико-техническом институте. Основателем компании ASPLinux была фирма SWsoft, созданная выпускниками ФизТеха и имевшая в тот момент офисы в Сингапуре, США и России. Руководство компании SWsoft небезосновательно решило, что России необходим свой дистрибутив Linux. В то время как в мире ОС Linux к тому моменту была самой динамично развивающейся операционной системой, RedHat Linux признавался «продуктом года» (Network Magazine и другие издания), в России продажами Linux занимались только фирма Linux Ink. и группа IPLinux Team, еще не оформившаяся в коммерческую фирму.

ASPLinux была создана как независимая компания со 100%-но российским капиталом. Техническим директором ее стал Максим Цыпляев, который ранее возглавлял фирму «ФизТехСофт», известную своей разработкой операционной системы PTS-DOS — отечественного клона MS-DOS, сертифицированной на соответствие требованиям Гостехкомиссии Росии и поэтому применявшейся в госструктурах. Название компании было образовано из первых букв словосочетания Application Service Provider, то есть поставщик (удаленного) прикладного сервиса.

Работа всех разработчиков до прихода в ASPLinux была связана с программированием в среде Unix/Linux. Наиболее известными сотрудниками были Леонид Кантер и Александр Каневский, создававшие (практически вдвоем) дистрибутив Black Cat Linux, о котором уже было рассказано выше. Другие разработчики тоже были участниками opensource-проектов, например, Кирилл Конягин, Григорий Бакунов, Павел Гашев. И программисты, и менеджеры обладали (и сейчас обладают) качественным техническим образованием — это выпускники МФТИ, МГУ, Донецкого технического университета, МИЭМа, и других вузов.

Название: Представление в Internet содержимого каталога средствами ASP
Раздел: Рефераты по информатике
Тип: статья Добавлен 11:21:09 29 марта 2011 Похожие работы
Просмотров: 4 Комментариев: 14 Оценило: 2 человек Средний балл: 5 Оценка: неизвестно Скачать
» & » .. » & «
» & arr(i) & _

‘Основной цикл вывода имен файлов

For i = 0 To UBound(arr)-1

Response.Write »

Рис. 32. ASP Linux Release Candidate 3
Рис. 33. ASP Linux 7.1

Весной 2000 года первые программисты ASPLinux приступили к разработке программы установки, менеджера загрузки операционных систем ASPLoader, программы для установки ASPLinux с сетевых ресурсов Espresso Download и пересборке пакетов. Осенью 2000 года бета-версию дистрибутива ASPLinux уже раздавали посетителям выставки Softool в Москве, а в январе 2001 года был выпущен ASPLinux Release Candidate 3 (рис. 32), предназначенный для открытого тестирования. Несколько тысяч коробочных версий этого предшественника первой версии ASPLinux Express были бесплатно разосланы всем желающим в разные уголки России, Украины, Беларуси и Казахстана в обмен на обязательство прислать отчет о тестировании. Те, кто мог, приходили в только что снятый московский офис ASPLinux на Большой Якиманке, чтобы записать дистрибутив на свои болванки.

В то же время ASPLinux вступил в переговоры о сотрудничестве с разработчиками дистрибутива Black Cat Linux. Переговоры об объединении завершились успешно: обеим сторонам совместная работа представлялась гораздо более продуктивной и привлекательной, нежели конкуренция. И в марте 2001 года было объявлено о слиянии двух дистрибутивов. Лидеры Black Cat Linux Team заняли руководящие посты в ASPLinux: Леонид Кантер стал руководителем отдела разработки дистрибутива, а Александр Каневский — ответственным за безопасность в дистрибутиве.

Первая версия ASPLinux под номером 7.1, о выходе которой было объявлено 16 апреля 2001 года, была представлена на пресс-конференции, прошедшей 11 мая того же года. Выбор номера версии был обоснован тем, что дистрибутив был основан на ASPLinux RC 3 и Black Cat Linux версии 6.2. Таким образом, дистрибутив ASPLinux унаследовал номер версии от Black Cat. К тому же это соответствовало нумерации версий, принятой в дистрибутиве Red Hat (16 апреля 2001 года вышла версия 7.1 от Red Hat). Между прочим был выпущен и дистрибутив ASPLinux 7.0, но он был напечатан в Сингапурском и Корейском филиалах ASPLinux и в России не распространялся.

ASPLinux 7.1 был выложен на ftp-сервер компании и был выпущен в виде двух коробочных версий — простейшей, ASPLinux 7.1 Standard (сам дистрибутив, руководство по установке и 30 дней технической поддержки) и ASPLinux 7.1 Deluxe. В эту версию были включены дополнительные диски с документацией, приложениями, офисным пакетом Sun StarOffice 5.2 и программным продуктом OS Selector компании Acronis, а также печатная документация — руководство по установке, руководство пользователя и руководство по Sun StarOffice 5.2. Кроме того, покупателям этой версии предоставлялась 90-дневная техническая поддержка. Первыми покупателями коробочных версий дистрибутива ASPLinux 7.1, названного «Мрия», были посетители выставки компьютерных технологий «Комтек», где ASPLinux выступал совместно с российской антивирусной компанией «Диалог-Наука».

Для успешного распространения разрабатываемого дистрибутива требовалось создать службу технической поддержки, написать подробную документацию, издать справочную литературу, разработать учебные курсы, создать сеть распространения по всей стране. Все это было постепенно сделано. Первые учебные курсы по ASPLinux были разработаны преподавателями кафедры вычислительной математики МФТИ совместно со специалистами ASPLinux, и были запущены в марте 2001 года. Это были четыре отдельных курса — «Установка и настройка Linux», «Архитектура ОС Linux», «Сетевое программирование в ОС Linux», «ОС Linux: установка и настройка». К концу 2003 года спектр курсов по ASPLinux расширился за счет двух новых учебных центров: центра компьютерного обучения «Специалист» при МГТУ им Н.Э.Баумана и Академии Корпоративных Систем, начавших читать сертифицированные ASPLinux курсы по администрированию Linux и безопасности в Linux.

Летом 2001 года начали заключаться первые соглашения с компаниями-дистрибьюторами программного обеспечения. На сегодняшний день дистрибьюторами ASPLinux являются компании 1C, Медиахауз, БУКА, Mont Distribution, Softline, CPS, а также ряд региональных компаний — поставщиков компьютеров и программного обеспечения. Продажами ASPLinux занимается и истинно линуксовая компания — LinuxCenter из Санкт-Петербурга, которая высылает диски по почте. Так что теперь дистрибутив ASPLinux продается более чем в 60 городах России и стран СНГ, и всегда может быть доставлен по заказу пользователей в любую точку России.

В июле 2001 года была разработана программа ОЕМ-сотрудничества и были заключены первые ОЕМ-соглашения. Производителям компьютерной техники предлагалось предустанавливать ASPLinux на собираемые ими компьютеры и вкладывать в компьютер ОЕМ-комплект ASPLinux, состоящий из дистрибутива ASPLinux и руководства «Быстрый старт», описывающего установку ASPLinux и основы работы в этой системе. Партнерами ASPLinux в настоящий момент являются такие компании, как Rover Computers, Формоза, R-Style, Инел, Desten Computers, Nix, Ф-центр, ряд относительно небольших компаний, а так же региональных компаний из Иркутска, Барнаула, Нижнего Новгорода, Костромы и других городов. К концу лета 2001 года ASPLinux также начал сертифицировать персональные компьютеры и серверы мировых и российских производителей на совместимость с ASPLinux. Произведена сертификация серверов и ПК компаний R-Style, Kraftway, Dealine, CLR, IBM.

В декабре 2001 года вышла следующая версия дистрибутива — ASPLinux 7.2 «Байкал». Одновременно с этим часть сотрудников офиса ASPLinux в городе Глазове была приглашена работать московском офисе ASPLinux и новообразованный московский коллектив ASPLinux уже плохо помещался в помещении на Большой Якиманке, поэтому компания переехала ближе к центру, на улицу Неглинную. По сравнению с полуподвальным помещением на Большой Якиманке это было огромным качественным сдвигом.

В апреле 2002 года впервые был выпущен сборник обновлений дистрибутива ASPLinux 7.2 на отдельном диске. Диск предназначен прежде всего для предоставления пользователям, у которых нет доступа в Интернет, или Интернет слишком дорог для обновления ASPLinux по ftp. Установка обновлений обеспечивала пользователям исправление найденных в вышедшем релизе ошибок, поддержку более широкого спектра оборудования, повышала уровень безопасности системы. Теперь компания выпускает диски с обновлениями регулярно.

При создании дистрибутива ASPLinux 7.3 «Vostok» были использованы наработки компании за срок, прошедший с момента выхода ASPLinux 7.2, среди них и open source проекты, в которых принимают участие программисты ASPLinux, и пакеты, выполненные на заказ. Например, в ASPLinux 7.3 включен пакет поддержки USB-ключа eTokenPro, разработанный компанией ASPLinux по заказу компании Aladdin. Дистрибутив «Vostok» тестировался на компьютерной технике (серверах, настольных компьютерах, ноутбуках), предоставленной компаниями IBM, Kraftway, BCC, R-Style, Formoza, Rover Computers. В этот релиз была добавлена болгарская локализация по запросу появившегося у ASPLinux партнера Cyclone Trade Company, заинтересованного в продвижении ASPLinux на болгарском рынке. В январе 2003 года Cyclone Trade Company по договору, заключенному с ASPLinux, начала продавать болгарскую версию ASPLinux 7.3, включающую руководства на болгарском языке.

В марте 2003 года вышел первый специализированный дистрибутив компании ASPLinux — ASPLinux 7.3 Server Edition, содержащий программные продукты, необходимые для организации доступа в Интернет, создания и поддержки веб-сайтов компании, построения локальной сети предприятия, рабочие станции которой могут управляться любыми операционными системами. В дистрибутив входят приложения для подсчета и контроля интернет-трафика, сбора и обработки статистики посещаемости интернет-сайтов компании и другое программное обеспечение, необходимое для решения повседневных задач системного администратора. Одной из важнейших особенностей дистрибутива является возможность централизованной настройки и администрирования программ через web-интерфейс. Несколькими месяцами позже ASPLinux 7.3 Server Edition был сертифицирован Гостехкомиссией России.

Следующий дистрибутив, ASPLinux 9, вышел 12 мая 2003 года. В него были добавлены разработанные в RedHat графические утилиты настройки принтера, сети, установки и удаления приложений и прочие полезные вещи. ASPLinux 9 же оказался первым дистрибутивом, который компания начала производить в Украине. Украинские пользователи с самого начала проявляли большой интерес к ASPLinux — как благодаря украинским корням компании, так и из-за особо жестких мер украинских правоохранительных органов по отношению к пользователям и распространителям пиратского программного обеспечения. Тем не менее, легальный ввоз коробочных версий ASPLinux в Украину сильно удорожал дистрибутив для украинских пользователей, поэтому купить его могли далеко не все желающие. Летом 2003 года наконец началась печать коробочных версий ASPLinux 9 в Украине. Донецкий офис, руководителем которого является Леонид Кантер, ранее занимавшийся только разработкой дистрибутива, теперь начал и продавать ASPLinux.

Рис. 34. ASP Linux v10

Одновременно с появлением дистрибутива ASPLinux 9 на прилавках газетных лотков появился журнал «Chip Special», полностью посвященный Linux и укомплектованной одной из предварительных версий ASPLinux 9, уместившейся на одном диске и включавшей набор основных пользовательских приложений. Это был первый в России выпуск журнала, целиком посвященный Linux и являющийся по сути небольшим руководством по Linux для начинающих. Кроме того, урезанная версия дистрибутива ASPLinux появлялась на дисках журналов «МирПК» и «PC Magazine», что позволило читателям этих журналов, не имевших дела с ОС Linux, поближе познакомиться с этой операционной системой. А летом 2003 года ASPLinux впервые попал в состав претендентов на звание «Лучший продукт года на Российском IT-рынке», проводимое журналом «МирПК» в номинации «операционные системы». Хотя победа и была присуждена Windows XP, ASPLinux оказался на втором месте, набрав больше голосов, чем в предыдущем голосовании получили все Unix-подобные операционные системы, вместе взятые.

Последним на сегодняшний день дистрибутивом от ASPLinux является дистрибутив ASPLinux v10, выпущенный в конце 2004 года. Он основан на дистрибутиве Fedora Core 3. Сочетание относительной лёгкости в настройке, наличия купонов на поддержку в поставке системы, существование обширного русскоязычного сообщества в интернете и некоторых других факторов делает ASP Linux, возможно, оптимальным для российского частного потребителя или рядового специалиста (способного настроить систему, но не предполагающего глубоко вдаваться в её разработку). Кроме того, ASP Linux предлагает специальную версию дистрибутива для серверов — ASP Linux Server II, а также оказывает ряд услуг корпоративным заказчикам.

Компания ALT Linux

Рис. 33. Логотип ALT Linux

О команде IPLabs Linux Team было подробно рассказано в одном из предыдущих разделов. Упоминалась выше и команда пользователей и разработчиков Linux, сформировавшаяся вокруг сайта linux.ru.net (LRN). В феврале 2001 года команды IPLabs Linux Team и LRN решили объединиться. Результатом объединения стала компания ALT Linux. Пресс-релизы о создании фирмы ALT Linux и о закрытии проекта IPLabs Linux Team датированы 25 марта 2001 года. ALTLinux — название фирмы, а не дистрибутива. В соответствии с уже сложившейся в сообществе открытых исходников традицией, ALT рекурсивно раскрывается как ALT Linux Team.

Я приведу ответы А.Смирнова на несколько моих вопросов относительно истории фирмы ALT Linux.

В.К. Кто были «отцами-основателями» фирмы?
А.С. Стас Иевлев, Дмитрий Левин, Алексей Новодворский, Алексей Смирнов, Антон Фарыгин

В.К. Почему решили заняться выпуском Линукс-дистрибутивов?
А.С. Собственный дистрибутив мы решили выпускать, поскольку нам стало тесно в рамках уже существующих проектов. Это было достаточно смелое решение, но без него нам было трудно реализовать свой потенциал. В результате мы создали полноценную систему распределенной разработки, организованной вокруг «Сизифа» — банка свободных программ. Сегодня это один из крупнейших в мире репозиториев свободного ПО с поддержкой целостности.

В.К. Что послужило основой для вашего первого дистрибутива?
А.С. После создания фирмы, мы работали уже на собственной пакетной базе, наработанной еще командой IPLabs Linux Team, но не решились сразу поменять и название фирмы, и название дистрибутива. Выпустили Linux Mandrake Russian Edition Spring 2001 (25 Марта 2001 г.). В нем уже все пакеты были пересобраны и поддерживались ALT Linux (эти же наработки стали основой репозитория пакетов Sisyphus). То есть Spring 2001 не был уже доработкой какой-либо версии Mandrake, хотя по договоренности с фирмой Mandrakesoft использовал имя и логотип Mandrake. Использовались также инсталлятор и программы конфигурирования от Mandrake (Drak*), которые ещё долго сохраняются в наших дистрибутивах. Переход на собственный инсталлятор и конфигуратор произойдут только с версии 3.0, выпуск которой ожидается в ближайшее время.

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

Рис. 34. Linux Mandrake RE Spring 2001

А.С. После Spring 2001 следующие наши разработки шли уже под маркой ALT Linux:
2001, июнь — ALT Linux MSI
2001, июль — ALT Linux Junior 1.0
2001, сентябрь — ALT Linux Junior 1.1
2001, сентябрь — Intel SOHO Server 2.0
2002, апрель — ALT Linux Master 2.0
2002, май — OpenOffice.ru
2002, июль — ALT Linux Junior 2.0
2002, ноябрь — Сертифицирован ЗИС «УТЕС_К»
2003, январь — ALT Linux Manli 2.0
2003, март — ALT Linux Master 2.2
2003, март — ALT Linux Junior 2.2
2004, февраль — ИВК-Кольчуга
2004, март — ALT Linux 2.3 Compact
2004, июнь — ALT Linux 2.3 Junior (для школ)
2004, август — Свободный Офис для Linux и Windows 2.0
2004, сентябрь — ALT Linux SOHO Server
2004, октябрь — ALT Linux 2.4 Master.

Кстати, на нашем сайте доступна вся история «новостей» от момента закрытия проекта IPLabs Linux Team и открытия фирмы ALT Linux. Начинать можно отсюда. У нас сохранился полный список новостей от момента создания. Внизу, под списком новостей есть еле заметные стрелочки, которые позволяют переходить на другую страницу.

В.К. Сколько человек являются штатными сотрудниками фирмы на сегодняшний день?
А.С. 35. Кстати, список проектов по разработке открытого ПО, в которых принимают участие сотрудники фирмы ALT Linux можно посмотреть здесь.

В.К. Не могли бы вы сказать, на чем фирма зарабатывает деньги — ведь на продаже дистрибутивов много не заработаешь?
А.С. Приведу структуру финансовых поступлений:
10% — продажа дистрибутивов ALT Linux
20% — OEM продажи и тендерные поставки дистрибутивов ALT Linux
20% — внедрения и техподдержка
50% — заказная разработка.

В.К. Приведите примеры крупных проектов на основе Линукс, выполненных вашей фирмой.
А.С. В качестве примера приведу «Сервер коротких сообщений» для Билайн (на основе Jabber), разработку по заказу ИВК межсетевого экрана с расширенной функциональностью «ИВК-Кольчуга», систему производственного тестирования компьютеров — «Инквизитор», разработанный по заказу фирмы «МаксСелект», специализированные версии Linux по заказу Intel, MSI, Manli. Отмечу также наши аналитические работы в рамках «Электронной России», а также для Гостехкомиссии (в качестве субподрядчика).

В.К. Если это возможно, дайте вашу оценку распространенности Линукс в России (отдельно, доля Линукс на серверах и на персональных компьютерах — десктопах).
А.С. Не готов дать адекватной оценки. Приведу только числа, которые могут кому-то помочь в подобной оценке:
— за год мы поставляем около 50 000 экземпляров ALT Linux.
— на сегодня зарегистрировано 6574 установки ALT Linux 2.4 Master.

Рис. 35. Дистрибутивы ALT Linux Master и Junior

Фирма ALT Linux Team выпускает два основных дистрибутива — универсальный ALT Linux Master и десктопный ALT Linux Junior. Универсальный Master рассчитан на пользователя, использующего Linux в своей профессиональной деятельности, не обязательно компьютерной. Junior — дистрибутив для начинающих пользователей Linux, для домашнего применения, он широко используется также в компьютерных клубах. При желании Junior может быть легко обновлен до Master или до Sisyphus при помощи apt-get.

На основе версии 2.0 дистрибутива Master фирма ALT совместно с НПФ «Промтехн» создала защищенную информационную систему «Утес-К», сертифицированную Гостехкомиссией при Президенте РФ. Она рассчитана на применение в государственных и коммерческих структурах. На основе Junior выпускаются дистрибутивы для OEM-партнеров и известных производителей оборудования. Клоны Junior, например, предустанавливаются на ноутбуки iRU, а дистрибутив Manli Edition, сделанный по заказу производителя системных плат, разошелся стотысячным тиражом по всему миру.

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

Sisyphus — это один из четырех крупнейших в мире репозиториев пакетов ПО для Linux с поддерживаемой целостностью и возможностью регулярного обновления. Все дистрибутивы ALT Linux разрабатываются на основе Sisyphus. Он отражает состояние разработок ALT Linux Team, которые полностью открыты в любой момент. Результаты работы коллектива ALT, отраженные в Sisyphus, естественно, используется разработчиками свободных программ и операционных систем со всего мира так же, как ALT использует результаты их работы. В Sisyphus ежедневно меняются десятки и сотни мегабайт ПО, появляются новые. Любой пользователь дистрибутивов от ALT, если хочет установить в свою систему самые свежие версии пакетов, может обновиться из Sisyphus при помощи утилиты apt-get. Их полная работоспособность, естественно, не гарантируется (все же Sisyphus предназначен в первую очередь для разработчиков, а не для обычных пользователей), но возникающие проблемы можно обсудить в открытом списке рассылки sisyphus@.

Компания ЛинуксЦентр

Компания ЛинуксЦентр была создана компанией Мезон.Ру 30 сентября 2000 года. В штате компании на сегодняшний день работает 15 человек, плюс примерно столько же удаленных сотрудников, которые отвечают за сборку какого-то дистрибутива, за информационное наполнение сайта и т.п.

Главная задача компании — продвижение операционной системы Linux в России. ЛинуксЦентр издает в России дистрибутивы Linux, FreeBSD, NetBSD, OpenBSD, а также соответствующее программное обеспечение, игры под Linux, атрибутику и образовательную литературу. Компания занимается дистрибуцией коробочных продуктов от компаний MandrakeSoft, Red Hat, Inc., Novell (SuSe Linux), ASPLinux, ALTLinux, Линукс ИНК, Digital Security, MOPSLinux. Кроме того, осуществляется локализация продуктов Knoppix, MandrakeMove и TheOpenCD, выпускаются доработанные версии Gentoo Linux и FreeBSD. В частности, ЛинуксЦентр принимал участие в переводе на русский язык документации по Mandrakelinux, учебных материалов по Linux от MandrakeSoft и LPI.org, в переводе на русский язык части справки по SUSE Linux.

Продукция ЛинуксЦентра продается через собственную дистрибьюторскую сеть, партнерские сети фирм 1С, «МедиаХауз», «Новый Диск», интернет-магазины Ozon.Ru и Books.Ru, и конечно, через собственный интернет-магазин. В Интернет-магазине ЛинуксЦентра можно купить коробочную версию почти любого дистрибутива Linux, различных вариантов систем BSD, соответствующее ПО, книги по программированию под Unix, администрированию этой системы и её использованию, а также атрибутику движения OpenSource. Суммарный тираж дистрибутивов, которые издает ЛинуксЦентр, превышает 100000 копий в год. Суммарный тираж продаваемых книг — около 50000 экземпляров. Ежедневно отправляется несколько сотен заказов по всей России. Регулярно проводятся распродажи устаревших версий различных систем по «копеечным» ценам.

На сайте ЛинксЦентра работает новостной канал, Библиотека ЛинуксЦентра, поддерживается уникальная Виртуальная Энциклопедия Linux и FTP-архив (ftp.linuxcenter.ru), на котором выкладываются ISO-образы дистрибутивов, разработанных командой ЛинуксЦентра.

Не нашли то, что искали? Воспользуйтесь поиском:

. Часть 1

Интерфейс к базе данных с помощью ASP

Постановка задачи

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

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

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

Что нам понадобится

Для реализации вышеизложенной задачи нам потребуется персональный компьютер с Microsoft Windows NT или Windows 2000 (можно и Workstation, и Server), установленный IIS (Internet Information Server), какой-нибудь HTML-редактор (советую использовать Macromedia Dreamweaver), Microsoft Access (версии 95, 97 или 2000) и самый обычный текстовый редактор.

Создание и подготовка базы данных

Прежде всего создадим базу данных статей, для чего:

  • запустим приложение Microsoft Access;
  • любым из известных способов создадим новую базу данных. Назовем ее «Articles»;
  • в созданной базе данных создадим таблицу с именем, например «Articles»;
  • пользуясь инструментом «Конструктор», определим поля нашей таблицы и типы принимаемых ими значений (рис. 1);
  • заполним таблицу несколькими статьями в соответствии с созданными полями (рис. 2);
  • сохраним базу данных в файле «ArticlesDB.mdb».

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

  • запустим программу-конфигуратор источников данных (Data Sources ODBC) — Start->Settings->Control Panel->Administrative Tools->Data Sources ODBC;
  • перейдем во вкладку «System DSN» и создадим новый источник данных, нажав на «Add…»;
  • в появившемся списке драйверов выберем драйвер баз данных Microsoft Access — «Microsoft Access Driver (*.mdb)» и нажмем на «Finish»;
  • в строке «Data Source Name» зададим имя нашей базы данных, например «Articles» (это то имя, по которому мы в дальнейшем будем обращаться к ней);
  • нажмем на «Select…», выберем подготовленный нами файл «ArticlesDB.mdb» и нажмем «OK».

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

Оформляем главную страницу (index.asp)

С ASP работать очень просто. Для этого надо всего лишь вставить текст скрипта ASP в пару тэгов . В остальном ASP-файл ничем не отличается от HTML-файла (за исключением, пожалуй, расширения). Комментарии в HTML, как известно, вставляются в пару тэгов , в ASP же закомментировать строку можно при помощи символа ‘ (апостроф) в ее начале.


Теперь давайте разберемся. Во-первых, как вы наверняка заметили, ASP-код легко сочетается с HTML-тэгами; в этом его достоинство. Так, к примеру, строка Response.Write Link & «
» отображает на экране браузера клиента подготовленное сервером значение переменной Link и HTML-тэг
, то есть перевод строки. Особый интерес вызывает переменная rs. Для искушенных программистов сразу скажу — это указатель. Однако в ASP с целью облегчения работы начинающих указатели маскируются. Здесь не встретишь громоздких С’шных конструкций, типа «я знаю, что ты знаешь, что я знаю», или, выражаясь программистским языком, указатель на указатель… Однако сделано это так искусно, что гибкость программирования при этом не теряется, нет лишь прямой работы с указателями, а только работа с помощью специальных функций, скрывающих от программиста рутину и защищающих указатели от некорректных действий. Таким образом, выражение rs.Fields («Article»).value означает значение поля «Article» текущего значения указателя на элемент базы данных (в нашем случае статей) и содержит текст статьи, которая соответствует текущей позиции указателя на все статьи. Переход к следующему элементу базы (смещение указателя) выполняется с помощью инструкции Rs.MoveNext. В приведенном выше примере это не делается, а попросту формируется ссылка на текст статьи в виде ее названия и отображается комментарий самой первой статьи, соответствующей результату запроса. Давайте попробуем отобразить все статьи нашей базы данных на главной странице в виде HTML. И еще, обратите особое внимание на директиву:

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

Первая строчка скрипта шаблона HTML присваивает переменной TheID значение, переданное ссылкой с использованием метода Request.QueryString. Далее открывается база данных, из которой читается статья (запись), соответствующая идентификатору, переданному из главного скрипта (index.asp).

Создаем главную страницу

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

Язык структурированных запросов — SQL

Настала пора разобраться с тем, что таится за строчками:

По сути, именно за этими двумя строчками кроется работа с нашей базой данных: первая представляет собой текстовую строку с запросом к базе данных (текстовые строки в ASP записываются в двойных кавычках); вторая — содержит директиву выполнения этого запроса с одновременным присвоением результата переменной (указателю на записи в базе данных). В рамках настоящей статьи мы не будем рассматривать SQL (Structured Query Language) во всех деталях, а остановимся лишь на тех его операторах, без понимания которых дальнейшая работа будет невозможна. Для тех, кому этого покажется недостаточным, советую посетить отобранные мною сайты с детальной документацией по SQL.

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

DELETE удаляет те ряды из «Имя Таблицы», которые удовлетворяют условию, определенному в «Определении», и возвращает число удаленных рядов. Если выполнить команду DELETE без условия WHERE, то все ряды указанной таблицы будут удалены. В этом случае DELETE возвратит 0. Ключевое слово LOW_PRIORITY откладывает выполнение операции DELETE до завершения работы чтения из таблицы других клиентов.

SELECT используется для извлечения рядов (записей) из одной или более таблиц. Выражение_Select определяет столбцы таблицы, значения которых необходимо извлечь. Все ключевые поля должны быть заданы в строгой последовательности. К примеру, выражение HAVING должно следовать за любым выражением GROUP BY и до любого выражения ORDER BY.

Выражение_Select можно заменить псевдонимом (alias) с помощью ключевого слова AS. Псевдоним используется в качестве идентификатора имени столбца и может быть использован наряду с ключевыми словами ORDER BY или HAVING.

Выражение HAVING может относиться к любому столбцу или псевдониму в Выражении_Select. Оно применяется к запросу в последнюю очередь, непосредственно перед посылкой данных клиенту. SELECT . INTO OUTFILE ‘имя_файла’ заносит отобранные записи в файл. Файл создается непосредственно на сервере и не может «уже существовать» (одна из основных причин такого механизма заключается в предотвращении случайного «затирания» различных важных файлов).

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

Первая форма — INSERT . VALUES — вставляет ряды на основании заданных значений. Вторая форма — INSERT . SELECT — вставляет ряды, выбранные из другой таблицы.

Ключевое слово LOW_PRIORITY откладывает выполнение операции до завершения работы чтения из таблицы других клиентов. Ключевое слово IGNORE в команде INSERT позволяет избегать вставки повторяющихся строк (используется в сочетании с ключевыми словами PRIMARY или UNIQUE). Для второй формы INSERT INTO . SELECT операция не может содержать выражения ORDER BY. Таблица, в которую производится добавление записей, не может присутствовать в выражении FROM части SELECT запроса потому, что запрещено производить выделение из той же самой таблицы, в которую производится вставка.

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

UPDATE обновляет поля существующей таблицы новыми значениями. Выражение SET показывает, какие поля (столбцы) должны быть изменены, и значения, которые должны быть им присвоены. Выражение WHERE, если оно есть, указывает, какие ряды должны быть обновлены. В противном случае операция применяется ко всем рядам таблицы. Ключевое слово LOW_PRIORITY откладывает выполнение операции до завершения работы чтения из таблицы других клиентов. Выражения UPDATE выполняются слева направо.

Обновляет значение поля Password в таблице WAPassword, записывая в поле, чей идентификатор ID равен 1 значение ‘passw’.

Увеличивает значение поля counter таблицы Счетчик на 1.

Удваивает поле age, а затем прибавляет 1 к его значению в таблице persondata.

Что такое Global.asa

Global.asa позволяет выполнять определенные скрипты в начале работы клиентской сессии или при инициализации IIS. Примером тому может служить простейший счетчик числа посещений сайта. Более того, допустимо использовать множественные файлы Global.asa. Однако следует помнить, что ASP-скрипт ищет самый близкий (расположенный в том же каталоге) файл Global.asa и использует именно его.

По сути, этот файл может содержать четыре скрипта: первый будет выполняться при инициализации службы IIS/PWS (Application_OnStart), второй — при остановке службы IIS/PWS (Application_OnEnd) (обычно эти первые два скрипта отрабатывают в процессе перезагрузки компьютера), и еще два скрипта выполняются дополнительно при инициализации сессии пользователя (Session_OnStart) и по ее окончании (Session_OnEnd). Данная схема очень сильно напоминает пары «конструктор-деструктор». Неспроста всякая переменная, которая должна быть использована (например, в текущей сессии), может быть инициализирована в Session_OnStart с тем, чтобы быть использованной в процессе работы сессии, она же уничтожается (обнуляется) в Session_OnEnd.

Global.asa не может содержать тэгов HTML. Недопустимо использование JavaScript. Не рекомендуется писать файл Global.asa с помощью каких-либо HTML-редакторов, для этого гораздо лучше использовать NotePad. И еще один совет: прежде чем вставлять скрипт в файл Global.asa, попробуйте его в работе в обычном ASP-файле.

Пример файла Global.asa

Добавляем новую статью (UploadForm.asp и Upload2DBS.asp)

Теперь, когда мы разобрались с SQL, можно приступать к добавлению новой статьи, причем делать мы это будем прямо с сайта, а если быть точнее — непосредственно с HTML-формы. Для этого сначала создадим файл с самой формой и определим скрипт-реакцию на подтверждение (кнопку «Publish the article!»). (Предполагается, что читатель знаком с азами построения HTML-форм, поэтому мы рассмотрим этот процесс, не вдаваясь в детали построения форм.)

Прежде всего следует уточнить задачу на этом этапе. Итак, очевидно следующее:

  • на загрузку статьи с сайта должен иметь право не каждый (следовательно, желательно предусмотреть пароль для доступа к этой функции);
  • у каждой статьи есть определенная тема (рубрика), причем она не может быть произвольной, а должна выбираться из списка;
  • список можно хранить непосредственно в HTML-файле и, каждый раз изменяя его, изменять сам файл. Это самый простой и быстрый способ;
  • однако для того, чтобы позволить динамически изменять и пополнять этот список, рекомендуется держать его в базе данных. Это позволит пользователям произвольным образом изменять его содержимое и не потребует переделки формы. Для простоты сначала рассмотрим вариант со встроенным («жестко прошитым») рубрикатором.

Как видим, передача управления осуществляется благодаря директиве ACTION=»http://localhost/Upload2DBS.asp»> в тэге формы. Тем самым указывается скрипт-ответ на реакцию пользователя после нажатия на кнопку «Publish the article!». Теперь остановимся на селекторе рубрик. Как уже отмечалось, желательно перевести его содержимое в базу данных. Для этого в нашей базе данных (файл ArticlesDB.mdb) создадим новую таблицу с именем, к примеру «Topics», в которой с помощью конструктора определим всего одно поле — «Topic» типа «текст». Далее заполним эту таблицу произвольными значениями нашего рубрикатора и отсортируем полученный список в алфавитном порядке. После чего следует заменить тэг

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

Во-первых, следует позаботиться о том, чтобы все обязательные поля (а они отмечены звездочкой) были введены. Наиболее правильным способом проверки этого является скрипт, написанный на любом языке описания скриптов (например, JavaScript), который будет проверять, введены ли значения обязательных полей. Для этого достаточно добавить в определение тэга формы параметр onsubmit=»preprocess();», где preprocess() — имя функции-скрипта, который и будет осуществлять проверку. Здесь как нельзя кстати видно преимущество языков описания сценариев (JavaScript, Jscript, VBScript) перед ASP. ASP выполняется на стороне сервера, а перегружать связь «клиент-сервер» простой проверкой типа «введены ли значения», согласитесь, неправильно. Однако специально в целях обучения мы будем делать это с помощью ASP.

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

Удаляем статью (RemoveForm.asp и Rem.asp)

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

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

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

Организуем поиск (SearchForm.asp и SearchDBS.asp)

Как известно, без поиска навигация в сколь-нибудь солидной базе данных невозможна в принципе. Попробуем организовать поиск статьи по ее реквизитам, причем постараемся организовать булев (логический) поиск, соединяя отдельные значения критериев поиска с помощью логики «И/ИЛИ».

Опять же не заостряя внимание на поисковой форме (файл SearchForm.asp), перейдем непосредственно к самому процессу поиска:

Самое интересное происходит при формировании запроса к базе из составляющих:

В зависимости от введенной пользователем комбинации исходных полей из этих компонентов формируется окончательный запрос, в частности для полей «Author» и «Title». Возможны четыре случая: оба поля пусты, пусто первое поле, пусто второе поле и оба поля не пусты. Соответствующая строка SQL-запроса в каждом из этих случаев формируется по-своему. То же самое относится к состоянию селекторов рубрик статей и порядку их сортировки. При добавлении той или иной подстроки учитывается состояние «радиокнопок» И/ИЛИ и соответствующая подстрока добавляется в SQL-запрос, предваряясь логическим элементом «and» или «or» соответственно. После того как окончательный запрос сформирован, он выполняется, а результирующая страница формируется исходя из списка статей, удовлетворяющих критериям.

Полный код приведенных в статье примеров, включая файл базы данных, находится на нашем CD-ROM.

И в заключение

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

Среди множества инструментальных средств, служащих для облегчения создания ASP-приложений, выделяются два: Easy ASP © Eric Banker, 2000 и Microsoft InterDev из комплекта Microsoft Visual Studio 6.0. Первый — очень удобное, несложное и небольшое средство для быстрого создания ASP-приложений. Второй представляет собой мощный, тяжеловесный интегрированный пакет в духе Microsoft для разработки всевозможных Web-приложений.

Временная версия EasyASP 4.0 находится на нашем CD-ROM.

Среди огромного числа сайтов мною были отобраны те, посещение которых было для меня особенно полезным и с которыми хотелось ознакомить читателей, а именно:

http://www.15seconds.com/issue/000210.htm — создание динамичных JavaScript-скриптов с помощью ASP и интерфейсов к базам данных

http://www.alphasierrapapa.com/iisdev/ — сайт, посвященный разработке серверов IIS с помощью ASP

http://www.websiteresources.com/ — огромная база исходных текстов всевозможных Web-программ

Примеры ASP-кода для профессионалов

http://www.asptoday.com/search.asp?category=ASP Tricks — масса полезных советов для начинающих программировать на ASP

http://www.oreilly.com/catalog/aspnut/ — замечательная книга популярнейшей серии «In a Nutshell» всемирно известного издательства O’REILLY «ASP in a Nutshell A Desktop Quick Reference». На сайте бесплатно размещена одна из глав книги

http://www.chilisoft.net/ — версии ASP для различных платформ можно скачать с этого сайта

http://www.willcam.com/sql/ — введение в структурированный язык запросов SQL

SQL Reference and Example Site — хорошо структурированный материал по SQL

ASP.Net. Лекция 11. Навигация по сайту (исходники)

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

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

Site Map

Структура навигации должна быть описана в карте сайта. Она находится в файле .sitemap формата XML, который можно создать в диалоге New File, выбрав пункт Site Map. Имя этого файла умолчанию — web.sitemap. Карта сайта служит источником информации для всех элементов управления группы Navigation. С ней можно работать программно с помощью класса SiteMap или через элемент управления-источник данных SiteMapDataSource.

Узлы siteMapNode могут вкладываться друг в друга, создавая иерархию. Логика вложенности узлов никак не связана с физическим расположением файлов. Каждый атрибут url в файле .sitemap должен быть уникальным.


Схема формата .sitemap

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

Редактирование карты сайта в Visual Studio 2005 облегчается с помощью технологии IntelliSense.

Атрибут title узла карты сайта создает текстовое описание страницы. Он используется как текст гиперссылки, создаваемой в TreeView или Menu. Атрибут description задает текст подсказки(Tooltip), связанной с этой гиперссылкой. Атрибут url описывает путь к странице внутри веб-сайта. При этом для страниц в корневой директории достаточно указать их название. Если страница находится в поддиректории, путь указывается с помощью прямого слеша.

Элементы управления для навигации по сайту — Treeview, Menu, SiteMenuPath.

Некоторые элементы навигации могут работать с картой напрямую, например, SiteMenuPath, но Menu и Treeview могут показывать карту сайта, только получая данные из SiteMapDataSource.

Элемент управления SiteMapPath

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

MSDN Home > ASP.NET Developer Center > Reference > Using ASP.NET Controls

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

Для того, чтобы на странице работал этот элемент, даже не нужно источника данных. Он автоматически читает карту сайта из файла Web.sitemap. Достаточно просто перетащить его на страницу. Имеются 4 свойства стиля, каждый из которых задается отдельно: для корневого элемента, для разделителя, обычного узла и текущего узла. У SiteMapPath имеется такая же возможность автоформатирования, как и у многих других элементов управления.

Свойство PathDirection позволяет изменить направление от корня к текущей странице на обратное. Например, если у вас был таким:

Главная : Игра : Таблица

,то после изменения значения PathDirection на CurrentToRoot станет таким:

Таблица : Игра : Главная

Текстовый атрибут PathSeparator задает разделитель между узлами. Например, в первом примере это » > «, который ставится по умолчанию, а во втором » : «. Пробелы здесь существенны. Похожие атрибуты был и в календаре — к примеру NextMonthText. Для того, чтобы задать изображения, в качестве разделителя, можно использовать шаблон PathSeparatorTemplate.

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

Если подержать курсор мыши над элементом, появится подсказка, текст которой берется из атрибута description соответствующего узла карты сайта. Отключить отображение подсказки можно с помощью свойства ShowToolTips=»false».

Всего имеется 4 шаблона: PathSeparatorTemplate, NodeTemplate, RootTemplate и CurrentNodeTemplate, с помощью которых можно вставлять любые элементы управления в различные части SiteMapPath. Для каждой из частей можно определить и собственный стиль.

SiteMapDataSource

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

В простейшем виде объявляется так:

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

StartFromCurrentNode =False задает возможность читать только узлы, начиная с текущей страницы.

Свойство FlatDepth задает количество уровней вложенности, которое читается из карты сайта. По умолчанию это -1, то есть читаются все доступные уровни.

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

SiteMapViewType определяет форму представления узлов. По умолчанию это Tree. Если значение равно Path, то будет читаться путь между корневым узлом и текущим, как в элементе управления SiteMapPath.

TreeView

Элемент TreeView создан специально для показа иерархической информации. Он может черпать информацию как из любого XML-файла через XmlDataSource, так и из карты сайта посредством SiteMapDataSource. Как следует из его названия, TreeView показывает данные в виде дерева, причем его узлы можно раскрывать и закрывать, выбирать отдельные «листья». При этом будут запускаться события, которые можно обработать.

TreeView состоит из узлов , которые соединены между собой отношениями «родитель-потомок». У одного родителя может быть один или несколько потомков. Узлы, у которых нет родителя, называются корневыми . Их в элементе управления может быть несколько. Узлы, у которых нет потомков, называются листьями .

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

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

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

Внешний вид линий можно отредактировать, при этом с помощью средства TreeView Line Generator будут созданы изображения для всех ее фрагментов.

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

Свойство ImageSet имеет набор предопределенных значков для разных типов узлов. Например, MSDN придаст вашему дереву сходство с TreeView на сайте msdn.com, а XPFileExplorer с программой Explorer в Windows XP.

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

Если источником данных служит XmlDataSource, то его узлы можно привязать к элементу TreeView. Создайте на странице Treeview. У него есть «умный ярлык», который позволит настроить источник данных. Настройка происходит так же, как и у элемента управления Xml.

После этого нужно настроить способы показа данных. По умолчанию он будет показывать названия узлов, а не их внутреннее содержание. В SmartTag выберите пункт Edit TreeNode Databindings. В результате в редакторе должен появиться примерно такой текст.

Значение TextField используется, если нужно показать значения атрибутов узла в исходном XML-файле, а #InnerText указывает текст между открывающими и закрывающими теками узла.

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

На странице элемент TreeView будет выглядеть так:

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

Программное управление TreeView.

У TreeView есть множество событий. Событие SelectedNodeChanged запускается, когда пользователь выбирает узел.

Можно программно раскрывать и закрывать узлы.

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

В следующем примере заполним значения элемента управления TreeView из базы данных Northwind. Родительские узлы — категории продуктов, которые заполняются данными о продуктах тогда, когда узел необходимо раскрыть.

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

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

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

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

TreeView позволяет не только показывать информацию, но ставить флажки рядом с узлами. Это полезно, если в нем содержится информация о товарах, при этом пользователь может выбрать некоторые из них. Свойство ShowCheckBoxes допускает 5 значений: None, Root, Parent, Leaf, All.

При этом рядом с узлами-листьями появляются флажки. Значение флажков можно прочитать программно.

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

Цена записана в первом дочернем поле с индексом 0. При этом обращаться свойство Text было бы неправильно, потому что там находится отформатированный текст, например «306 руб.», который нельзя преобразовать в число.

Элемент управления Menu

Выпадающее меню можно создать средствами одного только css. Это красивое решение, но требует большого объема кода. Также необходимо предусмотреть возможность просмотра разными браузерами. Большинство разработчиков создают меню с помощью JavaScript. В ASP.NET 2.0 создание выпадающего меню любого уровня вложенности требует всего 2 строчек.

Вся остальная работа достается ASP.NET. А ее много, чтобы убедиться в это, посмотрите сгенерированный код в браузере.

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

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

Задать относительный путь в проекте ASP MVC

Есть проект на ASP MVC с именем Test. В проекте есть папка App_Data в которой файл testFile.xml, к которому нужно обратиться.

пробовал и такие варианты:

Но это всё неправильно.

Господа, собственно вопрос, как правильно прописать?


/App_Data/testFile.xml»)); – Igor 30 мар ’16 в 12:37

3 ответа 3

переменная Sever может быть недоступна, лучше использовать HostingEnvironment.MapPath(_virtualPath) . Переменная Server берет метод именно отсюда.

В эту папку вы кладете закрытые данные, такие как XML-файлы или базы данных, если вы используете SQL Server Express, SQLite или другие файловые хранилища. IIS не будет обрабатывать содержимое этой папки.

Или если есть доступ к Контроллеру, то

Для преобразования виртуального пути в физический в ASP.NET — используйте Server.MapPath :

Всё ещё ищете ответ? Посмотрите другие вопросы с метками c# asp.net-mvc или задайте свой вопрос.

Похожие

Подписаться на ленту

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

дизайн сайта / логотип © 2020 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2020.11.11.35402

ArcMap

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

Путь (Path)

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

Вы можете столкнуться с двумя написаниями пути: «pathname» и «path name». Все варианты написания пути (Path, pathname и path name) являются синонимами.

Системный путь и путь каталога

ArcGIS оперирует термином «путь каталога» или «путь ArcCatalog». Путь каталога – это путь, распознаваемый только ArcGIS. Например:

относится к классу пространственных объектов powerlines в наборе объектов EastValley файловой базы геоданных Infrastructure . Этот путь не является корректным системным путем с точки зрения операционной системы, поскольку Windows не распознает наборы и классы пространственных данных, расположенные внутри файловой базы геоданных. Само собой, ArcGIS работает с путями каталога.

Рабочая область и базовое имя

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

Местоположение

Местоположение (Location) является общим термином (см., например: «Укажите местоположение ваших данных» или «Введите местоположение ваших данных»).

Прямые и обратные косые черты

В Windows обратная косая черта ( \ ) используется в качестве разделителя при указании пути. UNIX системы используют прямую косую черту ( / ). В ArcGIS не имеет значения, какая косая черта используется при указании пути. ArcGIS всегда будет правильно считывать путь, какой бы знак в нем не использовался.

Обратная косая черта при написании скрипта

Языки программирования, уходящие корнями в UNIX и язык C, такие как Python, рассматривают обратную косую черту ( \ ) в качестве управляющего символа. К примеру, \n соответствует возврату каретки. Поскольку пути могут содержать обратные косые черты, необходимо избегать их распознавания как знак перехода. Обычным делом является использование двойной обратной косой черты, например:

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

Абсолютные и относительные пути

Абсолютный, или полный путь

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

Относительный путь

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

В приведенной ниже структуре папок, предположим, что вы воспользовались Проводником Windows для перехода в папку D:\Data\Shapefiles\Soils . После перехода в данный каталог относительный путь будет использовать директорию D:\Data\Shapefiles\Soils в качестве текущей (пока вы не перейдете в новый каталог и он не станет текущей директорией). Текущую директорию иногда называют корневой папкой.

Если вы хотите перейти к папке Landuse из текущей директории ( Soils ), вам нужно ввести следующий текст в адресную строку Проводника Windows:

Проводник Windows перейдет в папку D:\Data\Shapefiles\Landuse . Другие примеры использования папки D:\Data\Shapefiles\Landuse в качестве текущей представлены ниже:

Примечание:

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

Относительный путь не может распространяться на другие диски. К примеру, если ваша текущая папка находится на диске D , вы не можете использовать относительные пути для перехода к какой-либо директории на диске E .

Абсолютные и относительные пути в ArcMap

При создании документа ArcMap (либо ArcScene, либо ArcGlobe) вы можете указать, что сохраняться будут относительные пути. Для установки этой опции выберите Файл (File) > Свойства документа карты (Map Document Properties) . Здесь вы можете указать, будете ли вы хранить абсолютные или относительные пути.

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

и данными одного из слоев являются

то в Newmap.mxd записано следующее:

Когда вы снова открываете Newmap.mxd , ArcMap преобразует сохраненные относительные пути (с обозначением с помощью точки и двух точек) обратно в абсолютные, которые отображаются как источник данных слоя. Эта конвертация всегда зависит от местоположения документа карты (текущей директории).

Преобразуются только пути, относящиеся к одному диску

Относительные пути не могут менять диски. То есть в случае, если корневой каталог находится на диске D , вы не сможете использовать относительные пути для перехода к директории на диске E . Если вы сохраняете документ карты с использованием относительных путей, преобразованы и сохранены будут только относящиеся к одному и тому же диску.

Абсолютные и относительные пути в инструментах модели

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

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

  • Данным модели
  • Растровым изображениям модели
  • Используемым в модели инструментам
  • Файлам, на которые ссылаются метаданные инструмента и справка
  • Таблицам стилей
  • Файлам слоя ( .lyr ), использующимся для условных обозначений
  • Компилированным файлам справки ( .chm )

Для сохранения относительных путей щелкните правой кнопкой мыши инструмент модели, выберите Свойства (Properties) , а затем перейдите на закладку Общие (General) . В нижней части диалогового окна включите опцию Сохранить относительные пути (Store relative path names (instead of absolute paths) , как показано ниже.

Преобразуются только пути, относящиеся к одному диску

Относительные пути не могут менять диски. То есть в случае, если корневой каталог находится на диске D , вы не сможете использовать относительные пути для перехода к директории на диске E . Если вы сохраняете вашу модель с использованием относительных путей, преобразованы и сохранены будут только пути, относящиеся к одному и тому же диску.

Абсолютные и относительные пути в инструментах-скриптах

При использовании мастера Добавить скрипт (Add Script) опция сохранения относительных путей появится на первой панели. Вы также можете установить эту опцию, щелкнув правой кнопкой мыши инструмент-скрипт, выбрав Свойства (Properties) , а затем закладку Общие (General) . В нижней части диалогового окна выберите Сохранить относительные пути (Store relative path names (instead of absolute paths) .

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

  • Скрипту
  • Наборам данных, которые используются в свойстве значения по умолчанию
  • Файлам, на которые ссылаются метаданные инструмента и справка
  • Файлам слоя ( .lyr ), используемым для свойства условных обозначений
  • Компилированным файлам справки ( .chm )
  • Таблицам стилей

Преобразуются только пути, относящиеся к одному диску

Относительные пути не могут менять диски. То есть в случае, если корневой каталог находится на диске D , вы не сможете использовать относительные пути для перехода к директории на диске E . Если вы сохраняете ваш инструмент-скрипт с использованием относительных путей, преобразованы и сохранены будут только пути, относящиеся к одному и тому же диску.

Пути в скрипте не преобразуются

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

т.к. путь ..\redlands.mdb\streets является относительным.


Какой смысл в использовании относительных путей вместо абсолютных?

Использование абсолютных путей характеризуется следующим:

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

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

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

К примеру, возьмем представленную ниже структуру папок. В этом примере D:\Tools\Toolboxes\Toolbox1 содержит инструмент-скрипт D:\Tools\Scripts\MyScript.py .

При использовании абсолютных путей в случае, если вы перемещаете набор инструментов D:\Tools\Toolboxes\Toolbox1 на другой диск, например, в E:\Final\Toolbox1 , ArcGIS найдет D:\Tools\Scripts\MyScript.py и все будет прекрасно работать. Если же вы используете относительные пути, ArcGIS не найдет скрипт и инструмент работать не будет. Диалоговое окно инструмента откроется, но после его запуска вы получите сообщение об ошибке: «Скрипт, связанный с этим инструментом, не существует». Вам необходимо открыть свойства инструмента и ввести корректный путь к скрипту.

С другой стороны, если вы работаете с относительными путями, вы можете просто скопировать папку D:\Tools в любое место на любом компьютере и все будет работать. Это не сработает при использовании абсолютных путей, поскольку другой пользователь может скопировать папку в каталог F:\NewTools и путь D:\Tools\Scripts\MyScript.py на его компьютере найден, естественно, не будет.

Заключение

  • Относительные пути не могут менять диски.
  • Абсолютные пути лучше применять, если данные не будут переноситься, как это обычно и происходит на дисках персональных компьютеров.
  • Относительные пути полезно использовать в случае, когда вы передаете документы и данные другому пользователю.
  • Относительные пути используют обозначения точки и двойной точки (. and ..). Вы можете вводить относительные пути с такими обозначениями в Проводнике Windows и командной строке Windows.
  • ArcGIS не позволяет вводить относительные пути с использованием обозначений точки и двойной точки. Чаще в документе и наборе инструментов хранятся относительные пути (после того как вы отметили опцию сохранения относительных путей).
  • Относительные пути «отсчитываются» от текущей папки, являющейся местоположением сохраненного документа или набора инструментов.

Пути UNC

UNC расшифровывается как Universal (или Uniform, или Unified) Naming Convention – Конвенция об универсальных наименованиях, и является синтаксисом для доступа к директориям и файлам в компьютерных сетях. Синтаксис показан ниже:

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

Имя компьютера отделяется с помощью двойной обратной косой черты ( \\ ).

В UNC имя компьютера также называется именем хоста.

Есть несколько правил для путей UNC:

  • Пути UNC не могут содержать меток тома (таких как D ).
  • Невозможен переход в директорию выше уровнем, чем общая директория.
  • Опция Сохранять относительные пути (Store relative path names) для документов и инструментов неприменима к путям UNC.

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

В Windows возможно открывать доступ к папкам, чтобы другие пользователи в сети могли с ними работать. В ArcCatalog или Проводнике Windows щелкните правой кнопкой мыши Общий доступ и безопасность (Sharing and Security) и следуйте дальнейшим указаниям открывающегося диалогового окна.

URL расшифровывается как Uniform Resource Locator – Универсальный локатор ресурса и уникально описывает адрес любого документа в Интернете. Компонентами URL являются:

  • Протокол, используемый для доступа к ресурсу, такой как HTTP (HyperText Transfer Protocol) или FTP (File Transfer Protocol)
  • Хост (сервер), с которым устанавливается соединение
  • Путь к файлу на хосте

Windows Internet Explorer позволяет ввести строку www.esri.com в адресной строке Internet Explorer и тип протокола будет добавлен автоматически http:// . Более правильным является явное указание протокола, например, http . Среди других протоколов назовем HTTPS (Secure Hypertext Transfer Protocol), FTP, mailto (адрес электронной почты e-mail) and news (новости Usenet) и т.д.

В ArcGIS вы можете использовать пути URL там, где это является допустимым. В общем, в пользовательском интерфейсе содержатся подсказки, где возможно или необходимо использование URL. При использовании URL в ArcGIS Explorer рекомендуется включать тип протокола как в строке ниже:

Путь к файлу подключения ArcSDE

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

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

Written on 09 Декабря 2008 . Posted in ASP.NET

ОГЛАВЛЕНИЕ

Например, такой сайт ,как Amazon.com, разделен на несколько различных секций, каждая из которых предназначена для отдельного семейства (или категории) товаров, таких как книги (Books), электронные устройства (Electronics), компьютеры (Computers), DVD, и т.д. Каждая данная секция может состоять из подразделов. Раздел «Книги» (Books) разделен на такие категории, как «Книги на CD дисках» (Books on CD), романы (Novels), исторические (History), мелодрамы (Romance), и т.д. Обычно данные логические структуры образуются согласно иерархии типов. Следующее изображение демонстрирует сокращенную версию карты сайта Amazon.com.

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

До появления ASP.NET 2.0 разработчики обычно находили свои собственные пути решения такой проблемы, как навигация по сайту. В настоящее время использование ASP.NET 2.0 позволит вам с легкостью определить структуру сайта и реализовать ее при помощи обычных элементов интерфейса навигации. В данной статье мы рассмотрим особенности навигации по сайту при помощи ASP.NET 2.0. Читайте далее, чтобы узнать больше об этом!

ASP.NET version 1.x не предоставляет никакой поддержки встроенной навигации по сайту, следовательно, многие разработчики реализовывали свои собственные идеи по поводу функциональности навигации по сайту. На этом пути им предстояло встретиться с двумя препятствиями:

  1. Решить, как организовать в карте сайта информацию о структуре сайта
  2. Реализовать элементы интерфейса навигации

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

После того как было решено, какую информацию необходимо сохранять для отражения структуры сайта, а заодно и определен способ организации данной информации (база данных, XML файл, либо что-то еще), разработчику предстояло столкнуться со вторым препятствием — как предоставить данную структуру пользователю. Обычным элементом пользовательского интерфейса навигации является элемент управления Menu, причем ASP.NET 1.x им не обладал, а это означало, что разработчики могли либо купить его, либо создать свой собственный.

В общем, реализация навигации по сайту в ASP.NET 1.x не была столь сложной задачей, но все же это было одним из препятствий на пути создания сайта. Более того, поскольку не существовало никакой встроенной поддержки интерфейса навигации, каждый разработчик создавал свое собственное решение данной проблемы, что усложняло работу новым разработчикам проекта, которым приходилось разбираться и вникать в логику интерфейса навигации.

Реализация интерфейса навигации по сайту в ASP.NET 2.0 становится легкой задачей благодаря особенностям данной технологии. ASP.NET предоставляет программную библиотеку API, которая позволяет осуществлять запросы по сайту. ASP.NET не требует определенного формата для определения карты сайта, хотя по умолчанию предполагает использование XML файла. Детали настройки карты сайта могут быть определены вручную, так как функциональность навигации в ASP.NET 2.0 использует модель провайдеров (Provider model). Модель провайдеров позволяет разработчикам настроить работу выполняемую в пределах конкретной подсистемы ASP.NET, при этом не изменяя API.

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

В дополнение к возможности указания собственной структуры, ASP.NET 2.0 предоставляет набор элементов управления, которые помогут вам с легкостью создать карту сайта в вашей ASP.NET странице:

  • SiteMapPath — предоставляет иерархическую навигацию, отображая положение пользователя относительно структуры сайта. Например, при посещении раздела «Романы» (Novels) на сайте Amazon.com будет отображено что-то типа: Home > Books > Novels.
  • TreeView — отображает структуру сайта в иерархическом дереве.
  • Menu — отображает структуру сайта при помощи меню.
    При отображении интерфейса навигации сайта элементы TreeView и Menu используют элемент управления SiteMapDataSource для того, чтобы считывать содержимое карты сайта.

На самом деле, данные элементы управления вызывают API интерфейса навигации ASP.NET 2.0. Поскольку интерфейс навигации реализован при помощи модели провайдеров, элементы управления не «обращают внимания» на внутренние детали и на то, как организована карта сайта. То есть независимо от того, используете ли вы карту сайта по умолчанию, или же создаете свою логику карты, элементы управления навигацией могут быть использованы. (Если вы хотите использовать собственную карту сайта, то вам нужно будет создать класс, который обеспечит ее соответствующими методами и свойствами для работы с картой сайта.)

Построение карты сайта

Карта сайта состоит из набора связанных между собой объектов SiteMapNode. Эти объекты формируют иерархию (как показано в начале данной статьи). Иерархия содержит одиночные корневые узлы, которые не имеют родительского узла. Каждый узел в иерархии представляет собой логический раздел веб-сайта. Каждый раздел может иметь заголовок, указатель ресурса (URL), описание и т.д., которые моделируются свойствами класса SiteMapNodes(Title, Url, Description, и т.д.).

Иерархия объектов SiteMapNodes представляется в таком виде, в котором она отображена в памяти в то время, когда она просматривается API библиотекой интерфейса навигации сайта. Тем не менее, данная карта сайта должна каким-то образом быть физически организована, например, при помощи XML файла или в таблице базы данных. По умолчанию, ASP.NET 2.0 предоставляет стандартное решение в виде реализации карты сайта при помощи XML файла. Чтобы использовать данную технику, вам необходимо в корневом каталоге вашего веб-приложения, названного Web.sitemap, создать XML файл, который будет иметь следующую структуру:

Создание файла Web.sitemap
С момента появления Visual Studio 2005 вы можете с легкостью создать данный файл карты сайта посредством выбора опции Add New Item при правом клике на сайте в проводнике Solution Explorer, выбрав затем иконку Site Map («Карта сайта»). Удостоверьтесь, что название файла осталось Web.sitemap. Созданный файл будет иметь несколько XML элементов , похожих на те, что мы рассмотрели выше.

Элементы могут обладать несколькими атрибутами. Чаще всего встречаются следующие:

  • title — определяет заголовок раздела
  • url — определяет указатель ресурса раздела (URL); не является обязательным, но если он указан, каждый указатель карты сайта должен быть уникальным
  • description — (не обязательно указывать) отображает описание раздела; используется в атрибуте alt обработанных элементов управления интерфейса навигации

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

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

Отображение карты сайта при помощи элементов управления навигации

Теперь, когда мы определили карту сайта, мы готовы к выводу данной информации при помощи страницы ASP.NET. Как говорилось выше, существует три встроенных элемента управления навигации: SiteMapPath, TreeView и Menu. Использование данных элементов не представляет большого труда — просто перетащите их на ASP.NET страницу и настройте свойства для того, чтобы настроить соответствующий сценарий диалога с пользователем.

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


  • Шапка (верхняя часть) — здесь отображается заголовок сайта («Welcome to my Website!»)
  • Левая область — здесь расположен элемент управления TreeView, который отображает все содержимое карты сайта. Это позволит пользователю быстро переместиться в определенную область сайта.
  • Основная область — главная область будет включать уникальное содержимое каждой страницы, использующей мастер-страницу. (Заметьте элемент управления ContentPlaceHolder в главной области.) В дополнение, элемент SiteMapPath также добавлен в верхнюю часть главной страницы, предоставляя иерархическую навигацию и отображая пользователям, где они находятся на сайте.

Чтобы добавить SiteMapPath на главную страницу, я просто-напросто перетаскиваю и бросаю элемент управления SiteMapPath из Toolbox на мастер-страницу. При добавлении элемента управления TreeView (либо Menu) вам необходимо сначала добавить на страницу элемент управления SiteMapDataSource; далее добавьте TreeView (либо Menu) и установите его свойство DataSourceID в значении ID элемента управления SiteMapDataSource (это может быть осуществлено посредством использования смарт-тэга TreeView). Элемент управления SiteMapDataSource осуществляет запрос по карте сайта, используя API интерфейса навигации, и предоставляет полную структуру карты сайта элементу TreeView (либо Menu).

Следующее изображение показывает веб-сайт, просмотренный в веб-браузере. Заметьте, что слева присутствует элемент управления TreeView, перечисляющий все содержимое карты сайта. Нажатие на любой узел в элементе управления TreeView переносит пользователя к соответствующему разделу. Элемент управления SiteMapPath в верхней части основной области демонстрирует пользователю его текущее положение на сайте (т.е., Home > Books > Novels).

Карта сайта

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

Программная работа с картой сайта

Карта сайта является набором взаимосвязанных узлов. Каждый узел карты сайта обычно содержит заголовок, указатель ресурса (URL) и описание. Изображение, показанное выше, является примером карты сайта, где каждый блок отражает определенный узел карты сайта. ASP.NET не требует определенного формата карты сайта, хотя, по умолчанию, предлагается использовать XML файл. (особенности использования XML файла мы исследовали в первой части.)

ASP.NET предоставляет класс, названный SiteMap , который подразумевает программный (только для чтения (read-only)) доступ к карте сайта. Данный класс характеризуется двумя элементами управления, которые мы рассмотрим в данной статье:

  • SiteMapPath — обрабатывает иерархическую навигацию, основываясь на посещенной странице и ее расположении в структуре сайта. В частности, SiteMapPath начинает обработку с узла, возвращенного свойством SiteMap.CurrentNode, и продвигается вверх по иерархии, пока не достигнет корня.
  • SiteMapDataSource — данный элемент управления создает иерархический источник данных, который отражает структуру карты сайта. Для того чтобы отобразить информацию карты сайта в других элементах управления, таких как TreeView или Menu, элементы управления не осуществляют запрос к карте сайта напрямую; вместо этого они привязаны к конкретному элементу SiteMapDataSource, который обрабатывает чтение в структуре карты сайта. (Мы детально рассмотрим элемент управления SiteMapDataSource в следующих статьях.)

Данный класс SiteMap обладает двумя родственными свойствами: RootNode и CurrentNode. Оба эти свойства возвращают экземпляры SiteMapNode. Класс SiteMapNode является узлом, определенным в карте сайта, и обладает свойствами, описывающими узел — Title, Url, Description, а также свойствами, которые позволяют программно перемещаться по иерархии — ParentNode, ChildNodes, NextSibling, PreviousSibling, и т.д..

Вы можете использовать класс SiteMap в ваших собственных страницах ASP.NET. Для примера: мы можем вывести ссылки «Следующая» (Next), «Предыдущая» (Previous) и «Вверх» (Up) на каждой странице, путем добавления трех элементов управления HyperLink на мастер-страницу сайта, наряду с небольшим куском кода, который проверяет на присутствие NextSibling, PreviousSibling или ParentNode в CurrentNode. В частности, вы добавляете следующую разметку в вашу мастер-страницу:

Обработчик события Page_Load мастер-страницы должен выглядеть так:

Это добавит три гиперссылки (Next, Up, и Previous) на каждую страницу, унаследовавшую мастер-страницу.

Отображаем иерархическую навигацию при помощи элемента управления SiteMapPath

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

  • Структурой сайта, определенной картой сайта,
  • Посещаемой страницей
  • Значением свойств элемента управления SiteMapPath

Когда посещается страница с элементом управления SiteMapPath, данный элемент пытается сопоставить страничный URL со значением указателя ресурса узла сайта, определенного в карте сайта. Если нет совпадений — элемент продвигается вверх по структуре к корню, создавая следующее: RootNode > ParentNode > . > ParentNode > CurrentNode. Здесь CurrentNode является заголовком узла карты сайта, который сравнивается с указателем ресурса (URL) запроса текущей страницы; RootNode и ParentNodes обрабатываются как гиперссылки в том случае, если узел карты сайта обладает значением URL. Элемент управления SiteMapPath на странице History раздела Books (Books/History.aspx) обрабатывается как Home > Books > History, при этом Home и Books обрабатываются как ссылки на Default.aspx и Books/Default.aspx соответственно. Посещение страницы Books/Default.aspx, SiteMapPath обрабатывает просто как Home > Books.

Результат работы SiteMapPath зависит от карты сайта и посещенной страницы. Результат работы SiteMapPath может также быть настроен при помощи свойств элемента. Существуют три стандартных форматирующих свойства — BackColor, Font, ForeColor, — а также и другие настройки SiteMapPath, такие как:

  • PathDirection — может иметь одно или два значения — RootToCurrent (по умолчанию) или CurrentToRoot. При помощи RootToCurrent иерархическая навигация на странице History раздела Books обрабатывается как Home > Books > History; при помощи CurrentToRoot результатом будет History > Books > Home.
  • PathSeparator — указывает строку, используемую для отделения каждого узла в иерархической навигации; по умолчанию >
  • RenderCurrentNodeAsLink — логическое свойство (Boolean), которое указывает на то, стоит ли обрабатывать CurrentNode как ссылку; по умолчанию — False.
  • ParentLevelsDisplayed — целочисленное значение которое может быть установлено в предел отображаемой иерархии. По умолчанию, данное свойство установлено в значение -1, тем самым означая, что не существует предела; установка значения в 1 на странице History в результате даст обработку иерархии Books > History. Home не включается, так как элемент управления SiteMapPath проходит максимум через один родительский уровень — от History к Book.
  • ShowToolTips — если узел карты сайта имеет значение описания (description), описание отображается как подсказка для каждого узла иерархии в случае, если данное свойство установлено в True (по умолчанию).

Также существуют свойства стиля для настройки BackColor, Font, ForeColor и т.д., для различных частей элемента SiteMapPath. Свойство NodeStyle может быть использовано для настройки внешнего вида узлов и иерархической навигации; RootNodeStyle и CurrentNodeStyle могут быть использованы для последующей настройки первого и последнего узлов в иерархии. Часто простейшим и наиболее практичным методом форматировать элемент управления SiteMapPath может быть использование его мастера Auto Format, который можно применить, используя смарт-тэг элемента управления.

Настраиваем обработанный результат при помощи шаблонов

Элемент SiteMapPath содержит четыре шаблона, которые позволяют последующую настройку результата обработки. Шаблоны позволяют смешивать HTML разметку , веб-элементы управления и синтаксис привязки данных (DataBinding); если вы раньше использовали элементы управления DataList или Repeater, то вы уже должны быть знакомы с шаблонами. Шаблоны в ASP.NET 2.0 по существу являются такими же, как и шаблоны в ASP.NET 1.x, за исключением того, что ASP.NET 2.0 использует более новый и насыщенный синтаксис выражений привязки данных. Например, в ASP.NET 1.x вам нужно было использовать синтаксис для того, чтобы получить значение из колонки. В ASP.NET 2.0 данный старый синтаксис работает, но вы также можете использовать и более короткий вариант, .

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

Например, если вы хотели обработать всего лишь корневой узел, принадлежащий SiteMapPath, как LinkButton, вы можете добавить к элементу SiteMapPath вместе со следующей разметкой:

Данная разметка добавит элемент LinkButton к SiteMapPath, чье свойство Text назначено соответствующему свойству Title в SiteMapNode. При нажатии на LinkButton вызывается постбэк и событие Command элемента, тем самым вызывая обработчик события LinkButton1_Command. Свойство Url в SiteMapNode передается данному обработчику события при помощи свойства CommandArgument. В обработчике события вы можете выполнить все то, что было необходимо сделать при обработке на сервере и затем, после этого, перенести пользователя на страницу, запрашиваемую путем Response.Redirect(e.CommandArgument).

Ограничение доступа к пунктам карты сайта

Поскольку определенные области сайта могут быть доступны только авторизированным пользователям, то у нас появляется дилемма, связанная с навигацией по сайту. Включать ли страницы, которые доступны только авторизированным пользователям, в карту сайта? Если мы сделаем это, то всем пользователям будут видны страницы, имеющие ограничение по доступу в элементах Menu либо TreeView. Почему стоит отображать ссылки на страницы для пользователей, которые не имеют к ним доступа? Если мы исключим данные страницы из карты сайта, то те пользователи, которым разрешен просмотр данных страниц, не смогут с легкостью перейти на них, поскольку данные страницы не будут являться частью карты сайта и тем самым они не будут отображены в элементах TreeView или Menu сайта!

К счастью, навигация в ASP.NET 2.0 предоставляет такую услугу, как ограничение прав (security trimming). При получении информации о карте сайта при настроеном ограничении в правах (security trimming) пользователю доступны только те узлы карты сайта, которые ему разрешено посещать. Это означает, что элементы TreeView либо Menu на сайте будут содержать только те, которые доступны данному пользователю. Читайте далее, чтобы узнать больше об этом!

Начнем с настройки Membership и ролей (опционально) в ASP.NET 2.0

Поскольку ограничение прав в навигации сайта лежит в основе построения карты сайта на пользователе, который посещает страницу, а также на настройках авторизации, указанных в карте сайта для страниц, то перед тем как исследовать функцию ограничения прав (security trimming), вам нужно будет настроить сайт на использование такой службы в ASP.NET 2.0, как Membership. (Вы также можете использовать роли в вашем сайте и создать систему авторизации, основанную на ролях, но это не является обязательным при изучении принципа ограничения прав (security trimming)). Тема настройки сайта на использование Membership и ролей (Roles) выходит за рамки данной статьи.

Приложение в конце данной статьи включает в себя пример ограничения прав (security trimming) по карте для сайта, который реализует службу Membership и ролей (Roles), и который вы можете использовать в том случае, если не хотите вручную настраивать свойства Membership и ролей на свежем веб-сайте. В частности, веб-сайт, приложенный к данной статье, содержит две роли, администратор (Administrator) и тестер (Tester), с четырьмя пользователями:

  • Superman — в качестве администратора и тестера
  • Admin — в качестве администратора
  • Mr. Tester — в качестве тестера
  • Average User — не обладающий ни одной ролью

Более того, в проекте присутствуют три папки — Admin, Tester и AuthUsersOnly. Первые два каталога были настроены таким образом, что к ним доступ имели только пользователи, обладающие ролями администратора (Administrator) и тестера (Tester), соответственно. Только пользователи с определенными правами имеют доступ к каталогу AuthUsersOnly.

Настройка навигации по сайту, используя ограничения прав (security trimming)

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

Настройки навигации могут быть установлены при помощи файла Web.config, используя следующий шаблон:

Модель провайдеров (provider model) предоставляет разработчикам определенный публичный (public) интерфейс прикладных программ (API), но позволяет настроить внутреннюю обработку при необходимости. По умолчанию навигация по сайту использует XmlSiteMapProvider, которая содержит информацию о карте сайта из XML-файла Web.sitemap. Вы можете изменить используемый провайдер, либо изменить настройки провайдера, установленного по умолчанию, при помощи файла through the Web.config.

Чтобы изменить настройки провайдера, установленного по умолчанию, просто добавьте нового провайдера, который будет использовать тот же тип, как и стандартный провайдер (System.Web.XmlSiteMapProvider), устанавливая настройки по необходимости. Блок кода, показанный выше, демонстрирует способ настройки двух параметров XmlSiteMapProvider:

  • Параметр siteMapFile содержит название файла карты сайта, используемое провайдером; по умолчанию данное значение равно Web.sitemap. При желании вы можете настроить название файла. Я советую вам проверять файл, чтобы быть уверенным, что название файла оканчивается расширением .sitemap, поскольку данное расширение защищено движком ASP.NET, тем самым защищая файл от просмотра пользователями.
  • Параметр securityTrimmingEnabledуказывает на то, использовано ли ограничение прав (security trimming) или нет. Установите данный параметр в значении «Истина» (True), если требуется использование ограничений прав.

И это все! Применив одну настройку, система навигации по сайту станет настолько смышленой, что будет отображать разделы соответственно настройкам авторизации, указанным для ссылок на ресурсы (URL) в элементах , а также от авторизированного пользователя. Следующее изображение показывает элемент TreeView, отображенный при посещении анонимного пользователя (тот, кто еще не авторизовался), а также при посещении обычного пользователя (Average User) и администратора (Admin user). Анонимный пользователь увидит (все) две ссылки — Home и My Blog. Обычный пользователь (Average User) увидит дополнительную ссылку — Auth Users, которая не была отображена анонимному пользователю, поскольку данная ссылка на ресурс (

/AuthUsers/Default.aspx) настроена таким образом, что только авторизированные пользователи имеют к ней доступ. Администратору (Admin user) доступна еще одна дополнительная ссылка, поскольку он обладает ролью администратора (Administrator role) и ссылка на ресурс, указанная в узле Admin карты сайта (

/Admin/Default.aspx), настроена таким образом, что только администраторы имеют к ней доступ.

The TreeView When Visited by an Anonymous Visitor
The TreeView When Visited by Average User The TreeView When Visited by Admin

Избегаем ограничения прав (Security Trimmings) при помощи атрибута roles

Бывают случаи, когда вам нужно будет явно указать в ограничениях прав то, что не стоит ограничивать доступ к карте сайта для конкретной роли или группы ролей. Например, если ваша карта сайта содержит ссылку на внешний ресурс, система навигации сайта не сможет определить правила авторизации для внешнего ресурса. Тем самым она ставит ограничения на все узлы для всех пользователей. То есть, если вы используете ограничения прав (security trimming) и используете карту сайта с ссылкой на внешний ресурс (например ), то ни один из пользователей не увидит этого в элементах TreeView либо Menu. Более того, вам наверняка понадобится настроить систему навигации таким образом, чтобы она отображала данный узел для пользователей, обладающих ролями администратора и тестера (либо для всех пользователей, независимо от их роли.)

Аналогично вам может понадобиться отобразить пользователям узлы локальной карты сайта, даже если у них нет доступа к данным ресурсам. Например, пользователь, который посещает карту сайта и ему еще необходимо авторизоваться, скорее всего, не увидит Admin link в TreeView. Тем не менее мы все же хотим отобразить ее. Нажатие на ссылку вызовет перенос пользователя на страницу

/Admin/Default.aspx, где система различит авторизированных пользователей от неавторизированных. То есть они будут перенесены на страницу авторизации. После авторизации они будут автоматически перенесены обратно на страницу администрирования (Admin). Если же они обладают ролью администратора (Administrator role), то им будет разрешен доступ к разделу администратора (Admin), в противном случае они будут перенесены обратно на страницу авторизации.

Чтобы устанавливать ограничение по правам на определенные узлы сайта , используйте атрибут roles в соответствующем элементе . (Заметьте: данная настройка не будет действовать на потомков элемента ; то есть вам необходимо напрямую настроить данный атрибут в элементах , в которых вы хотели бы явно указать дополнительные роли, которым необходимо видеть данный узел.) Атрибут roles может содержать одно название роли, список имен, отделенных запятой, либо звезду (*) для выбора всех пользователей. Следующий файл карты сайта, включенный в приложение, доступное в конце данной статьи, демонстрирует, как использовать атрибут roles для отображения всем пользователям узла карты сайта с ссылкой на внешний ресурс. (Следует помнить, что результатом опущения атрибута roles в приведенном случае будет то, что данный узел карты сайта не будет отображен никому из пользователей, если установлены ограничения по правам.)

Атрибут roles также может быть использован для добавления некоторого улучшения функциональности характеристик ограничений по правам (security trimming). При использовании данных ограничений провайдер навигации по сайту автоматически проверяет правила авторизации для всех узлов, указанных в карте сайта. Вы можете обойти данную проверку для тех узлов, которые вы хотите отображать всем пользователям (например, Home и About в указанном выше примере), путем добавления roles=»*». Добавляя данный атрибут, вы сократите стандартную проверку авторизации, тем самым улучшая функциональность ограничений по правам.

Модель провайдеров

Возможности навигации по сайту реализованы при помощи модели провайдеров (provider model), которая предоставляет стандартный интерфейс программ (API — класс SiteMap), но позволяет разработчикам добавить свою реализацию интерфейса во время выполнения. ASP.NET 2.0 предоставляется с единственной реализацией — XmlSiteMapProvider, с помощью которой разработчик может создать карту сайта используя XML-файл (Web.sitemap). Тем не менее, структура нашего сайта может быть сформирована информацией о существующей базе данных, либо каталогами и файлами, из которых составлен наш веб-сайт. Вместо того чтобы дублировать базу данных либо файловую систему в файле Web.sitemap, мы можем создать специализированный провайдер (custom provider), который использует базу данных или информацию о файловой системе в качестве карты сайта.

Благодаря провайдеру мы можем предоставить собственную реализацию под-системы навигации сайта, но при этом доступ к ней может быть осуществлен посредством класса SiteMap. В сущности, имея в наличии специализированный провайдер (custom provider), класс SiteMap и элементы управления навигацией будут работать точно также, как и в случае с XmlSiteMapProvider. Единственным отличием будет только то, что информация карты сайта будет заимствована от нашей созданной логической структуры, будь это база данных, веб-сервис, файловая система либо какой-нибудь другой источник данных, который требуется нашему приложению. В данной статье мы рассмотрим способ создания специализированной модели навигации по сайту и построим с нуля файловый провайдер карты сайта (File System-Based Site Map Provider). Читайте далее, чтобы узнать больше об этом!

Назначение файлового провайдера карты сайта (File System-Based Site Map Provider)

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

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

В дополнение вам, скорее всего, придется написать некоторый код инициализации для специализированной модели карты сайта. При первом посещении карты сайта, после того как специализированный провайдер был зарегистрирован (custom provider) в файле Web.config, вызывается метод Initialize() данной модели и при этом также передаются названия атрибутов и их значения, указанные в файле Web.config провайдера. Метод Initialize() может считать данные названия и значения атрибутов и сохранять их там, где необходимо. Например, провайдеру карты сайта, который обратился к информации о структуре из базы данных, понадобится наличие строки соединения в разметке провайдера в файле Web.config. В методе Initialize() значение данной строки соединения может быть сохранено в поле (member variable ) класса. Впоследствии оно может быть использовано для произведения присоединения к базе данных при построении карты сайта.

Расширяем класс StaticSiteMapProvider

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

  • GetRootNodeCore() — возвращает корневой узел карты сайта.
  • BuildSiteMap() — формирует карту сайта и возвращает корневой узел.


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

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

Структура каталогов и файлов веб-сайта отражает его логическую структуру. Каталог Books содержал страницы, названные Novels.aspx, Romance.aspx, History.aspx и т.д. Аналогично были структурированы файлы в каталогах, названных Electronics, DVDs и Computers. Вместо того чтобы дублировать информацию о системе файлов в файле Web.sitemap (и помнить о том, что необходимо обновлять ее при добавлении новых страниц, переименовывать каталоги и файлы, либо удалять все страницы разом), мы можем создать специализированный провайдер карты сайта, который будет основываться на структуре файловой системы.

Я создал такой специализированный провайдер карты сайта и назвал его FileSystemSiteMapProvider. Данный класс, вместе с веб-сайтом, использующим данный провайдер, доступен в конце статьи.

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

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

Свойства провайдера FileSystemSiteMapProvider

По умолчанию, провайдер FileSystemSiteMapProvider подсчитывает все ASP.NET-страницы и каталоги веб-приложений, за исключением папки Bin и папок, начинающихся с префикса App_. Тем не менее могут существовать такие страницы или каталоги, которые вы не хотите отображать в карте сайта. Провайдер FileSystemSiteMapProvider предлагает два опциональных свойства, которые могут быть указаны для достижения данной цели:

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

/Books/Novels.aspx to ExcludeFileList.
ExcludeFoldeerList — список каталогов, которые мы также не хотим включать в карту сайта. Если папка исключена, все файлы и подкаталоги также исключаются. В то же время путь к каталогу также должен быть указан, например

Оба свойства ExcludeFileList и ExcludeFoldeerList являются объектами StringDictionary; более того, оба являются Protected, тем самым означая, что вы можете с ними работать напрямую с вашей ASP.NET-страницы. Вместо этого вам придется использовать подходящие вспомогательные методы для добавления, удаления и пересчета данных свойств. (В качестве более подробного примера использования вспомогательных методов рассмотрите страницу SiteMap_Info.aspx в приложении к данной статье.) Тем не менее вы можете настроить данные свойства в их исходные значения при помощи файла Web.config, и мы это вскоре рассмотрим.

В дополнение к данным исключающим свойствам FileSystemSiteMapProvider содержит еще четыре других свойства:

    RootUrl — полностью проверенный путь к странице, которая служит корневым узлом в карте сайта. Если данное значение не указано — значение по умолчанию равно

/Default.aspx.

  • RootTitle — заголовок, который отобразится для корневого SiteMapNode. По умолчанию «Home».
  • UseDefaultPageAsFolderUrl — логическое свойство, значение которого указывает на то, необходимо ли использовать DefaultPage в качестве ссылки на папку или нет. Если данное свойство установлено в значении True (стандартное значение), то каждый созданный в карте SiteMapNode для каталога будет иметь свое собственное свойство Url установленное в

    /FOLDER/DefaultPage.aspx (если файл существует). Более того, файл

    /FOLDER/DefaultPage.aspx (если он существует) не добавляется как потомок каталога.

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

    /Books/Default.aspx. Если вы хотите, чтобы узел Books в карте сайта мог быть нажат и при этом мог переносить пользователя на

    /Books/Default.aspx, то оставьте данное свойство, равное True. Если же вы хотите, чтобы пользователь не мог нажать на узел Books, и вместо этого хотите добавить четвертого наследника узла Books, который посылает пользователя на

    /Books/Default.aspx, то установите данное свойство в False.

  • DefaultPageName — название файла для страницы, которая является документом по умолчанию. По умолчанию равно Default.aspx.
  • Создаем карту сайта

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

    Вы также можете довольно легко сохранить дерево — просто создайте переменную _root SiteMapNode на уровне класса и назначьте данную переменную корню SiteMap. Такой подход позволяет построить карту сайта единожды, и затем сохраняет ее до того, как веб-приложение будет перезагружено либо будет отредактирован класс FileSystemSiteMapProvider. Данное сохранение может показаться слишком «агрессивным», но, тем не менее, в случае если новые ASP.NET-страницы добавлены в файловую систему либо удаляются существующие, карта сайта не отобразит данные изменения.

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

    /), и когда вызывается BuildSiteMap(), я проверяю файловую систему на какие-либо изменения, произошедшие с момента последнего вызова BuildSiteMap(). Если ничего не произошло — я просто возвращаю ссылку _root, так как нет никакой необходимости в перестройке карты сайта. Если же были произведены какие-либо изменения, то я заново собираю карту.

    Метод BuildSiteMap() и рекурсивная BuildSiteMapFromFileSystem(), приведенные ниже, являются двигателями создания карты сайта. Я оставил парочку вспомогательных методов (к примеру, CreateFileNode() и CreateFolderNode()). Данные методы вы можете исследовать, скачав полный код в конце данной статьи.

    Расширяем возможности провайдера FileSystemSiteMapProvider

    Реализация FileSystemSiteMapProvider, продемонстрированная тут, использует очень простой алгоритм определения заголовка для SiteMapNodes файлов и папок — она просто использует название файла или папки, заменяя underscores (_) пробелами. Тем не менее, вы наверняка захотите установить в качестве основы названия файла значение элемента (если таковое существует), или основываться на каком-то критерии либо тэге . Вы с легкостью можете добавить данную функциональность путем расширения класса FileSystemSiteMapProvider и перегрузки методов GetFileTitle() и GetFolderTitle(). Данные два метода возвращают заголовок, используемый SiteMapNode для указанного пути к файлу либо каталогу.

    Внедрение провайдера FileSystemSiteMapProvider в веб-сайт

    Последним шагом будет внедрение провайдера в ваш веб-сайт и использование его вместо стандартного XmlSiteMapProvider. Для этого добавьте следующую разметку в файл Web.config вашего приложения:

    Ограничения прав доступа к узлам карты сайта (security trimming)

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

    Модель провайдера карты сайта и ограничение прав (security trimming) применяются для настройки узлов карты сайта, используемых элементами управления навигации. Тем не менее, нам может понадобиться настроить обработанный результат элемента навигации, основываясь на информации карты сайта. Допустим, в нашем элементе управления Menu мы хотим отображать иконку, расположенную рядом с каждым пунктом меню, в зависимости от классификации, указанной для узла карты соответствующего пункта меню. В качестве альтернативы разметка, обработанная встроенными элементами управления ASP.NET, может оказаться непригодной. Вместо того, чтобы отображать TreeView либо Menu, нам наверняка захочется отобразить информацию навигации сайта в виде списка с маркерами. Данную функциональность можно получить при помощи класса SiteMap.

    Добавление специализированных атрибутов к узлам карты сайта

    В предыдущих главах данной серии статей мы обсуждали способ формирования логической навигационной структуры сайта в качестве карты сайта, которая является иерархическим набором узлов. Каждый узел карты сайта представлен в коде как экземпляр класса SiteMapNode, который обладает такими свойствами, как ChildNodes, ParentNode, Title, Url, и др. Следующая диаграмма отражает карту сайта; каждый блок в диаграмме является узлом карты.

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

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

    Конечно, до того как мы начнем работу с данными значениями, нам нужно назначить их экземплярам SiteMapNode, из которых составлена карта сайта. Как вы с этим будете справляться — зависит от того, какой провайдер карты сайта вы используете. Если вы используете стандартный провайдер карты сайта (XmlSiteMapProvider — тот, который хранит карту сайта в файле с XML-кодом), специализированные значения могут быть добавлены как дополнительные атрибуты к элементам . К примеру, представьте, что вам нужно добавить изображение в каждый узел элемента TreeView и каждое изображение определить в карте сайта. Мы можем добавить атрибут imageUrl в различные элементы следующим образом:

    Указав свойства imageUrl нам теперь нужно настроить элемент навигации, используемый для отображения информации, таким образом, чтобы он отображал указатель изображения (URL). Давайте рассмотрим пример использования элемента TreeView. Начнем с добавления SiteMapDataSource на страницу, затем добавим TreeView, свяжем TreeView с SiteMapDataSource. Далее, создадим обработчик для события TreeView TreeNodeDataBound. Данное событие запускается по разу для каждого узла TreeView после того, как пункт будет привязан к узлу TreeView.

    Обработчик события передает экземпляр TreeNodeEventArgs в своем втором параметре, который обладает свойством Node, а тот в свою очередь возвращает привязанный узел TreeView. Узел TreeView обладает свойством DataItem, которое возвращает тот объект, который был привязан к TreeView. Во время использования TreeView для отображения информации карты сайта DataItem является конкретным экземпляром SiteMapNode на сайте и привязан к определенному узлу TreeView.

    Следующий код проверяет, обладает ли текущий экземпляр SiteMapNode установленным специализированным значением imageUrl. Если это так, то оно устанавливает свойства узлов TreeView ImageUrl в

    /Images/value, где value является значением атрибута SiteMapNodeimageUrl.

    Создаем специализированный пользовательский интерфейс навигации

    ASP.NET 2.0 имеет в наличии три элемента управления которые обычно используются для отображения информации из карты сайта:

    • SiteMapPath — отображает пользователю его положение в иерархии карты сайта (Этот элемент управления обсуждался в второй части данной сериии статей.)
    • TreeView — отображает все узлы карты сайта в свертывающимся дереве (treeview)
    • Menu — отображает все узлы в карте сайта, в меню выровненном по горизонтали либо вертикали

    Чтобы отобразить информацию карты сайта, оба элемента TreeView и Menu должны быть привязаны к SiteMapDataSource. SiteMapDataSource является элементом управления, возвращающим информацию о карте сайта в TreeView либо Menu в качестве объекта SiteMapNodeCollection, который содержит иерархию узлов. Элементы управления TreeView и Menu рекурсивно проходят по данному набору и выстраивают свои собственные пункты меню и узлы дерева соответственно.

    Мы можем работать с SiteMapNodeCollection, возвращенным SiteMapDataSource, либо декларативно, либо программным путем:

    Здесь мы связали Repeater siteMapAsBulletedList с SiteMapDataSource1 элемента управления SiteMapDataSource. Учтите, что SiteMapDataSource возвращает иерархический объект SiteMapNodeCollection. Repeater, не будучи иерархическим элементом управления информацией, всего лишь перечисляет первый уровень результатов узлов карты сайта. То есть он не углубляется в дочерние узлы каждого SiteMapNode. В данном примере ShowStartingNode установлен в значение False, что заставляет SiteMapNodeCollection начать обработку со второго уровня (Books, DVD, Electroincs, и Computers). То есть для каждого SiteMapNode второго уровня инициируется ItemTemplate. (Корневой узел карты сайта (Home) отображается с небольшой разметкой в HeaderTemplate.)

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

    Это полезно использовать для отображения корневого узла карты сайта, а также первый уровень. Но что если мы хотим отобразить дополнительные уровни? Мы можем просто добавить другой Repeater в ItemTemplate, тем самым устанавливая DataSource того второго Repeater в свойство ChildNodes текущего используемого узла, примерно так:

    Для C#, свойство DataSource будет установлено как DataSource=’ ‘

    Декларативный подход ограничен только отображением тех уровней карты, которые внедрены во множество Repeater. То есть, если узел Romance имел дополнительные подузлы, вышеупомянутая декларативная разметка не включала бы их в себя. Для того чтобы отобразить их, используя декларативную разметку, нам нужно добавить третий Repeater к ItemTemplate второго Repeater. Тем не менее, это не будет отображать все узлы сайта вплоть до 4 уровня.

    Чтобы отобразить узлы любой «глубины» в списке нам необходимо программно задействовать SiteMapDataSource и рекурсивно пройтись по возвращенным объектом SiteMapNodeCollection. Следующий код (только в VB) демонстрирует способ реализации данной идеи. На странице присутствует элемент Label с ID bulletedList, и SiteMapDataSource с IDsiteMapData и его свойство ShowStartingNode установлено в значение False. (Данный код, а также все предыдущие примеры, доступны в конце данной статьи. )

    Asp.Net Mvc программно определяет название раздела на странице контента

    Я не говорю о RenderSection, и мой вопрос напрямую не связан с макетом.

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

    таблица с именем Module. Модули похожи на Widgets. Обратите внимание на поля Position и ModulePath.

    Позиции похожи на ContentPlaceHolder, определенные на странице «Макет». В Mvc определите положение, как показано ниже.

    Поле ModulePath содержит расположение PartialView. Они будут отображаться в макете.

    Проблема начинается здесь. Как это сделать программно.

    Обычно мы используем;

    для определения раздела на странице содержимого.

    В Asp.net WebForms это очень легко сделать.

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

    На самом деле мне нужно что-то вроде этого;

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

    Илон Маск рекомендует:  Dos fn 06h консольный ввод вывод
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL
    Целесообразность использования файлового провайдера карты сайта (File System-Based Site Map Provider)