On Wed, Aug 31, 2011 at 4:10 PM, Peter Ertl <pe...@gmx.org> wrote:
> 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)
> + "');");
> }
> })
I use templates for this (PackageTextTemplate and Co.). Works like a charm.
>
>
>
> 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
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
