JQuery-Mobile e ASP.Net - AJAX o Postback?

Question

Ho sviluppato ASP.Net per il passato e fino a poco tempo fa mi sono imbattuto in un progetto mobile. Jquery-Mobile sembra perfetto come framework per questo, quindi mi sono semplicemente tuffato in esso.

Attualmente sto usando l'approccio ASP.Net per mettere i controlli server su una pagina, quindi usare jqm per migliorare quei controlli per renderli mobili. Effettivamente effettuo il postback per raccogliere i dati del modulo ed elaborarli in code-behind. Per evitare un aggiornamento completo della pagina, ho dovuto mescolarli anche con updatepanel. In qualche modo li ho fatti funzionare, ma in fondo sento che questo non è il modo giusto (o efficiente) di farlo.

C'è troppa complicazione nel mescolare le cose per farle bene, quindi penso che forse dovrei semplicemente evitare il postback e fare tutto altrimenti in richieste AJAX pure?

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

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

codice sottostante:

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

Domande:

• Questo funziona, ma è questo il modo migliore per andare con i siti web jQuery-Mobile, o questo è solo un altro brutto esempio?

• UpdatePanel e postback non sono una buona idea per questo scenario? (So ​​che funzionano)

• Se AJAX è preferito, come faccio a compilare un elenco a discesa sul pageload (controllo non server)? L'invio di una richiesta AJAX per popolare DropDownList su $ (document) .ready() sembra stupido per me

Quello che sto cercando è regole pratiche di sviluppo di un sito mobile, non voglio per guidare troppo lontano da ciò che dovrebbe fare bene. I tuoi input sono molto apprezzati. Grazie.

Answer 1

asp.net Web Forms e jQuery Mobile in realtà non funzionano insieme. Il modello postback rompe il modo in cui funziona jQuery Mobile ajax e cadrà quando avrai più di una singola pagina o modulo. Nello specifico, Web Form richiede un singolo tag <form> che avvolge tutti i controlli lato server e non è possibile introdurre ulteriori moduli "interni". jQuery Mobile funziona davvero meglio con il modello ajax e una o più "pagine" (<div data-role="page">) e moduli che sono contenuti all'interno del DOM. I pannelli di aggiornamento finiranno per causare il caos.

Un approccio è semplicemente disattivare il caricamento di jQuery Mobile ajax. Puoi farlo con questo:

//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> 

ma alla fine, non avrai un sito Web altamente efficiente. Se il tuo sito è in esecuzione su una rete wireless locale, potrebbe essere abbastanza buono.

Io lavoro in un ambiente di forme per lo più Web e aveva bisogno di un Web Form basato app jQuery Mobile e 5 o giù di lì "pagine" codificati come un unico file HTML statico. Ho quindi fatto affidamento su JavaScript e jQuery ajax caricando gli endpoint del servizio Web ASMX. Ho anche fatto un uso estensivo di KnockoutJS ma certamente avrei potuto fare affidamento esclusivamente su JavaScript e jQuery ajax per estrarre i dati (e nel mio caso l'app era di natura reportistica senza aggiornamento dei dati). Se stai salvando dei dati, puoi usare la stessa tecnica

Un approccio ancora migliore è quello di andare con asp.MVC netto che elimina il modello di postback forzato e consente il controllo a grana fine su dove vengono posizionati i tag <form>.

Sto lavorando su un sito mobile più grande e utilizzo MVC per il back-end e sfruttando appieno le visualizzazioni Razor ma alla fine mi affido alle chiamate ajax client per tutti i dati e KnockoutJS per quasi tutti i markup dinamici. Alla fine, la mia app lato client non è poi così diversa tra Web Form e MVC. I controller basati su MVC sono più facili da utilizzare per gli endpoint ajax e la soluzione è più pulita.

In generale, inserirò entrambe le soluzioni nell'applicazione "pagina singola", ovvero approccio SPA. Esistono altri approcci che potrebbero funzionare con Web Forms ma, nella mia limitata esplorazione, questa era l'opzione migliore.