On Mon, Oct 24, 2011 at 11:23 AM, Attila Király
<kiralyattila...@gmail.com> 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 <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
>>
>
