コントロールと標準の HTML

https://stackoverflow.com/questions/22084

09-06-2019
|

質問

私は ASP.NET (C# - この特定の質問には関係ないことはわかっていますが、完全な情報開示など) に興味を持っていますが、 asp:-style コントロールのおかげで、面倒な HTML 作成の手間が大幅に軽減されますが、特定の動作でイライラすることがよくあります。昨夜、マスターページを使用しているときに次のような問題に遭遇しました。私の <asp:BulletedList ID="nav">, 、HTMLに変換すると、次のようになりました。 <ul id="ct100_nav">.

他にも問題があります。DataGrid に自動入力すると、必ずしも必要ではない属性が結果のテーブルに追加されることに気付きました。

フレームワークに依存して退屈な業務の一部を引き受ける場合、ある程度の「設定に関する規約」を受け入れなければならないことは承知していますが、この場合の「規約」は確立された規約というよりも、むしろ不要な余分なもの。知っているなぜ ID によってプレフィックスが追加されますが、特に Web 標準の伝道者として、単一のページ内で HTML ID を重複させたりはしないので、このようなことを微調整してオフにすることはできるはずです。

そこでここでの質問は、私よりも経験豊富な ASP.NET 開発者向けです。アプリの開発と展開の経験の中で、これらのコントロールをどのように活用していますか?ハードコーディングされた HTML に戻ってしまうことはありませんか?ブレンドを使っていますか？これらのコントロールの特異な癖を中心に HTML を設計したくはありませんが、可能であれば、それらを活用したいと考えています。

男の子は何をすればいいでしょうか？

解決

個人的には、

社内のものには標準の ASP.NET コントロールが適していると思います。そのシナリオでは、クイックアンドダーティが適しています。しかし、私はかつてデザイナーでもある Web 開発者と仕事をしたことがありますが、彼は ASP.NET コントロールの使用を拒否し、HTML でコードを記述し、必要に応じて runat="server" タグを追加するだけでした。これは、彼が HTML がどのようにレンダリングされるかを正確に知りたかったためであり、いずれにしても、当時は ASP.NET コントロールの一部が標準に準拠してレンダリングされませんでした。

私はその中間に位置します。適切な場合には HTML を使用し、そうでない場合には使用しません。両方の長所を活かすことができます。 CSS コントロールアダプター

他のヒント

ここで私自身の意見と一致する意見をいくつか見て、実際にとても安心しました。テンプレート言語としての ASP.NET は非常に貧弱です。

ここでプロが指摘したいくつかの点に反論したいと思います（炎スーツを着て！）。

Dave Ward は ID の衝突について言及しています。これは事実ですが、その対応がひどいと思います。clientID のような ASP.NET 内部に従うことを除いて、ID を実質的に役に立たなくするよりも、xpath またはディープ css セレクターによってノードが参照されることを希望します。CSS と JS の記述が無意味にはるかに困難になるだけです。

ロブ・クーパーは、コントロールが HTML の代わりになるので大丈夫だと語ります (意訳、許してください、ロブ) - まあ、大丈夫ではありません。なぜなら、彼らは既存のよく理解されている言語を採用し、「いいえ、私たちのやり方で物事を進めなければなりません」と言ったからです。今」、そして彼らのやり方は とても 実装が不十分。例えばasp:panel は、あるブラウザーではテーブルをレンダリングし、別のブラウザーでは div をレンダリングします。ドキュメントや実行がなければ、ログインコントロール (およびその他のコントロール) のマークアップは予測できません。それに対してデザイナーに CSS を書いてもらうにはどうすればよいでしょうか?

Espo は、プラットフォームが HTML を変更した場合にコントロールがどのように抽象化の利点をもたらすかについて書いています。これは明らかに循環的です (プラットフォームが変更されているために変更されているだけであり、代わりに独自の HTML があればその必要はありません)。実際に問題が発生します。更新によってコントロールが再度変更される場合、CSS はそれにどのように対処するのでしょうか?

擁護者は「はい、しかしこれは設定で変更できます」と言うか、コントロールやカスタムコントロールのオーバーライドについて話すでしょう。では、なぜそうしなければならないのでしょうか？これらの問題の一部を修正することを目的とした CSS フレンドリーなコントロールパッケージは、非セマンティックなマークアップを備えているだけで、ID の問題には対処していません。

これらのコントロールはビューとコントロールを非常に緊密にバインドしているため、Web フォームアプリですぐに MVC (3.5 実装ではなく抽象概念) を実装することは不可能です。従来の Web デザイナーには、以前は CSS と JS の別々のドメインであったものを実装するためにサーバー側のコードに関与する必要があるため、現在では参入障壁があります。私はこれらの人々に同情します。

私は、コントロールによって特定のプロファイルのアプリを非常に迅速に開発できるという Kiwi の指摘に強く同意します。また、何らかの理由で HTML を不快に感じるプログラマーがいること、さらには ASP.NET の他の部分がもたらす利点についても受け入れます。これらの制御が必要になるため、 5月価格に見合う価値があります。

しかし、私コントロールが失われることに憤りを感じています。コードビハインドでクラス、スタイル、スクリプトなどを扱うモデルは間違った後退だと感じています。さらに、テンプレート (このプラットフォーム用のマイクロフォーマットと xslt の実装) にはもっと良いモデルがあると感じています。ただし、コントロールをこれらに置き換えるのは簡単ではありません。

ASP.NET は LAMP や Rails の世界の関連技術から多くのことを学ぶことができると思いますが、それまでは可能な限り 3.5 MVC を使用したいと考えています。

(長くなってしまってごめんなさい </rant>)

簡単に言うと、ASP は決して使用しないでください。本当に正当な理由がない限り、標準 HTML コントロールのバージョンを使用しないでください。

ジュニア開発者は、ほとんどの ASP.NET 書籍でこれらのコントロールについて説明されているため、それらのコントロールの方が優れているに違いないと思い込み、それらのコントロールを使用することに夢中になることがよくあります。そうではありません。現時点で、8 年間毎日 ASP.NET 開発を行ってきましたが、実際に ASP を使用するのが理にかなっているケースは 2 ～ 3 つしか思いつきません。標準の HTML コントロールに対する INPUT コントロール。

サーバーコントロールの ID については、次のようになります。実際にブラウザに書き込まれる ID は、ClientID にアクセスすることで確認できます。そうすることで、サーバー側とクライアント側のスクリプトを組み合わせることができ、_id="ct100_nav"_ をハードコーディングする必要がなくなります。

私は常に HTML を「ハッキング」する代わりに、付属のコントロールを使用するようにしています。後で更新や改善があった場合でも、フレームワークを置き換えるだけですべてのコードが機能し、HTML を変更する必要がないからです。

お役に立てれば

@brian、うん！すべての動作をほぼ制御できます。カスタムコントロール (3 種類あります) の作成を検討してください。最近私の質問でそれらの概要を説明しましたここ.

私は...するだろう強くチェックアウトすることをお勧めします。私にとっては終わりのない助けになります:)

