Roadmap for Wicket 6

classic Classic list List threaded Threaded
23 messages Options
12
Per
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for Wicket 6

Per
This post has NOT been accepted by the mailing list yet.

My only wish is #6 on Martin's list:

# Shorter release cycle

Whatever you guys come up with, I trust it to be super, and in the best interest of Wicket. But "shipping" is a nice feature too. Good luck with 6, and December or January would be great.

Per
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for Wicket 6

Attila Király
In reply to this post by Martin Grigorov-4
A few more ideas for Wicket 6:
- Use findbugs annotations in the api (like @Nonnull for arguments/return
values, an example library doing this is google guava). It is good for two
reasons: works like a documentation and findbugs can do some static code
analysis based on it. However it does not replace the current runtime checks
(like Args.*) it just helps a bit in the area.

- Hide wicket implementation details (like methods marked with "THIS IS A
WICKET INTERNAL API. DO NOT USE IT.") behind single entry points. For
example:
public class Component {
public class ComponentInternalApi {
public void doSomething() {
}

protected final void doSomethingElse() {
}
}

private final ComponentInternalApi internalApi = new ComponentInternalApi();

@Nonnull
public ComponentInternalApi internals() {
return internalApi;
}
}
This is a cosmetic change. The downside of this would be a slightly
increased memory footprint for wicket objects. The gain is a cleaner api.
This a bit similar to Martin's functionality grouping for WicketTester:
https://issues.apache.org/jira/browse/WICKET-3747.

Regards,
Attila

2011/8/31 Martin Grigorov <[hidden email]>

> On Wed, Aug 31, 2011 at 4:10 PM, Peter Ertl <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for Wicket 6

Igor Vaynberg-2
On Mon, Oct 24, 2011 at 11:23 AM, Attila Király
<[hidden email]> wrote:

> A few more ideas for Wicket 6:
> - Use findbugs annotations in the api (like @Nonnull for arguments/return
> values, an example library doing this is google guava). It is good for two
> reasons: works like a documentation and findbugs can do some static code
> analysis based on it. However it does not replace the current runtime checks
> (like Args.*) it just helps a bit in the area.
>
> - Hide wicket implementation details (like methods marked with "THIS IS A
> WICKET INTERNAL API. DO NOT USE IT.") behind single entry points. For
> example:
> public class Component {
> public class ComponentInternalApi {
> public void doSomething() {
> }
>
> protected final void doSomethingElse() {
> }
> }
>
> private final ComponentInternalApi internalApi = new ComponentInternalApi();
>
> @Nonnull
> public ComponentInternalApi internals() {
> return internalApi;
> }
> }
> This is a cosmetic change. The downside of this would be a slightly
> increased memory footprint for wicket objects. The gain is a cleaner api.
> This a bit similar to Martin's functionality grouping for WicketTester:
> https://issues.apache.org/jira/browse/WICKET-3747.

this will be a big memory overhead. its a new memory slot per
component instance which is 64 bits. i would rather do new
ComponentInternals(this).doSomething() like what we do with Behaviors.
or simply rename all internal methods with internal*

-igor


>
> Regards,
> Attila
>
> 2011/8/31 Martin Grigorov <[hidden email]>
>
>> On Wed, Aug 31, 2011 at 4:10 PM, Peter Ertl <[hidden email]> 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
>>
>
12