Feeding .NET MVC Ansichten der jQuery UI Weg

Question

Ich habe ein paar Blog-Beiträge und Tutorials über das Mischen in jQuery und die UI-Elemente für Ansichten in einer .NET MVC Web App gesehen. In der Regel sind sie jedoch auf Entwickler ausgerichtet, die einen umfassenden Überblick über den gesamten Entwicklungszyklus und Variationen der Back-/Middle-Tier-Technologien haben.

Als der Front-End-Entwickler ich eine jQuery-only UI zum Back-End-dev werfen - er warnt vor einem Nicht-Webforms-Schnittstelle wegen der Code-Reife pov.

Ich versuche, mit zurück zu schlagen "Nun ... es ist dein Muster ... ist es nicht elementar zu MVC? Keine Logik in der Ansicht? Ich lese das zu sein" Server-Side-Zeug '. Sie serialisieren nur die Eigenschaften, nach denen ich suche, oder besser ... lassen Sie mich leicht herausfinden, was Sie mir schicken können ... ich werde in der Lage sein, die Benutzeroberfläche über die jQuery UI zu implementieren. "

Wie gültig ist meine Position?

Kann erwartet werden, dass das jQuery-Grid mindestens die unteren 85% der nativen Kontrolle von .net (niedrige bis mittlere Kapazitäten # von Zeilen) verarbeitet?

Wie wäre es mit der Inline-Bearbeitung? ... vom Netz?

Würde die ausschließliche Arbeit in Web Services sein Leben vereinfachen? und wenn ja, wäre das nicht der logische Weg, eine .net-zu-jQuery-Beziehung aufzubauen? - Ajax Liaison Twixt Server (. NET WS-Methoden) und Client?

mny thx --Steve ...

Answer 1

Wenn dies ein Admin-Interface ist, und der Kunde hat sich bereit erklärt, dass die Nutzer Javascript dann denke ich, aktiviert haben müssen mit Hilfe von JavaScript-Widgets bauen auf der Seite ist eine bessere Option als die Verwendung der Serversteuerelemente von asp.net. Wenn dies jedoch eine öffentlich zugängliche Website ist, würde ich argumentieren, dass ein reiner HTML- und CSS-Ansatz viel besser ist, und dann Javascript verwenden, um die Seite progressiv zu verbessern!

Jetzt befürworte ich nie asp.net Serversteuerelemente, weil sie schlechte Markup ausspucken und sie sind übermäßig kompliziert zu verwenden. Stattdessen habe ich jQuery verwendet, um die Grunt-Arbeit und dom Query und Traversing zu tun. Ich befürworte auch nicht die Verwendung von jQuery UI, weil sie einige sehr wichtige Widgets, zum Beispiel keine Datentabelle, keine Baumansicht usw. fehlen. Ich weiß, dass es viele Plugins für jQuery gibt, aber sie sind nicht komponiert und daher muss jedes Plugin das Rad neu erfinden alles erreichen, was es braucht. Sobald Sie all Ihre Plugin-Bibliotheken und CSS hinzugefügt haben, haben Sie oft eine sehr große Seitenfläche. Außerdem hat jedes Plugin oft eine andere Homepage und Dokumentation, die vielleicht nicht auf dem neuesten Stand ist.

Ich denke, dass die beste UI-Bibliothek YUI ist, und Sie können es leicht mit jQuery kombinieren. Da jedes Widget aus Kernkomponenten besteht, ist das Gesamtgewicht des Downloads geringer. Außerdem haben Sie die gesamte Dokumentation an einem Ort mit 100 Arbeitsbeispielen. Es bedeutet auch, mit dem gleichen Satz von JavaScript-Mustern auf der ganzen Linie zu arbeiten, so dass Sie mit jedem Widget mehr und mehr über die Bibliothek erfahren. Hoffentlich jQuery UI holt auf, aber persönlich freue ich mich auf YUI 3 was für mich bedeutet, jQuery insgesamt fallen zu lassen ...

Answer 2

Kämpfen Sie nicht die Plattform. So liegt Schmerz und Leid.

Die MVC-View-Objekte unterscheiden sich erheblich von ASP.net-Webformularen mit Serversteuerelementen - Sie erhalten direkt HTML. Sie erhalten Jquery und Ajax im Grunde kostenlos, mit (fast) magischen Server-Seite Ajax Anrufverarbeitung.

Sie sind entworfen, um zu tun, was Sie fragen. Schreiben Sie Ihre eigene jquery ui erfindet das Rad neu.

Nicht nur wäre es eine Tonne zusätzlicher Arbeit für keinen Gewinn. Sie wären der einzige Entwickler, der das versucht, und wenn Sie Hilfe brauchen, können nur wenige einen Rat geben.

Answer 3

jQuery ist eine sehr ausgereifte Bibliothek. Es wird von Tausenden von Menschen im Internet verwendet, und ich glaube nicht, dass ich jemals einen Fehler gefunden habe. YUI wird von YAHOO überflutet, also ist es auch kampferprobt.

Eine Sache, die ich Ihnen nicht erwähnt habe, ist, dass ich die Standard-Webforms-View-Engine mit asp.net mvc verwende. Ich denke, es ist immer noch die beste Option, da Sie intellisense und auch Resharper Refactoring sogar Ihre Ansichten durchsucht, und die statische Lösung Analyse kann Code-Fehler in Ihren Ansichten finden.

Zum Erstellen meiner Markup habe ich MvcContrib Fluent Html verwendet, aber Sie könnten auch this article auschecken, die das DRY Prinzipal sehr gut befürwortet.