#c# #dotnetnuke #friendly-url #dotnetnuke-module
#c# #dotnetnuke #дружественный URL #dotnetnuke-модуль
Вопрос:
Предыстория
DotNetNuke поддерживает возможность присвоения URL-адресу пользовательского имени страницы, чтобы сделать URL-адрес более удобным для пользователя, например, вместо /Page/itemId/14/Default.aspx вы можете иметь /Page/itemId/14/My-Article.aspx . API для достижения этого — via DotNetNuke.Common.Globals.FriendlyUrl (который просто вызывает DotNetNuke.Services.Url.FriendlyUrl.FriendlyUrlProvider.FriendlyUrl ).
Этот FriendlyUrl метод имеет некоторые перегрузки, которые принимают параметр path и pageName , где вы можете указать значимые параметры строки запроса через path и удобное название страницы через pageName . Следуя примеру Брюса Чепмена, это может выглядеть примерно так:
FriendlyUrlProvider.Instance().FriendlyUrl(tab, "~/Default.aspx?TabId=" tab.TabID, "My_Custom_Page_Name.aspx")
Проблема
Моя проблема с этим подходом заключается в том, что URL получает только те параметры, которые я напрямую указываю в этом path параметре. Используя стандартный, не дружественный подход с Globals.NavigateURL , я получу дополнительные параметры, основанные на текущем контексте и настройках портала (в первую очередь, language ). Я бы предпочел не переопределять / копировать NavigateURL реализацию, но я не вижу другого выбора. У Брюса есть проблема в системе отслеживания проблем Gemini от DNN, которая позволяет добавить pageName параметр в Globals.NavigateURL , но она довольно долго оставалась без внимания.
Другая проблема заключается в том, что мне приходится жестко указывать «.aspx» в названии страницы, вместо того, чтобы позволить дружественному поставщику URL решать, каким должно быть расширение (или стоит ли вообще обходиться без расширения).
Я что-то упускаю, или копирование ядра NavigateURL мой лучший вариант для получения полной поддержки удобных имен страниц в URL?
Комментарии:
1. В моей ситуации мне нужно упростить несколько сотен тысяч красивых URL-адресов, все в нижнем регистре с дефисами, разделяющими токены. Я внес несколько упрощенных обновлений в DNN URLRewrite, FriendlyURL и одну служебную функцию. При запуске приложения пары Источник / назначение вставляются в состояние приложения, где UrlWrite может преобразовывать исходные (красивые запрошенные URL-адреса) в уродливые (доступные для чтения приложением URL-адреса), а FriendlyURL делает обратное (чтобы поставщики навигационного меню выдавали красивые URL-адреса). Мое решение не заменяет встроенную функциональность DNN, а только улучшает ее.
2. Я несколько раз пытался интерпретировать ваши конкретные потребности, но не могу сказать, поможет ли мое личное решение. Если это звучит привлекательно, дайте мне знать, и я смогу немного уточнить. Я сделал это так, что внедрение и тестирование в будущих версиях DNN должно занять от 1 до 2 часов. Мне не нравится изменять ядро DNN. Я хотел бы, чтобы мастер URL соответствовал моим потребностям, но он плохо масштабировался для этого приложения.
3. Мне нужно лучшее решение для всех сред (для ситуаций, когда я не могу заменить средство перезаписи URL). Я пытаюсь понять, действительно ли эта функциональность не встроена в DNN каким-либо значимым образом, даже несмотря на наличие API, или мне чего-то не хватает, что заставит это работать, не отвлекая внимание от ядра DNN.
Ответ №1:
Одним из небольших улучшений вышесказанного является вызов, Globals.ApplicationURL(tabId) чтобы получить "~/Default.aspx?TabID=x" часть URL. Однако вам все равно придется вручную добавить language параметр…