0

OK、それではまず、Lift フォームをバインドする bind( ... ) の方法が先週のものであることを認めるところから始めましょう。:) 私はそれを知っています、そして私はまだこのコードを更新するために戻っていません. また、これを行うための非常に洗練された Lifty の方法があると信じています。それが私が求めるものです。何かを一緒にハックする方法でさえ、私は困惑しています。それは言った...

最初に編集不可で表示する項目のリストがあり、各項目のタイトルは ajax 対応のリンクであり、サーバーを呼び出し、その項目を編集可能な形式の項目に置き換えます (私は SetHtml を使用して交換します)。その項目をリストした < li> のフォーム)。「親」アイテムリストビューは次のようになります

< form data-lift="form.ajax">
< div data-lift="creategamewizard?multipart=true" id="wizardform">
< ul>
< li>項目 1</li>
< li>項目 2</ / li>
< /ul>
その他のフォーム要素
< button>送信</button>
< input type="hidden" id='298356928734' />
< /div>
< form>

この ajax 送信 (隠しフィールド経由) は、processSubmit() を呼び出します。

editableItem フォームでスワップする SetHtml は次のようになります。
注: 次のリストの最後では、「親」送信ボタンが既にページにあるため、「保存」バインディングにはサーバー側のコードが関連付けられていません。このバインディングに別の非表示フィールドを配置したり、任意のコードを Edit Item Save ボタンに直接結びつけると、そのコードと「親」送信がトリガーされます。したがって、以下のアプローチは、親の送信とアイテムの編集の送信の両方に「親」の送信を使用しようとすることでした。

<a href="javascript://" onclick={ajaxOnClickHandler(editItemClickHandler(item.id.get))}>{item.title.get}</a>

def ajaxOnClickHandler(jsHandler: ()=>JsCmd) =
{
    SHtml.onEvent( e => jsHandler()).toJsCmd+";return false;"
}
def editItemClickHandler(itemId: String): ()=>JsCmd = ()=>
{
    trace.logAjaxComm("ExistingItem.Edit()")
    JsCmds.SetHtml("LiId"+itemId, getEditableItem(promo) )
}
def getEditableItem(itemId) =
{
    bind( ...
        "promotitle" -> SHtml.text(editablePromo.get.promotitle.is,
        (s:String) => {
            trace.logUIDataManipulation("Saving new promo Title["+s+"]");
            editablePromo.get.promotitle(s)
        }, "id" -> "promotitle"),
        "save" -> SHtml.button("Save", ()=> {})
    )
}

次に、ユーザーが項目を選択し、編集可能な項目フォームがプラグインされると、その項目のフォーム データを ajax 送信し、(現在更新されている) 非編集可能バージョンのデータに戻す「別の」送信ボタンがあります。

私にとっての問題は提出です。上記の [アイテムの編集] フォームに加えて、編集不可の「親」リスト ページに、リストの下のいくつかのフィールドの送信を処理する ajax 化された送信ボタンがあります。Edit Item "save"-> バインディングはボタンを追加します。ボタン自体は何もしないはずですが (実際には何もしません)、「Parent」送信ボタンをトリガーします。そして、その送信をルーティングして、[アイテムの編集] フォームを保存します。

編集不可のアイテムと編集可能なアイテムのコードは正常に交換されますが、編集可能なアイテムのフォームで行われた変更は保存されません。編集可能なアイテムのフォームの要素がまったく送信されていないために、それが起こっていることがわかりました。まったく表示されないログメッセージの例...

bind( ... "promotitle" -> SHtml.text(editablePromo.get.promotitle.is,
    (s:String) => {
        trace.logUIDataManipulation("Saving new promo Title["+s+"]");
        editablePromo.get.promotitle(s)
    }, "id" -> "promotitle")
)

通常の ajax 化されたフォームでは、すべての要素ハンドラーがレンダリングの順序で呼び出され (フィールドに変更があった場合、おそらく...)、submit/hidden 要素のハンドラーが最後に呼び出されます (それらが最後にある場合)。バインド リスト。

最後に、私の質問に取り掛かりましょう: このようなインプレース編集を行っている場合、2 つの送信ボタン (編集不可のリスト ページ用のボタンと、アイテムの編集時に追加される追加のボタン) を管理するにはどうすればよいですか? )? ページを更新する必要はないと確信していますが、Ajax でこれを行う方法がわかりません。または、代わりに、インプレース編集可能なフォームを送信しない ajax アクションとして送信することもできます。どういうわけか、親の送信をトリガーしませんか?

4

1 に答える 1

0

この質問につまずいた人のために、最終的に見つけた解決策を共有すると思いました...

1)問題は、編集可能なアイテムのフィールドハンドラーが呼び出される前に送信 (AJAX の場合、これは非表示の html タグ) が発生したことでした。そのため、編集可能なアイテムを非編集可能なリスト アイテムに戻す AJAX の更新時に、データはまだ更新されていませんでした。そのため、編集不可能な形式で表示されたものには更新が表示されませんでしたが、ブラウザでページを更新すると、更新がデータベースに保存され、適切に表示されました。

2)理由順序が間違っているのは、Lift が各フォーム タグのサーバー側ハンドラーに ID を割り当てることです (これは、末尾に追加の文字列が追加されて「単調増加」します)。フォームの ajax live-update を実行してフィールドを追加するまでは問題ありません (編集可能な項目フィールドを挿入したときに行ったように)。これらの新しく追加されたフィールドには、最初のページ レンダリングの一部として生成された隠しフィールドの後に来るサーバー側 ID が割り当てられました。

3)解決策は、S.formGroup を使用して隠しフィールドをより高い ID に明示的に押し込むことでした。詳細はこちらをご覧ください...

以下の最後のリンクの例は次のとおりです（私はSHtml.hiddenを使用しているのに対し、SHtml.submitを使用しているという点で私のものとは異なります）。送信ボタンのサーバー側ハンドラー ID に定数 1,000 を追加します。

"type=submit" #> S.formGroup(1000) { SHtml.submit("Submit", プロセス) }

私と本質的に同じ問題の議論: https://groups.google.com/forum/#!topic/liftweb/MYJQeVlOYFM
「サーバー側関数の順序」という見出しの下の ID 割り当てと S.formGroup の説明: https ://www.assembla.com/spaces/liftweb/wiki/cool_tips
そして最後に、最後のリンクからリンクされているのは、いくつかのサンプルコードです: https://groups.google.com/forum/#!topic/liftweb/E9z7PVhogQw

于 2014-03-17T17:56:34.687 に答える