タグ付けされた質問 「nested」

このタグは、さまざまなネストされたエンティティまたはプログラミングの操作に関連しています。

25
ネストされたオブジェクト、配列、JSONにアクセスして処理するにはどうすればよいですか?
オブジェクトと配列を含むネストされたデータ構造があります。どのようにして情報を抽出できますか、つまり特定または複数の値(またはキー)にアクセスできますか? 例えば: var data = { code: 42, items: [{ id: 1, name: 'foo' }, { id: 2, name: 'bar' }] }; でname2番目の項目のにアクセスするにはどうすればよいitemsですか?

30
ネストされたJavaScriptオブジェクトキーの存在をテストする
オブジェクトへの参照がある場合: var test = {}; それは潜在的に(しかしすぐにはではなく)ネストされたオブジェクトを持つでしょう: {level1: {level2: {level3: "level3"}}}; 深くネストされたオブジェクトのプロパティの存在を確認する最良の方法は何ですか? alert(test.level1);は生成されますundefinedが、alert(test.level1.level2.level3);失敗します。 私は現在次のようなことをしています: if(test.level1 && test.level1.level2 && test.level1.level2.level3) { alert(test.level1.level2.level3); } しかし、もっと良い方法があるかと思っていました。


14
子要素のマージンは親要素を移動します
私が持っているdiv(親別含まれている)div(子)。親は、body特定のCSSスタイルがない最初の要素です。設定すると .child { margin-top: 10px; } 最終結果は私の子供の上部がまだ親と揃っているということです。子が10ピクセル下にシフトされる代わりに、私の親は10ピクセル下に移動します。 私DOCTYPEはに設定されていXHTML Transitionalます。 ここで何が欠けていますか? edit 1 私の親には背景が上から下に(ピクセル完全)表示される必要があるため、厳密に定義された寸法が必要です。したがって、垂直マージンを設定することはできません。 編集2 この動作は、FF、IE、およびCRで同じです。
415 css  xhtml  margin  nested 

2
SQL Serverのネストされたselectステートメント
次の方法でうまくいかないのはなぜですか? SELECT name FROM (SELECT name FROM agentinformation) SQLについての私の理解は間違っていると思います。これは、 SELECT name FROM agentinformation 内側のSELECTステートメントは、外側のSELECTステートメントがクエリする結果セットを作成しませんか?

24
ドット「。」の使い方 辞書のメンバーにアクセスするには?
ドット「。」を介してPython辞書のメンバーにアクセスできるようにするにはどうすればよいですか? たとえば、書く代わりに mydict['val']たいと思いますmydict.val。 また、この方法でネストされた辞書にアクセスしたいと思います。例えば mydict.mydict2.val 参照するだろう mydict = { 'mydict2': { 'val': ... } }

7
反応ルーターv4 / v5のネストされたルート
現在、react router v4を使用してルートをネストするのに苦労しています。 最も近い例は、React-Router v4 Documentationのルート設定 です。 アプリを2つの部分に分割したい。 フロントエンドと管理領域。 私はこのようなことを考えていました: <Match pattern="/" component={Frontpage}> <Match pattern="/home" component={HomePage} /> <Match pattern="/about" component={AboutPage} /> </Match> <Match pattern="/admin" component={Backend}> <Match pattern="/home" component={Dashboard} /> <Match pattern="/users" component={UserPage} /> </Match> <Miss component={NotFoundPage} /> フロントエンドのレイアウトとスタイルは、管理領域とは異なります。したがって、フロントページ内のルートホーム、つまり1つは子ルートである必要があります。 / homeはフロントページコンポーネントにレンダリングされ、/ admin / homeはバックエンドコンポーネント内にレンダリングされます。 私はいくつかのバリエーションを試しましたが、常に/ homeまたは/ admin / homeを打たないことに終わりました。 編集-19.04.2017 この投稿には現在多くの意見があるため、最終的なソリューションで更新しました。誰かのお役に立てば幸いです。 …

