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 <mgrigo...@apache.org>
> 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
>
