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 >