12
ネストされたリストの理解をリスト化しますか?
私はこのネストされたリストを持っています: l = [['40', '20', '10', '30'], ['20', '20', '20', '20', '20', '30', '20'], ['30', '20', '30', '50', '10', '30', '20', '20', '20'], ['100', '100'], ['100', '100', '100', '100', '100'], ['100', '100', '100', '100']] 次に、リストの各要素を浮動小数点に変換します。私の解決策はこれです: newList = [] for x in l: for y in x: newList.append(float(y)) しかし、これはネストされたリスト内包表記を使用して行うことができますか? 私がやったことは: [float(y) …

3
ネストされたオブジェクトをクエリする方法は?
ネストされたオブジェクト表記でmongoDBをクエリするときに問題があります。 db.messages.find( { headers : { From: "reservations@marriott.com" } } ).count() 0 db.messages.find( { 'headers.From': "reservations@marriott.com" } ).count() 5 何が悪いのか分かりません。ネストされたオブジェクト表記がドット表記クエリと同じ結果を返すことを期待しています。どこが間違っているのですか?

16
HTMLフォームのネスト制限をどのように克服しますか?
XHTMLはネストされたフォームタグをサポートしていないことを知っており、この件に関してStack Overflowで他の回答をすでに読んでいますが、問題に対するエレガントな解決策はまだわかりません。 一部の人は、あなたはそれを必要とせず、これが必要とされるシナリオを考えることができないと言います。まあ、個人的には必要のないシナリオは思いつきません。 非常に簡単な例を見てみましょう: あなたはブログアプリを作成していて、新しい投稿を作成するためのいくつかのフィールドと、「保存」、「削除」、「キャンセル」などの「アクション」を備えたツールバーを持つフォームがあります。 <form action="/post/dispatch/too_bad_the_action_url_is_in_the_form_tag_even_though_conceptually_every_submit_button_inside_it_may_need_to_post_to_a_diffent_distinct_url" method="post"> <input type="text" name="foo" /> <!-- several of those here --> <div id="toolbar"> <input type="submit" name="save" value="Save" /> <input type="submit" name="delete" value="Delete" /> <a href="/home/index">Cancel</a> </div> </form> 私たちの目的は、JavaScriptを必要としない方法でフォームを記述することです。単純な古いHTMLフォームと送信ボタンだけです。 アクションURLは、個々の送信ボタンではなくFormタグで定義されているため、唯一のオプションは、汎用URLに投稿し、「if ... then ... else」を開始して、ボタンの名前を決定することです。提出されました。あまりエレガントではありませんが、JavaScriptに依存したくないため、唯一の選択肢です。 唯一の問題は、「削除」を押すと、このアクションに必要なのはpost-idの非表示入力だけであるにもかかわらず、サーバー上のすべてのフォームフィールドが送信されることです。この小さな例ではそれほど重要ではありませんが、私のLOBアプリケーションには何百もの(いわば)フィールドとタブがあり、(要件のため)一度にすべてを送信する必要があり、いずれにしてもこれは非常に非効率的ですそして廃棄物。フォームのネストがサポートされている場合、少なくとも「削除」送信ボタンを、フォームの内部にpost-idフィールドのみでラップできます。 「送信ではなく、リンクとして「削除」を実装するだけ」と言うことができます。これは多くのレベルで間違っていますが、最も重要なのは、ここでの「削除」のような副作用アクションは決してGETリクエストであってはならないためです。 だから私の質問(特に、フォームの入れ子は必要ないと言っている人たちへの質問)は、あなたは何をしますか?私が見逃しているエレガントな解決策はありますか、それとも最終的には「JavaScriptが必要か、すべてを送信するか」です。
199 html  forms  nested 

7
C ++でのネストされた型/クラスの前方宣言
最近、次のような状況で行き詰まりました。 class A { public: typedef struct/class {...} B; ... C::D *someField; } class C { public: typedef struct/class {...} D; ... A::B *someField; } 通常、クラス名を宣言できます。 class A; ただし、ネストされた型を転送宣言することはできません。次の場合はコンパイルエラーが発生します。 class C::D; 何か案は?

4
C ++でネストされたクラスを使用するのはなぜですか?
誰かがネストされたクラスを理解して使用するためのいくつかの素晴らしいリソースに私を向けることができますか?プログラミング原則のような資料や、このIBM Knowledge Center-Nested Classesなどの資料があります。 しかし、私はまだ彼らの目的を理解するのに苦労しています。誰かが私を助けてくれませんか?

9
SQL Serverで入れ子になったcaseステートメントロジックを実行する最良の方法
SQLクエリを作成しています。返される列のいくつかは、かなり多くの条件に応じて計算する必要があります。 現在、ネストされたcaseステートメントを使用していますが、面倒です。より良い(より整理された、そして/または読みやすい)方法はありますか? (Microsoft SQL Server、2005を使用しています) 簡単な例: SELECT col1, col2, col3, CASE WHEN condition THEN CASE WHEN condition1 THEN CASE WHEN condition2 THEN calculation1 ELSE calculation2 END ELSE CASE WHEN condition2 THEN calculation3 ELSE calculation4 END END ELSE CASE WHEN condition1 THEN CASE WHEN condition2 THEN calculation5 ELSE calculation6 END ELSE …


6
Pythonの複数レベルの「collection.defaultdict」
SOの優れた人々のおかげで、私はcollections.defaultdict、特に可読性とスピードの可能性を発見しました。私はそれらを成功させて使用しました。 ここで、3つのレベルの辞書を実装したいと思います。上位2つの辞書defaultdictと下位の辞書intです。これを行う適切な方法が見つかりません。これが私の試みです: from collections import defaultdict d = defaultdict(defaultdict) a = [("key1", {"a1":22, "a2":33}), ("key2", {"a1":32, "a2":55}), ("key3", {"a1":43, "a2":44})] for i in a: d[i[0]] = i[1] これで機能しますが、望ましい動作である以下は機能しません。 d["key4"]["a1"] + 1 私はどこかで2番目のレベルdefaultdictがtype intであることを宣言するべきだったのではないかと思いますが、どこでどのように行うのかわかりませんでした。 私がdefaultdict最初に使用している理由は、新しいキーごとに辞書を初期化する必要がないようにするためです。 よりエレガントな提案はありますか? pythoneersに感謝!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.