Здравствуйте, _SZ_, Вы писали:
_SZ>Но директория и страница были добавлены через SharePoint Designer и SharePoint вэб интерфейс и лежат в базе.
_SZ>Есть идеи, как можно обойти это препятствие?
Есть идея почитать вокруг virtual path provider. С ним, возможно, свой хэндлер и не понадобится.... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, _SZ_, Вы писали:

_SZ>Метод GetCompiledPageInstance нужен для создания инстанса страницы, которая выполнит потом ProcessRequest.
Вот с этого места непонятно. GetCompiledPageInstance делается для a2.aspx? Почему тогда его нет, ты же говоришь что есть такая страница?

_SZ>Неспрашивайте, зачем эта вся беда вообще стала нужна — так захотел заказчик...

_SZ>Как я описывал выше — методом GetCompiledPageInstance у меня не получается создать инстанс страницы.

_SZ>virtual path provider возможно в этом поможет, а возможно и нет — не проверял — так как если он вытянет объект типа SPFile, я понятия не имею, как потом сделать ProcessRequest.
Virtual Path Provider поможет GetCompiledPageInstance найти страничку, которой нет в файловой системе. Его надо не использовать, а реализовывать.
_SZ>В любом случае провайдер довольнообъёмная штука для такой задачи.
Да ну. Не шибко-то он объемный.
_SZ>Появилась мысль использовать HttpModule c Responce.Redirect на BeginRequest... пока думаю...
Внятно опиши задачу. Скорее всего, для нее заранее предусмотрен человеческий метод.... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, _SZ_, Вы писали:

_SZ>При клике по этим ссылкам должна открываться страничка а2.aspx с необходимым ключом, например — а2.aspx?id=b1, страничка а2.aspx знает, как ей обрабатывать полученный ключ.
Это всё понятно. Стандартный Url Rewrite.
_SZ>Однако в строке ввода URL адреса браузера должнен будет отобразиться адрес странички b1.aspx.
А какой именно адрес у странички b1.aspx?
_SZ>Был уже готов HttpHandler, который работал, но не был расчитан на виртуальную файловую систему — не мог сработать GetCompiledPageInstance для a2.aspx.
А для какой странички GetCompiledPageInstance срабатывал?
_SZ>HttpModule c Server.Transfer на BeginRequest тоже работает так, как надо...
А куда делается Server.Transfer? Есть подозрение, что он просто пользуется VirtualPathProvider, который уже и так реализован шарепоинтом. Каким-то способом ведь виртуальные странички работают, так? Я просто с шарепоинтом никогда не работал.
_SZ>Если есть идеи более человеческого метода — всегда рад учиться :)
Ну, скорее всего человеческий метод именно в Server.Transfer. Хотя его, наверное, можно было сделать и в хэндлере.... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, _SZ_, Вы писали:

_SZ>Он срабатывал для a2.aspx, но страничка реально существовала по пути, типа — c:\inetpub\wwwroot\VirtualFolder\folder\a2.aspx.
А теперь странички там нет. Но обращение к http://server/folder/ а2.aspx по-прежнему работает?... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, _SZ_, Вы писали:
_SZ>Да. Шарпоинт возвращает контент страницы.
что значит контент? Исходник что ли?... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, _SZ_, Вы писали:

_SZ>Нет. Шарпоинт вернёт из базы объект типа SPFile (в объектной модели шарпоинта).
Интернет експлорер ничего не знает про SPFile. Он умеет делать HTTP запросы и отображать некоторые типы файлов. Что ты увидишь, если в браузере наберешь " http://server/folder/ а2.aspx"?
_SZ> По сути он и есть aspx файл.
aspx как файл весьма существенно отличается от результата его работы.... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, _SZ_, Вы писали:

_SZ>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, _SZ_, Вы писали:

_SZ>>>Нет. Шарпоинт вернёт из базы объект типа SPFile (в объектной модели шарпоинта).
S>>Интернет експлорер ничего не знает про SPFile. Он умеет делать HTTP запросы и отображать некоторые типы файлов. Что ты увидишь, если в браузере наберешь " http://server/folder/ а2.aspx"?

_SZ>В общем случае, то же самое, если бы это была невиртуальная страница и я бы набрал в браузере этот же адрес.
_SZ>Думаю шарпоинт даёт иису aspx файл, а тот уже знает, как с ним работать.
Гм. Твои представления о механизме работы ASP.NET не вполне полны:
1. IIS представления не имеет о том, как работать с нестатическими файлами
2. Всё, что у него есть — это карта ISAPI Extensions, которая объясняет, как обрабатывать определенные расширения в URL . Не указанные в карте расширения проверяются по карте MIME типов и в случае удачи обрабатываются внутри самого IIS.
3. Обычыно ASP.NET регистрируется в IIS для обработки запросов с .aspx, .ashx, .ascx и еще парой десятков расширений.
4. По умолчанию, запросы .aspx обрабатываются так:
-- делается попытка загрузить файл с указанным именем, он компилируется в соответствии с настройками приложения и исполняется. Эта фаза может быть сокращена в случае, если в кэше есть уже скомпилированный экземпляр обработчика. Всё это собственно и делается методом GetCompiledPageInstance().
-- надо отметить, что за загрузку файла отвечает VirtualPathProvider. По умолчанию, мспользуется примитивная реализация MapPathBasedVirtualPathProvider, которая просто отображает виртуальные пути в физические через стандартное HostingEnvironment.MapPath.
-- кроме того, стоит отметить, что за компиляцию найденного файла отвечает BuildProvider.
5. Поскольку для шарепоинта стандартный способ не может подходить, я полагаю, что шарепоинт регистрирует для соответствующего веб приложения virtualPathProvider, умеюший поднимать исходники .aspx из базы шарепоинта. Что должно быть отражено в соответствующем web.config (доступ к .config виртуализировать таким способом невозможно)
6. Альтернативой является регистрация шарепоинтом своего ISAPI Extension на все расширения для его фолдеров. В таком случае магия может быть и другой, т.к. ASP.NET runtime будет хоститься внутри нестандартного ISAPI, и у него могут быть другие пути получения compiledpageinstance.

_SZ>Структура файла точно такая же, как у обычной aspx странички.
:)... << RSDN@Home 1.2.0 alpha rev. 677>>