检票口 + JavaScript

发布于 2024-07-06 19:09:47 字数 522 浏览 8 评论 0原文

我正在将 Javascript 小部件包装在 Wicket 组件中。我想让 JS 端与组件对话。到目前为止我所得到的：

一样

talker = new GridAjaxBehavior();
this.add(talker);

有问题的组件就像在构造函数中

，然后，稍后将类似的东西放入

"var MyGridTalker = new talker(" + this.talker.getCallbackUrl() + ");";

JS 中。

其中 GridAjaxBehavior 扩展了 AbstractDefaultAjaxBehavior。我希望 GridAjaxBehavior 在 JS 调用它时返回一些 XML。

我这样做的方式正确吗？ GridAjaxBehaviour 应该做什么来吐回 XML？

谢谢

原文

I'm wrapping up a Javascript widget in a Wicket component. I want to let the JS side talk to the component. What I've got so far:

Component in question goes like

talker = new GridAjaxBehavior();
this.add(talker);

in constructor

and then, later on, puts something like

"var MyGridTalker = new talker(" + this.talker.getCallbackUrl() + ");";

into the JS.

where GridAjaxBehavior extends AbstractDefaultAjaxBehavior. I want GridAjaxBehavior to spit back some XML when the JS calls it.

Am I doing this the right way? What should GridAjaxBehaviour do to spit back the XML?

Thanks

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

超可爱的懒熊 2024-07-13 19:09:47

吐回一些 XML 干什么？大概是为了更新模型或视图，是吗？

Wicket 的优势在于您不必担心呈现的 HTML。在模型-视图-控制器术语中，您设置控制器来正确修改模型，而 Wicket 则负责视图。

分离并不完全清楚：事实上，您可以显示/隐藏视图组件，或者然后进行更改，这可以被视为更改视图。

但您通常不必做的是直接管理浏览器或 javascript。如果您注意在 Java 代码中进行更改，Wicket 就会处理这个问题。

在 Wicket 中，Ajax 将使用 AjaxRequestTarget 目标调用 AjaxBehavior 上的方法。

在该方法中（或在从该方法调用的方法中），您可以执行所需的操作，更新模型或视图，然后将已更改的任何视图组件添加到目标。 Wicket 负责更新浏览器。

这是一个例子。它取自我所做的一些代码，但进行了大量修改只是为了使说明更清晰。这个想法很简单：“链式”下拉选择，当父级中的选择选项发生变化时，子级中的选项也会发生变化，如 [州] [县] [区] 系列。

（在实际的类中，模型更改被传递给子级，子级自行决定是否已更改，如果已更改，则将其自身添加到目标，然后将目标传递给其子级。我已将其中的大部分删除到举一个更清晰的例子。）

这是 ctor，它只是向自身添加了一个 AjaxBehavior 的匿名子类：

public AjaxChildNotifyingDropDownChoice(...code elided for clarity...) {
    this.child = child;

    // Ajax won't work without this:
    setOutputMarkupId(true);
    // 
    add( new OnChangeAjaxBehavior() {
        @Override
        public void onUpdate(final AjaxRequestTarget target) {

            // tell child to update its list
            // based on newly selected value

            // when the Ajax is called, 
            // my owning component's model
            // is already updated

            // note we could just type getModel()
            // I'm making explicit that we're calling it
            // on the enclosing class 
            // (which a non-static inner class has a hidden ref to) 
            child.setNewModelBasedOnSelectionOf( 
               AjaxChildNotifyingDropDownChoice.this.getModel());

            // now add the child to the target
            // Wicket javascript will receive the new 
            // options and re-render the child dropdown
            target.add(child);

        }
    });
}

我们还可以拥有隐藏或非隐藏的组件，或者添加 CSS 样式等行为，甚至将一个 Panel 替换为另一个 Panel。只要对于每个更改的组件我们：
1) 调用setOutputMarkupId(true); 这样 javascript 就可以找到它，并且
2) 将其添加到 AjaxRequestTarget

请注意，Ajax Behaviour 的不同类型（子类）具有不同的回调函数，因此请确保您覆盖了正确的回调函数（添加 @Override 注释，以便编译器可以在名称错误时抱怨）。

但同样，基本的 wicket 想法是，您不是发送原始数据供客户端解析和操作，而是更新您的模型和视图，并告诉 Wicket 重新渲染您更改的内容，方法是将更改的组件添加到目标。

我能想到直接发送 XML 的唯一原因是将其提供给非 Wicket javascript。让我知道这是否是你的目标，但我完全没有抓住重点。 ;)

Spit back some XML for what? Presumably to update the model or the view, yes?

The strength of Wicket is that you don't have to worry about the rendered HTML. In Model-View-Controller terms, you set up the Controller to correctly modify the Model, and Wicket takes care of the View.

The separation is not entirely clear: in fact you can show/hide view components, or change then, and that can be seen as altering the View.

But what you generally don't have to do is directly manage the browser or javascript. Wicket takes care of that, if you take care of making your changes in the Java code.

In Wicket, the Ajax will call a method on your AjaxBehavior with an AjaxRequestTarget target.

In that method (or in methods called from it), you do whatever you need to do, updating models or views, and then you add to the target any view component that that has changed. Wicket takes care of updating the browser.

Here's an example. It's taken from some code I did, but heavily altered just to make explication clearer. The idea is simple: "chained" dropdown choices, where the options in the child change when the select option in the parent changes, as in the series of [State] [County] [District].

(In the actual class, the Model change is passed to the child, which decides for itself if it has changed, and adds itself to the target if it has, then passes the target to its child. I've removed most of that to make a clearer example.)

Here's the ctor, which just adds to itself an anonymous subclass of an AjaxBehavior:

public AjaxChildNotifyingDropDownChoice(...code elided for clarity...) {
    this.child = child;

    // Ajax won't work without this:
    setOutputMarkupId(true);
    // 
    add( new OnChangeAjaxBehavior() {
        @Override
        public void onUpdate(final AjaxRequestTarget target) {

            // tell child to update its list
            // based on newly selected value

            // when the Ajax is called, 
            // my owning component's model
            // is already updated

            // note we could just type getModel()
            // I'm making explicit that we're calling it
            // on the enclosing class 
            // (which a non-static inner class has a hidden ref to) 
            child.setNewModelBasedOnSelectionOf( 
               AjaxChildNotifyingDropDownChoice.this.getModel());

            // now add the child to the target
            // Wicket javascript will receive the new 
            // options and re-render the child dropdown
            target.add(child);

        }
    });
}

We could also have hidden or un-hidden components, or added behaviors like CSS styles, or even swapped one Panel for another. As long as for each changed component we:
1) called setOutputMarkupId(true); so that the javascript can find it, and
2) added it to the AjaxRequestTarget

Note that different types (subclases) of Ajax Behavior have different callback functions, so be sure you're overriding the right one (add an @Override annotation so the compiler can complain if you got the name wrong).

But again, the basic wicket idea is that instead of sending raw data for the client to parse and act on, you update your model and view, and tell Wicket to re-render what you've changed, by adding the chnaged components to the target.

The only reason I can think of to send straight XML would to be to feed it to non-Wicket javascript. Let me know if that's your aim, and I completely missed the point. ;)

回复收藏 0 原文