Mam jedną aplikację strony - co oznacza, że wszystko na serwerze zostaje przekierowane do pojedynczego pliku index.html, który wykonuje ciężkie podnoszenie i trasowanie przy użyciu interfejsu API historii HTML5 (pushstate).Routing w jednej aplikacji strony z inną stroną główną
Teraz chcę dodać nową stronę docelową z boku - nazwijmy go landing.html i chcę klientów najpierw dostać się do landing.html gdy dostęp / i index.html jeżeli mają dostęp do jakiejkolwiek innej trasy.
Teraz IE9 nie obsługuje interfejsu API historii HTML5, więc używa się w nim ścieżek "hash-urls", takich jak /books/authors, czyli . Ponieważ sekcja hash adresu URL is not sent to the server dotyczy serwera, wszystkie ścieżki są /, co oznacza, że nie mogę prowadzić do landing.html lub index.html w oparciu o tę logikę.
myślałem hack - przekierowanie URL z / do landing.html, wykrywanie #! na kliencie, dodając cookie na serwerze (lub klient) nazywa notReallyHomePage i przekierowanie do odpowiedniej strony na podstawie pliku cookie na serwerze . To jest naprawdę hacky i nie jest dobrym rozwiązaniem.
Jaki byłby właściwy sposób postępowania z routingiem w tym przypadku?
Moje backend jest w ASP.NET MVC, ale nie sądzę, że to istotne pytanie
Dlaczego nie skorzystać z możliwości oferowanych przez routingu ASP.NET MVC. – Antony
@Antony, ponieważ nie działają w ten sposób aplikacje pojedynczej strony. Routing odbywa się po stronie klienta - nie musisz więc uderzać serwera, gdy użytkownik kliknie link. Zaletą jest to, że większość tras wymaga tylko JSON z serwera (a nie znaczników), a inne mogą pominąć trafienie serwera w ogóle. –
Prawdopodobnie chcesz coś w rodzaju strony indeksu/kontenera, która ma logikę routingu. Ta strona ładuje się w częściach w zależności od wybranej trasy. Ponieważ twoje trasy nie są wysyłane na serwer, nie sądzę, że możliwe jest natychmiastowe załadowanie poprawnej strony. – Cerbrus