> >> 2. AJAX components (Wicket vs. ZK)
> >you do not implement features like drag and drop or datepicker in wicket,
> >instead you wrap javascript libraries that implement those features with
> >wicket components.
>
> I am actually confused at how many ways Wicket supports AJAX. The classes in
> wicket.ajax packages are used for AJAX behaviors. I supposed these classes
> are for common AJAX behaviors. It seems they are different from wrapping
> JavaScript - correct me if I am wrong. Then my questions are
> 1) what is the standard way to add AJAX with Wicket: first looking for
> existing components (including the components in WicketStuff), then if not
> found, wrap JavaScript?
> 2) I read the attached file and googled more for the instruction on how to
> wrap JavaScript. Found one here
> (http://cwiki.apache.org/WICKET/adding-dynamic-field-prompts-or-hints.html).
> I am wondering if there are instructions on how to do it in a general way.
It really depends on how the JavaScript/ Ajax library you want to use works.
Often, you need to load some general dependencies in the header, and
then do some initialization that connects DOM elements (i.e. some of
the tags that are connected to Wicket components) to with functions in
that library. When you're not creating reusable components and
multiple pages, this is fairly straightforward as you can then put JS
includes and initialization code straight in the header section of
your pages. When you create reusable components however, you need to
give this a little bit more thought, and work through
IHeaderContributor by either components/ behaviors that implement this
interface (like most behaviors do) and implementing/ overriding
renderHead, or use the HeaderContributor utility class.
For Ajax components/ behaviors you need a way to communicate partial
requests. For behaviors - in general the best way to implement Ajax -,
there is IBehaviorListener. It's really up to you how to implement
this. Wicket and wicket-extensions ship with a range of convenient
ajax behaviors and utility classes and a Wicket specific Ajax
JavaScript library. But on top of that, there are projects in
Wicket-stuff that use Dojo and Scriptaculous for instance that provide
an Ajax implementation from scratch. It's really up to you to decide
which approach you like best. If it they don't have the components you
need: build them yourself :) It's one of Wicket's strength that this
is relatively easy to do, and if you're up to it, you can contribute
back for the next one who is looking to for a similar solution.
Btw, it's also a topic that we write a whole chapter about in Wicket
In Action - though that chapter won't be available for a month or so
as we're revising it - so if you sign up for MEAP (nope, it's not
free) you can help use make that chapter perfect by giving us feedback
when it is available :)
> >>3. Target application (Wicket)
> > like you say, wicket is component oriented. it doesnt really care how you
> > build your app: many pages or a single page. at my day time job we have an
> > app that is mostly a single page with a lot of component replacement.
> > works
> > just fine.
>
> Still not sure, if a page includes many replacement, how to keep the
> method/class short yet support those changes?
What you do, is code your page for a certain starting position, and
then when the user navigates, start replacing sections. You wouldn't
typically code that in one page.
For instance, as a very simple example, this:
public MyPage(PageParameters params) {
add(new UserListPanel("content")) {
public void onSelectUser(AjaxRequest ajaxRequest, User user) {
Panel p = new UserDetailsPanel("content");
replaceWith(p); // replace user list panel with details panel
ajaxRequestTarget.addComponent(p); // tell ajax engine to render on client
}
};
}
uses component replacement. Starts with displaying a list, and then
replaces the list with the details. And the details can replace
itself, it's children or even parents itself as well.
It wouldn't be too worried about whether you follow a strictly single-
or multi page 'paradigm' though. Mixed probably often works best.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
