Ok, so since this is brainstorming time I can probably ask for cool features
without getting punished :-)
- partial ajax updates on repeaters (insert/modify/delete)
- some kind of intuitive support from wicket to synchronize access to session
or page data when processing multiple, concurrent ajax requests
- easier interaction between javascript and page with less magic. Especially I
would love to have stable urls for ajax callbacks that are relative to the page.
[disclaimer] consider the following example just non-functional(!) pseudo(!)
code to get the idea what I mean... no idea if this could possibly work ...
please excuse if this is complete b**s** :-)
EXAMPLE....
public class CheckoutPage extends WebPage
{
private OrderLineItems items;
private PaymentMethod payment;
public CheckoutPage()
{
mountPageResponder("order/items", new PageResponder()
{
@Override
public void onGet(Request request, Response response)
{
// convert order line items into json
// send json to client
}
});
mountPageResponder("payment/change", new PageResponder()
{
@Override
public void onPost(Request request, Response response)
{
// move : request.getParameter("method") ->
this.payment
}
});
}
}
So gettting the shopping items from within javascript in the checkout page with
jQuery would simply be
$.get("order/items", function(data) {
// process order line item data and refresh markup
})
Change the payment method to master card:
$.ajax({ type: 'POST', url: "payment/change", data: { method: 'master-card'
}, success: updatePaymentInfoCallback, error: showError )
(please excuse possibly errors in the above javascript)
so no need for stuff like this:
add(new Behavior()
{
@Override
public void renderHead(Component component,
IHeaderResponse response)
{
response.renderOnLoadJavaScript("initCheckoutScript('" + urlFor(someListener) +
"');");
}
})
Cheers
Peter
Am 31.08.2011 um 14:26 schrieb Korbinian Bachl - privat:
> My wish list:
>
> 1. Java 6
>
> 2. JEE6 where possible like e.g. CDI;
>
> 3. Modularization using OSGI
>
> 4. AJAX overhaul: currently Ajax is a pain in case it gets more complicated
> as one
> -> needs to add components to target AND page hierarchy;
> -> needs to do .setOutput****Id(true) all over
> -> can't touch "invisible" containers in e.g.: DataTable
>
> 5. look at side-efforts done by matej, igor and co to bring the nice things
> to wicket and enhance/ or replace the affected counterparts of wicket (e.g.:
> DataTable vs. InMethod Grid; bindgen-wicket etc.)
>
> 6. Not 100% sure: let the HTML templates feed via a single place so one can
> switch to e.g. a JCR implementation - however, I dont know how this could
> work in conjunction with added jars etc. to path. Idea is to allow the
> templates to live outside the java part (e.g.: CMS);
>
> 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't
> use SSL, no "may use SSL");
>
>
>
> Am 30.08.11 00:12, schrieb Martijn Dashorst:
>> In order to start discussing what will constitute Wicket Next and
>> where we want to take our beloved framework, I'll start off with my
>> wish list:
>>
>> 1. Java 6 as a minimum requirement for *all* of wicket
>> 2. Servlet API 3.0 as a minimum requirement
>> 3. JavaEE 6 support for at least CDI
>> 4. Proper OSGi support
>> 5. Ajax refactoring to use JQuery and provide proper JQuery integration in
>> core
>> 6. Shorter release cycle
>>
>> I +1000 #1 in my wish list, since then I'll be able to build releases again.
>>
>> Regarding #6 I aim to release Wicket 6 final in December.
>>
>> Martijn
