JQuery-Mobile i ASP.Net - AJAX lub odświeżenie?

Question

Zajmuję się tworzeniem ASP.Net w przeszłości i do niedawna natrafiam na projekt mobilny. Jquery-Mobile wydaje się idealny do tego, więc po prostu wskoczyłem w to.

Obecnie używam podejścia ASP.Net do umieszczenia elementów sterujących serwera na stronie, a następnie użyj jqm do ulepszenia tych elementów sterujących, aby stały się mobilne. Rzeczywiście, odświeżam dane, aby zbierać dane formularzy i przetwarzać je za pomocą kodu. Aby uniknąć pełnego odświeżania strony, musiałem również połączyć je z updatepanelem. W jakiś sposób sprawiłem, że działały, ale w głębi duszy po prostu uważam, że nie jest to właściwy sposób (lub skuteczny sposób) robienia tego.

Jest zbyt wiele komplikacji związanych z miksowaniem różnych rzeczy, więc wydaje mi się, że powinienem po prostu unikać postbacków i robić wszystko - w innych przypadkach w czystych żądaniach AJAX?

$.ajax({ 
type: 'POST', 
    url: "/GetName", 
    data: "{}", 
    contentType: "application/json; charset=utf-8" 

}) 
.success(function (response) { 
    alert(response); 
}); 

kod z opóźnieniem:

[WebMethod()] 
public String GetName() 
{ return "Jack"; } 

Pytania:

• To działa, ale jest to lepszy sposób, aby przejść z jQuery-Mobile stronach internetowych, lub jest to po prostu kolejny zły przykład?

• Czy UpdatePanel i postback to zły pomysł na ten scenariusz? (Wiem, że działają)

• Jeśli preferowane jest AJAX, w jaki sposób mogę wypełnić listę rozwijaną na stronie pageload (brak kontroli serwera)? Wysyłanie żądania AJAX do wypełnienia dropdownlist na $ (document) .ready() wydaje mi się głupi

Co szukam ma reguły kciuka opracowania stronę mobilną, nie chcę, aby sterować zbyt daleko od tego, co należy robić dobrze. Twoje dane wejściowe są bardzo doceniane. Dzięki.

Answer 1

asp.net Web Forms i jQuery Mobile naprawdę nie działają razem. Model odświeżenia działa tak, jak działa jQuery Mobile ajax, a jego działanie kończy się, gdy masz więcej niż jedną stronę lub formularz. W szczególności Web Forms wymaga pojedynczego tagu <form>, który owija wszystkie kontrolki po stronie serwera i nie można wprowadzać dodatkowych "wewnętrznych" formularzy. jQuery Mobile naprawdę działa najlepiej z modelem ajax i jedną lub więcej "stronami" (<div data-role="page">) i formularzami zawartymi w DOM. Aktualizacja paneli ostatecznie doprowadzi do chaosu.

Jednym ze sposobów jest wyłączenie ładowania jQuery Mobile ajax. Możesz to zrobić w ten sposób:

//note that the order of script loading here is critical. 
<script src="http://code.jquery.com/jquery-1.8.2.min.js"></script> 
<script> 
    $(document).bind(“mobileinit”, function() { 
     $.mobile.ajaxEnabled = false; 
    }); 
</script> 
<script src="http://code.jquery.com/mobile/1.2.0/jquery.mobile-1.2.0.min.js"> 
</script> 

, ale na końcu nie będziesz mieć wysoce wydajnej strony internetowej. Jeśli witryna działa w lokalnej sieci bezprzewodowej, może być wystarczająco dobra.

Pracuję w środowisku najczęściej w środowisku Web Forms i potrzebuję aplikacji jQuery Mobile opartej na Web Forms i zakodowałem 5 lub więcej "stron" jako pojedynczy statyczny plik html. Następnie zacząłem polegać na JavaScript i jQuery ajax ładując punkty końcowe ASMX. Rozlegle korzystałem również z KnockoutJS, ale z pewnością mogłem polegać wyłącznie na JavaScript i jQuery ajax, aby pobierać dane (w moim przypadku aplikacja miała charakter sprawozdawczy bez aktualizacji danych). Jeśli zapisujesz dane, możesz użyć ta sama technika.

Jeszcze lepszym podejściem jest stosowanie asp.net MVC, który eliminuje wymuszony zwrotny model i umożliwia precyzyjną kontrolę nad miejscem, w którym umieszczone są twoje znaczniki <form>.

Pracuję nad większą stroną mobilną i korzystam z MVC na zapleczu i korzystając w pełni z widoków maszynki Razor, ale ostatecznie polegam na wywołaniach ajaxowych po stronie klienta dla wszystkich danych i KnockoutJS dla prawie wszystkich dynamicznych znaczników. Ostatecznie moja aplikacja po stronie klienta nie różni się zbytnio od Web Forms i MVC. Kontrolery oparte na MVC są łatwiejsze do pracy z punktami końcowymi ajax, a rozwiązanie jest czystsze.

Ogólnie rzecz biorąc, stosowałbym oba rozwiązania w ramach "aplikacji pojedynczej strony", czyli metody SPA. Istnieją inne podejścia, które mogą współpracować z Web Forms, ale w moich ograniczonych eksploracjach była to najlepsza opcja.