私も ASP.NET への冒険を続けていますが、同様の不満を感じたことがあります。ただし、すぐに慣れます。ただ覚えておく必要があるのは、 退屈な HTML 作成が必要ない理由は、ASP.NET コントロールがすべてを行ってくれるからです。.

コントロールを継承し、そこから HTML 出力を微調整する必要がある場合でも、これらをある程度制御/微調整することができます。

以前は、あちこちに追加のマークアップを追加することで、特定のコントロールがデフォルトで W3C 検証に合格しなかったため、必要に応じて単純にオーバーライドして編集する必要がありました (修正には文字通り数分かかりました)。

制御システムがどのように機能するかについて学ぶと思います。次に、自分でいくつか組み合わせてみます。これは、内部で何が起こっているのかを理解するのに非常に役立ちました。そのため、何か問題が発生した場合、どこに行けばよいのかがわかります。

HTML は、ID の衝突を防ぐ ASP.NET の方法により、この種の ID を使用してレンダリングされます。マスターページやウィザードコントロールなどの各コンテナコントロールは、子の ID の前に「ID_」を付加します。

箇条書きリストの場合、ListView は適切な中間点を提供します。データソースにバインドすることもできますが、レンダリングされた HTML をより厳密に制御できるようになります。Scott Gu が ListView についての素晴らしい紹介をここに載せています:

http://weblogs.asp.net/scottgu/archive/2007/08/10/the-asp-listview-control-part-1-building-a-product-listing-page-with-clean-css-ui。 aspx

ASP.NET によって追加された ID のプレフィックスが、後で JS などを使用してアクセスする際に問題になる場合は...サーバー側には .ClientID プロパティがあります。

ASP.NET によってオーバーヘッドが追加される場合は、出力される HTML を完全に制御できる ASP.NET MVC (まだプレビュー) を検討する必要があります。

追加されたものも気に入らないので、MVC に移行します。

ここでの回答のほとんどはデザイナーの観点からのものだと思います。小規模から中規模のプロジェクトでは、コードと CSS/HTML を同期し、標準に準拠したクリーンな状態にするのはオーバーヘッドのように思えるかもしれません。デザイナーがこれを行うには、レンダリングされた HTML を完全に制御する必要があります。ただし、ASP.NET でその完全な制御を行う方法はたくさんあります。そして私にとって、必要な HTML を aspx/ascx ファイルに含めるのは、最もスケーラビリティが低く、汚い方法です。CSS を通じてコントロールのスタイルを設定する場合は、いつでも CssClass プロパティを通じてサーバー側のクラスを設定できます。JS 経由でアクセスしたい場合は、正しい ID を持つ JS をサーバー側で再度発行できます。これによる唯一の欠点は、開発者とデザイナーが緊密に連携しなければならないことです。大規模なプロジェクトでは、これはいずれにせよ避けられません。しかし、ASP.NET が提供する利点は、これらの困難をはるかに上回ります。それでも、標準に準拠した HTML、スキニングのサポート、およびレンダリングされたマークアップを制御するためのその他の機能が必要な場合は、いつでもサードパーティコントロールを使用できます。

Dave Ward 氏がすでに述べたように、「これは ID の衝突を防ぐ ASP.NET の方法です」。

この好例としては、カスタムコントロール内にコントロールを配置し、そのカスタムコントロールをリピーター内で使用して、カスタムコントロールの HTML がページに対して複数回出力されるようにする場合です。

他の人が述べたように、JavaScript のコントロールにアクセスする必要がある場合は、ClientScriptManager へのアクセスを許可する ClientScript プロパティを使用し、この方法でスクリプトをページに登録します。スクリプトを作成するときは、コントロールの ID を単に入力するのではなく、参照しようとしているコントロールの ClientID プロパティを使用するようにしてください。

レンダリングされた HTML を細かく制御したい場合は、次のことを調べてください。 ASP.NET MVC その代わり。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow