nicht angemeldet
Webanwendungen mit MS VS .NET entwickeln
0 0 0 MS data grids
Webanwendungen mit MS VS .NET entwickeln
Hi,
die Firma, in der ich seit kurzem arbeite, setzt Microsoft Visual Studio .NET 2005 und ASP.NET 2.0 ein, um ihre Webanwendungen zu entwickeln. Genauer gesagt soll eine Desktop Anwendung fürs Web umgeschrieben werden...
Und irgendwie komm ich damit nicht so ganz zurecht... Also nicht mit dem Studio an sich, sondern überhaupt mit der ganzen ASP.NET sache...
Hat schon mal jemand damit eine große Webanwendung entwickelt?
Was mich am meisten stört ist, dass es für mich sehr kompliziert erscheint, wie alles zusammen hängt.
Und irgendwie scheint es mir oft unflexibel. Es gibt zB auf einer Seite ein Formular mit Validatoren und weiterhin ein Suchfeld. ASP.NET macht aber immer nur ein Formular (<form>-Tag) pro Seite. Möchte ich nun das Suchfeld abschicken, reagieren die Validatoren und das Formular wird nicht abgeschickt. Das liegt daran dass die Validatoren an das onsubmit event des Formulars gekoppelt sind. Ich habe aber zB keine schnelle Möglichkeit gefunden, dass Suchfeld seperat zu behandeln, da ja alles unter einer <form> steckt.
Es sind halt oft lauter so kleine Sachen, die mir das Leben schwer machen. Allein schon die ganze Verwirrung auf Serverseite mit den ganzen On.... Methoden. zB OnPreRender, OnPreInit, OnInit, Page_Load...
oder die ganzen zig Einträge in der web.config.
Oder Komponenten, die Fehlermeldungen wie ("~ must not be registereed before PreRender-Funktion") erzeugen.
Was mich auch noch nervt, dass Komponenten eingesetzt werden, die sehr seltsamen Code produzieren oder schlecht zusammen arbeiten. <style> innerhalb von <body>, oder eine Navileiste wird als tabelle statt ul gerendert.
Ich bin halt PHP Programmierer und entweder ist es so, dass es wirklich sehr viel einfacher oder übersichtlicher ist oder ich mich einfach noch zu wenig mit ASP.NET beschäftigt habe.
Vielleicht kann ja mal jemand was dazu schreiben, der schon Erfahrung mit größeren Webprojekten auf ASP.NET (2.0?) Basis hat.
Viele Grüße!
-
Hi,
es ist alles Gewöhnungssache, gerade wenn du aus einer eher prozeduralen Programmierwelt wie PHP kommst.
Auch ist das Konzept von ASP.Net mit seinen vielen Designern und vorgefertigten Komponenten (die ihren HTML-Sourcecode generieren) primär auf schnell-zusammenklicken-und-es-funktioniert ausgerichtet und von daher vielleicht etwas undurchsichtig am Anfang. Viele der Komponenten die du auf eine "Seite" zusammenklicken kannst bedienen sich per default gerendertem JavaScript für die Funktionalität, zum Bleistift eben diese Validatoren. Du kannst aber genauso auch ASP.Net Seiten nach dem klassischen Schema "Response.Write" plus dein eigener HTML-Sourcecode basteln. Oder, wenn du entsprechend Erfahrung hast, dann schreibst du dir deine eigenen Komponenten, die dann "semantisch sinvolleren" Code erzeugen.
<table> hin, <ul> her... am Ende funktioniert es und nur das (sowie eine ausreichende Kompatibilität mit diversen Brausern) interessiert den Kunden. Das einige "Semantisches-Markup"-Fetischisten sich nicht ganz wohlfühlen, ist eine andere Geschichte, die ich nicht zu diskutieren brauch.
Um dich besser mit ASP.Net anzufreunden und zu verstehen warum es so ist wie es ist, solltest du dir vielleicht mal ein paar Artikel zum Thema "Lebenszyklus einer ASP.Net Seite" durchlesen. Dann wirst du auch sehr schnell erkennen wozu diese ganzen OnDies und OnDas Methoden da sind.
Warum es nur ein <form> pro Seite gibt? Wozu sollte es mehrere geben? Das <form> Tag spielt bei der Programmierung eine ziemlich unwichtige Rolle. Du greifst für gewöhnlich über die Controls-Collection oder über direkte Felder auf die einzelnen "Formular"-Felder bei PostBacks (form.submit()) zurück. Das Verdrahten, ob das Formular wirklich zum Server geschickt wird oder ob die Aktion (Buttonklicks) auch client-seitig via JS abgehandelt wird, geschieht hinter geschlossenen Gardinen, sprich du sollst dich darum gar nicht kümmern. Du erzeugst einfach deine Formularelemente, verdrahtest sie mit Aktionen (Events) und fertig.
Hast du vorher schon mal reine Windows-Anwendungen entwickelt. Wenn ja, solltest du feststellen, dass MS versucht hat, das Programmiermodell von Windows Forms direkt aufs Web = ASP.Net zu übertragen.
Mit Version 2.0 hat MS (eine Wertung dazu möchte ich aber nicht abgeben) dem ASP.Net noch eine ganze Masse an deklarativer Programmiermöglichkeit hinzugefügt, weniger offensichtlicher Code, noch mehr "behind-the-scenes".
Finale Frage: Wenn du 0 Erfahrung mit ASP.Net (anscheinend wohl auch mit .Net allgemein), was machst du dann in diesem Job? Hat man dich mit dem Bewusstsein angestellt, dass du dich eigentlich erst 12 Monate lang richtig einarbeiten müsstest? Nicht dass ich dir die Fähigkeit zum Einlernen absprechen möchte ... ich finde es nur etwas seltsam ... aber ich kenne ja auch die näheren Umstände nicht.
Ciao, Frank
-
Hi,
ich hatte schon Erfahrung mit .NET und Windows.Forms. Auch etwas ASP.NET. Aber vielleicht nicht in der Intensität wie jetzt.
Und als ich eingestellt wurde, war noch gar nicht klar ob ich Webkram mache oder mich doch eher ums Framework kümmern sollte.
Programmieren kann ich ja, auch C# und in .NET Umgebung.Nur irgendwie scheint ASP.NET Programmierung (im Moment) weniger Programmierung zu sein, sondern mehr Geklicke auf grafischen Wizards von Komponenten oder im Designer, Einstellungssache und Fehlersuche zu sein.
Ich fühl mich nur manchmal etwas hilflos, da ich zB nicht weiß wodurch das onsubmit Attribut reingerendert wird. Und wenn ich es da (in <form>) nicht haben will, oder wenn ich dessen Wert ändern will, dann geht das halt nicht so einfach. Oder ich bin zu dumm. Aber jedenfalls gehts nicht intuitiv, da es ja im Code nicht da ist, und erst zur Laufzeit entsteht.Man scheint halt kaum Handhabe zu haben, was ASP.NET alles im Hintergrund macht und was dann am Ende im Browser ankommt.
Gruß!
Hi,
es ist alles Gewöhnungssache, gerade wenn du aus einer eher prozeduralen Programmierwelt wie PHP kommst.
Auch ist das Konzept von ASP.Net mit seinen vielen Designern und vorgefertigten Komponenten (die ihren HTML-Sourcecode generieren) primär auf schnell-zusammenklicken-und-es-funktioniert ausgerichtet und von daher vielleicht etwas undurchsichtig am Anfang. Viele der Komponenten die du auf eine "Seite" zusammenklicken kannst bedienen sich per default gerendertem JavaScript für die Funktionalität, zum Bleistift eben diese Validatoren. Du kannst aber genauso auch ASP.Net Seiten nach dem klassischen Schema "Response.Write" plus dein eigener HTML-Sourcecode basteln. Oder, wenn du entsprechend Erfahrung hast, dann schreibst du dir deine eigenen Komponenten, die dann "semantisch sinvolleren" Code erzeugen.
<table> hin, <ul> her... am Ende funktioniert es und nur das (sowie eine ausreichende Kompatibilität mit diversen Brausern) interessiert den Kunden. Das einige "Semantisches-Markup"-Fetischisten sich nicht ganz wohlfühlen, ist eine andere Geschichte, die ich nicht zu diskutieren brauch.
Um dich besser mit ASP.Net anzufreunden und zu verstehen warum es so ist wie es ist, solltest du dir vielleicht mal ein paar Artikel zum Thema "Lebenszyklus einer ASP.Net Seite" durchlesen. Dann wirst du auch sehr schnell erkennen wozu diese ganzen OnDies und OnDas Methoden da sind.
Warum es nur ein <form> pro Seite gibt? Wozu sollte es mehrere geben? Das <form> Tag spielt bei der Programmierung eine ziemlich unwichtige Rolle. Du greifst für gewöhnlich über die Controls-Collection oder über direkte Felder auf die einzelnen "Formular"-Felder bei PostBacks (form.submit()) zurück. Das Verdrahten, ob das Formular wirklich zum Server geschickt wird oder ob die Aktion (Buttonklicks) auch client-seitig via JS abgehandelt wird, geschieht hinter geschlossenen Gardinen, sprich du sollst dich darum gar nicht kümmern. Du erzeugst einfach deine Formularelemente, verdrahtest sie mit Aktionen (Events) und fertig.
Hast du vorher schon mal reine Windows-Anwendungen entwickelt. Wenn ja, solltest du feststellen, dass MS versucht hat, das Programmiermodell von Windows Forms direkt aufs Web = ASP.Net zu übertragen.
Mit Version 2.0 hat MS (eine Wertung dazu möchte ich aber nicht abgeben) dem ASP.Net noch eine ganze Masse an deklarativer Programmiermöglichkeit hinzugefügt, weniger offensichtlicher Code, noch mehr "behind-the-scenes".
Finale Frage: Wenn du 0 Erfahrung mit ASP.Net (anscheinend wohl auch mit .Net allgemein), was machst du dann in diesem Job? Hat man dich mit dem Bewusstsein angestellt, dass du dich eigentlich erst 12 Monate lang richtig einarbeiten müsstest? Nicht dass ich dir die Fähigkeit zum Einlernen absprechen möchte ... ich finde es nur etwas seltsam ... aber ich kenne ja auch die näheren Umstände nicht.
Ciao, Frank
-
Nur irgendwie scheint ASP.NET Programmierung (im Moment) weniger Programmierung zu sein, sondern mehr Geklicke auf grafischen Wizards von Komponenten oder im Designer, Einstellungssache und Fehlersuche zu sein.
Das Problem mit dem MS-Spielzeug ist, dass es deppenhafte SW-Entwickler generiert. Das Spielzeug muss nicht unbedingt schlecht sein und manchmal ist man ja auch für den einen oder anderen Assi dankbar, aber leider, leider bekommt man als Entwickler oft nicht mit, was im Hintergrund an Code generiert wird. Unser persönliches Hassobjekt ist ADO und sein Vorgänger DAO für den Datenzugriff.
Ich fühl mich nur manchmal etwas hilflos, da ich zB nicht weiß wodurch das onsubmit Attribut reingerendert wird.
Häh?
Man scheint halt kaum Handhabe zu haben, was ASP.NET alles im Hintergrund macht und was dann am Ende im Browser ankommt.
Exakt das ist das typische MS-Problem. Auch bei Windows haben wir ein flaues Gefühl.
-
vorab: Vollzitate sind hier im Forum nicht ganz so beliebt, zitiere ggf nur das, was du kommentieren willst.
Dass du Erfahrung mit .Net hast, kam aus deinem ursprünglichen Beitrag nicht wirklich heraus ... deswegen ja auch meine Nachfrage, was du in dem Job willst. ;)
Wie ich auch geschrieben habe, ASP.net 2.0 ist um Längen deklarativer geworden gegenüber ASP.net 1.1. Die ganzen neuen Markup-Elemente wie ObjectDataSource, SqlDataSource (wo man deutlich sieht, wie MS die Integration mit dem eigenen SQL Server aufdrängelt ;) sind wirklich gedacht um alles nur noch fix per drag und drop zusammenzuklatschen. Frontends von der Konfektionsstange. Ich hatte im Juni keine 2 Stunden gebraucht um ein WM-Tippspiel für unsere Abteilung zusammenzuklicken, Datasource, GridView da und zum schluss noch 5 minuten CSS zur Verschönerung gebastelt ... das wars, der Rest der Logik wie z.b. Auswertung war sowieso in der Datenbank.
Ganz im Detail kann vielleicht nicht auf das spezifische HTML-Rendering jeder Komponente Einfluss nehmen aber grundsätzlich kommen bedienbare Websites heraus, und man bekommt sie sogar auch w3c-valide :)
OnSubmit ist weniger ein Attribut als eine Überschreibung eines Basisklassenmethode, die genau dann von der Basisklasse auch aufgerufen wird, wenn ein Submit durchgeführt wird. :)
"Jede" ASP.Net Seite erbt von bzw. ist abgeleitet von der Page-Basisklasse und besitzt eine Collecion für alle Controls, die man manuell oder per DragDrop auf die Seite geklatscht hat. Wenn du da jetzt eine Textbox nach ihrem Inhalt fragen willst, dann kannst du das über den deklarierten Member für dieses Objekt in deiner Seite. this.txtbox1.Text ... und ja du kannst darüber auch Daten hineinschreiben.
Grundsätzliche Frage: Warum willst du dich um das Rendering (wie es dann im Browser ankommt) unbedingt selbst kümmern? Bei Winforms tust du es ja auch nicht. Und das Ergebnis am Ende scheint für eine ausreichende Menge an Projektentscheidern und Kunden akzeptabel zu sein :) Und denen ist es oft egal, ob du <table> oder <ul> für die Navigation verwendet hast :). Ich denke es gibt noch keine aussagekräftigen Studien ob solche Feinheiten den Mehrwert eines Produktes überhaupt merklich beeinflussen. Wenn doch, dann her damit ;)
Für dich: Lerne einfach mit dem Programmiermodell "Page", "Controls" und "Events" im Zusammmenhang mit dem Lebenszyklus von ASP.net Seiten umzugehen. Du wirst sicher Kollegen haben, die da nicht mehr so grün sind. :)
Schönen Abend noch
Frank-
Hi,
Grundsätzliche Frage: Warum willst du dich um das Rendering (wie es dann im Browser ankommt) unbedingt selbst kümmern?
Will ich ja eigentlich nicht. Aber sobald ich so einen RequiredFieldValidator auf die Seite ziehe und EnableClientScripting auf true setze, dann scheint das Formular bei jedem submit zu prüfen, ob das Formular einen bestimmten Wert hat. Falls nein, wird der submit gecancelt.
So. jetzt hab ich noch ein Suchfeld, was völlig unabhängig von dem FieldValidator ist, mit eigenen SubmitButton. Und möchte ich die Suchanfrage starten, wird nicht submittet, weil von irgendeinem anderen Formular der Validtor meckert.
Im ASP Code sieht das halt nur so aus, dass man einfach ein asp:RequiredFieldValidator auf die Seite zieht und fertig, dadurch scheint ASP ein onsubmit="return Webform_Validate()" in das form-Tag zu rendern. Aber wenn ich jetzt sagen möchte, dass die Validatoren nur anspringen sollen, wenn auch der Button, der zu dem Validator gehört gedrückt wurde und NICHT auch beim Such-Submitbutton, dann weiß ich halt nicht wie es geht.
Das war ja nur ein Beispiel. Ich finde öfters solche Sachen, die mich aufregen. Nicht nur ASP.NET sondern eher auch Komponenten und Erweiterungen, wie zB Ajax Extensions und so...
gruß!
-
ah jetzt nicht mehr nur "cs" :)
Gegenfrage: Wozu setzt du dann einen RequiredFieldValidator (Erforderliches-Feld-Validator) ein? Es ist eine vorgefertigte Komponente die einen ziemlich häufig verwendeten Use Case abdeckt. Dass dieser dir nun nicht grad in den Kram passt für deine Aufgabenstellung ... PG.
Du könntest ja einfach die Button-Klicks entsprechend implementieren, dass der eine Button eben bei Klick das eine Feld prüft und der andere eben nicht. Und wenn du so etwas öfter brauchst, bastel dir deine eigene Komponente draus, die du an z.b. Buttons binden kannst. Da der RequiredFieldValidator in der Lage ist, JS code zu emittieren, wirst du das sicher auch von Hand bei anderen Komponenten passieren lassen können. :))
Es ist schon spät und ich hab gerade kein VS zur Hand, sonst würde ich das mal spasseshalber ausprobieren :)
wie zB Ajax Extensions und so...
Hab ich noch nicht benutzt, aber das (Ajax) ist für mich sowieso böse Voodoo-Hexerei ;) und so ...
Gut Nacht!
Frank
-
-
-
-
Mit Version 2.0 hat MS (eine Wertung dazu möchte ich aber nicht abgeben) dem ASP.Net noch eine ganze Masse an deklarativer Programmiermöglichkeit hinzugefügt, weniger offensichtlicher Code, noch mehr "behind-the-scenes".
Mal ne Frage an den MS-Experten: Diese data grids, wie schwierig ist es diese an stored procedures zu binden (für CRUD). Taugen die grids etwas?
-
Hi King Lully, welche "data grids" meinst du genau?
Das DataGridView von ASP.Net 2.0? Ja, das geht ziemlich simpel. SqlDataSource mit den jeweiligen SPs als CRUD Commands definieren und die Parameter auf die jeweiligen Grid Spalten mappen :)Cheers,
Frank-
Hi King Lully, welche "data grids" meinst du genau?
Das DataGridView von ASP.Net 2.0? Ja, das geht ziemlich simpel. SqlDataSource mit den jeweiligen SPs als CRUD Commands definieren und die Parameter auf die jeweiligen Grid Spalten mappen :)Eine Kollegin von uns hat vor ca. 3 Jahren wochenlang geforscht und kam mit den data grids nicht zurecht. (Sie frickelte allerdings auch im ASP-Code. ;)
Anmerkungen: Die Probleme kamen, wenn SELECTs in die Spalten eingebaut werden mussten, was ja eigentlich nichts besonderes ist.
Das Produkt hiess VS Studio 2005, wenn meine Erinnerungen nicht täuschen.-
Vor 3 Jahren gab es noch kein VS 2005 (.net 2.0) in der Form, dass irgendjemand damit hätte damit schon herumexperimentieren können, du meinst eher das VS 2003 (.net 1.1)?
Und mit "SELECTs" meinst du <select><option/><option/></select> oder SELECT Elefant FROM Afrika?
Mit den damaligen DataGrids (1.1) war und ist es immer noch eine Frickelei für sich, das kann gut sein. :) Deswegen wurde für ASP.Net 2.0 auch eine Menge in dieser Hinsicht (Datenbindung von Controls) getan.
Die Fortsetzung heisst dann WPF (Windows Presentation Foundation) - wobei ich WPF noch nicht bezüglich Websites genauer angeschaut habe, nur für Windows Anwendungen. Und da heisst es auch noch mal komplett umdenken vom aktuellen Programmiermodell :)
Gut Nacht
Frank-
Und mit "SELECTs" meinst du <select><option/><option/></select> oder SELECT Elefant FROM Afrika?
<SELECT>s waren gemeint, SQL-SELECTs passen nicht so gut in Tabellenspalten.
Mit den damaligen DataGrids (1.1) war und ist es immer noch eine Frickelei für sich, das kann gut sein. :)
Wenn ich mich recht erinnere frickelte die im ASP-Code herum, dann wieder im data grid-"Steuerelement", dann lief Darstellung und ASP-Code auseinander und dann hat es irgendwann mit ungeheuerem Aufwand geklappt bis rauskam, dass irgendwas doch nicht ging u.s.w..
Deswegen wurde für ASP.Net 2.0 auch eine Menge in dieser Hinsicht (Datenbindung von Controls) getan.
Die Fortsetzung heisst dann WPF (Windows Presentation Foundation) - wobei ich WPF noch nicht bezüglich Websites genauer angeschaut habe, nur für Windows Anwendungen. Und da heisst es auch noch mal komplett umdenken vom aktuellen Programmiermodell :)
WPF, brr, ich schliesse aus Deinem Vortrag nun, dass man HTML-basierten data grids von MS weiterhin nicht trauen kann, richtig?!
-
Weder falsch noch richtig. Wenn du nur intensiv nach einer Lücke in einem Zaun suchst, wirst du sie auch finden. Nichts ist universell für jede Anforderung einsetzbar. 3rd Party Produkte wie Infragistics sind auch nicht viel besser, sie haben meistens nur (man muss ja was zum Werben haben) mehr Features als die hauseigenen Microsoft-Controls.
Dein Problem mit dem ASP-Code/Datagrid Gefrickel, was, wie oder auch nicht funktionierte kann ich um diese Uhrzeit nicht mehr nachvollziehen, da müsstest du mir schon konkrete Anhaltspunkte geben.
WPF mögen wir wohl nicht? Klingt zu sehr nach Vista?
Jetzt aber endgültig: Gut Nacht, ich hab morgen wieder einige OO-vs-RDBMS Schlachten zu schlagen... :)
-
Dein Problem mit dem ASP-Code/Datagrid Gefrickel, was, wie oder auch nicht funktionierte kann ich um diese Uhrzeit nicht mehr nachvollziehen, da müsstest du mir schon konkrete Anhaltspunkte geben.
Nun, ich bat einmal eine Kollegin die data grids von VS2005 zu prüfen, hatte selbst einen Blick darauf geworfen und war zufrieden bzw. wäre zufrieden gewesen, wenn das mit den <SELECT>s noch geklappt hätte.
Es ist ja eine Standardanforderung, man hat eine Entität, die zu bearbeitem ist (Create, Delete, Update, Read), hat dafür verschiedene SPs, will eine Bindung an diese mit etwas JS und einer einzigen "grossen" <FORM>.
Dann hat man noch diese Verweise (FKs) auf andere Entitäten, die dann als <SELECT>s angezeigt werden und zuvor per "List-SP" geladen worden sind.
Das ist an und für sich nichts Besonderes und mit Marke Eigenbau und bspw. Perl kriegt man das recht gut hin.
Und ich vermutete damals, dass die data grids das auch mit geringem Aufwand hinkriegen bzw. der Entwickler mit Hilfe derselben.
Du kannst ja mal ein grid mit einem <SELECT> erstellen und mal schauen wie lange das dauert (inkl. CUD).
Die Dame benötigte etwa 80 Arbeitsstunden um zu scheitern. ;)
-
-
-
-
-
-
-