You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2012/07/17 11:08:41 UTC

Apache Wicket 6.0.0-beta3 is released

The Wicket team is proud to announce the third beta release of
the Wicket 6.x series. This release is an intermediary release
just before we give you 6.0.0 final.

There are no more planned API breaks but if you find something
that can be made better now it the time to discuss it! The
next planned release is 6.0.0 final, so speak now or forever
be silenced (or learn to live with it until 7.0.0 comes out).

Any feedback about the new features, their implementation and
their documentation is very welcome!

New and Noteworthy in 6.0.0-beta3
=================================

** NOTA BENE: ** the use of modules that are marked experimental,
by being part of the sub module 'wicket-experimental', are really
that: experimental. These modules can change, disappear or blow up
your computer without notice and you really use/depend on them at
your own risk.

Wicket Native Websockets
------------------------

A new **experimental** module has been added to Wicket 6 - Wicket
Native WebSocket. This module adds support for using HTML5
WebSockets as you may use Ajax in your Wicket applications.

All you have to do is to add a WebSocketBehavior to your page and from
there on you can receive messages from the clients and push messages
back to them.

At https://cwiki.apache.org/confluence/x/0vSoAQ you may find the
documentation and a link to a demo application.

If something is not clear feel free to ask your question in the
mailing lists and we will improve the documentation.

Wicket Bootstrap
----------------

The **experimental** modules now contain a new module for integration
with Twitter's Bootstrap. Currently this module only provides a
central way of using the Bootstrap resources. In the future we
will provide proper components and behaviors for the Bootstrap
concepts.

To use this new **experimental** module, add this to your pom:

    <dependency>
        <groupId>org.apache.wicket</groupId>
        <artifactId>wicket-bootstrap</artifactId>
        <version>0.1</version>
    </dependency>

To add Bootstrap support to your pages, add this in the `renderHead`
method:

    @Override
    public void renderHead(IHeaderResponse response) {
        super.renderHead(response);

        Bootstrap.renderHead(response);
    }

This will render a dependency to the Twitter bootstrap CSS and JS files,
including the required dependency to JQuery.

New Wicket Examples
-------------------
We have started an effort to revamp the tried and tested Wicket Examples
and bring them into 2012. The new examples are located in the
**experimental** module.

It is currently a copy of Twitter Bootstrap's design but with Wicket
specific filling.

You can test the examples by running the

    wicket-examples-jar/src/test/java/Start.java

class in the default package.

The examples will feature a component reference with typical use
cases, full examples such as Hello, World, and descriptions of the
code in play.

Wicket Atmosphere
-----------------

Wicket Atmosphere in the experimental modules has seen an upgrade of
the Atmosphere dependency to 1.0.0-beta3. This has caused an
incompatibility with Jetty 7.6.3 (used with Wicket and the examples). To
mitigate this, you need to override either:

 - the dependency on Jetty to 8.1.3 or newer, or
 - the dependency on Atmosphere to 0.9.5 (0.9.6 and 0.9.7 are broken as
   well)

See https://issues.apache.org/jira/browse/WICKET-4656 for more
information regarding this issue.

This release
============

 * Check the roadmap  with a list of the major
   goals: https://cwiki.apache.org/WICKET/wicket-60-roadmap.html

 * And the migration guide with all major and some minor changes
   between 1.5.x and 6.x series: http://s.apache.org/wicket-6.0-migration

 * The Jira changelog of all closed ticket at
   Jira: http://s.apache.org/wicket-6.0.0-beta3-changelog

To use it in Maven:

    <dependency>
        <groupId>org.apache.wicket</groupId>
        <artifactId>wicket-core</artifactId>
        <version>6.0.0-beta3</version>
    </dependency>

If you don’t use a dependencies management build tool then you
can download the full distribution (including source) and build from
source yourself.

Have fun,

The Wicket team!

---------------------------------------------------------------------
To unsubscribe, e-mail: announce-unsubscribe@wicket.apache.org
For additional commands, e-mail: announce-help@wicket.apache.org


Re: Apache Wicket 6.0.0-beta3 is released

Posted by Thomas Matthijs <li...@selckin.be>.
On Wed, Jul 18, 2012 at 8:39 PM, Douglas Ferguson <th...@gmail.com> wrote:
> How long should it take for this to appear in maven central?
>
> I currently don't see it there...
>
> http://mvnrepository.com/artifact/org.apache.wicket/wicket-core
>


http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.wicket%22%20AND%20v%3A%226.0.0-beta3%22

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Apache Wicket 6.0.0-beta3 is released

Posted by Douglas Ferguson <th...@gmail.com>.
How long should it take for this to appear in maven central?

I currently don't see it there...

http://mvnrepository.com/artifact/org.apache.wicket/wicket-core


On Jul 17, 2012, at 4:08 AM, Martijn Dashorst wrote:

> The Wicket team is proud to announce the third beta release of
> the Wicket 6.x series. This release is an intermediary release
> just before we give you 6.0.0 final.
> 
> There are no more planned API breaks but if you find something
> that can be made better now it the time to discuss it! The
> next planned release is 6.0.0 final, so speak now or forever
> be silenced (or learn to live with it until 7.0.0 comes out).
> 
> Any feedback about the new features, their implementation and
> their documentation is very welcome!
> 
> New and Noteworthy in 6.0.0-beta3
> =================================
> 
> ** NOTA BENE: ** the use of modules that are marked experimental,
> by being part of the sub module 'wicket-experimental', are really
> that: experimental. These modules can change, disappear or blow up
> your computer without notice and you really use/depend on them at
> your own risk.
> 
> Wicket Native Websockets
> ------------------------
> 
> A new **experimental** module has been added to Wicket 6 - Wicket
> Native WebSocket. This module adds support for using HTML5
> WebSockets as you may use Ajax in your Wicket applications.
> 
> All you have to do is to add a WebSocketBehavior to your page and from
> there on you can receive messages from the clients and push messages
> back to them.
> 
> At https://cwiki.apache.org/confluence/x/0vSoAQ you may find the
> documentation and a link to a demo application.
> 
> If something is not clear feel free to ask your question in the
> mailing lists and we will improve the documentation.
> 
> Wicket Bootstrap
> ----------------
> 
> The **experimental** modules now contain a new module for integration
> with Twitter's Bootstrap. Currently this module only provides a
> central way of using the Bootstrap resources. In the future we
> will provide proper components and behaviors for the Bootstrap
> concepts.
> 
> To use this new **experimental** module, add this to your pom:
> 
>    <dependency>
>        <groupId>org.apache.wicket</groupId>
>        <artifactId>wicket-bootstrap</artifactId>
>        <version>0.1</version>
>    </dependency>
> 
> To add Bootstrap support to your pages, add this in the `renderHead`
> method:
> 
>    @Override
>    public void renderHead(IHeaderResponse response) {
>        super.renderHead(response);
> 
>        Bootstrap.renderHead(response);
>    }
> 
> This will render a dependency to the Twitter bootstrap CSS and JS files,
> including the required dependency to JQuery.
> 
> New Wicket Examples
> -------------------
> We have started an effort to revamp the tried and tested Wicket Examples
> and bring them into 2012. The new examples are located in the
> **experimental** module.
> 
> It is currently a copy of Twitter Bootstrap's design but with Wicket
> specific filling.
> 
> You can test the examples by running the
> 
>    wicket-examples-jar/src/test/java/Start.java
> 
> class in the default package.
> 
> The examples will feature a component reference with typical use
> cases, full examples such as Hello, World, and descriptions of the
> code in play.
> 
> Wicket Atmosphere
> -----------------
> 
> Wicket Atmosphere in the experimental modules has seen an upgrade of
> the Atmosphere dependency to 1.0.0-beta3. This has caused an
> incompatibility with Jetty 7.6.3 (used with Wicket and the examples). To
> mitigate this, you need to override either:
> 
> - the dependency on Jetty to 8.1.3 or newer, or
> - the dependency on Atmosphere to 0.9.5 (0.9.6 and 0.9.7 are broken as
>   well)
> 
> See https://issues.apache.org/jira/browse/WICKET-4656 for more
> information regarding this issue.
> 
> This release
> ============
> 
> * Check the roadmap  with a list of the major
>   goals: https://cwiki.apache.org/WICKET/wicket-60-roadmap.html
> 
> * And the migration guide with all major and some minor changes
>   between 1.5.x and 6.x series: http://s.apache.org/wicket-6.0-migration
> 
> * The Jira changelog of all closed ticket at
>   Jira: http://s.apache.org/wicket-6.0.0-beta3-changelog
> 
> To use it in Maven:
> 
>    <dependency>
>        <groupId>org.apache.wicket</groupId>
>        <artifactId>wicket-core</artifactId>
>        <version>6.0.0-beta3</version>
>    </dependency>
> 
> If you don’t use a dependencies management build tool then you
> can download the full distribution (including source) and build from
> source yourself.
> 
> Have fun,
> 
> The Wicket team!
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Apache Wicket 6.0.0-beta3 is released

Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
p.s. I hope I sent this to the right list! Thunderbird used dev@ as the 
reply-to address.

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jul 25, 2012 at 6:18 PM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
> Ok, so if I understood properly:
>
> 1) To use a different backing lib, IJavaScriptLibrarySettings's
> setWicketEventReference(), setWicketAjaxReference() and
> setWicketAjaxDebugReference() methods should be used.

Yes. See org.apache.wicket.resource.CoreLibrariesContributor#contributeAjax()

>
> 2) If I have a subclass of AbstractDefaultAjaxBehavior which depends on
> jQuery, I must still add that dependency in order to "protect" my code from
> changes in the backing library.

Adding explicitly this dependency wont hurt. Wicket will filter the
duplicates, so just one jquery.js will be rendered.

>
> 3) A subclass of JQueryPluginResourceReference will always have a jQuery
> dependency no matter what the backing library is.

Yes, unless you put something else in IJSLSessings#setJQueryReference() ...

>
>
>> Blame Emond for that. He changed it and he didn't change the docs in the
>> Wiki...
>
> Ok but I wasn't really looking for someone to blame, but just to contribute
> to the beta testing! :)

OK, I blame him then :-)

Thanks for reading the docs and for updating them!

>
> Thanks for the explanation!



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Ok, so if I understood properly:

1) To use a different backing lib, IJavaScriptLibrarySettings's 
setWicketEventReference(), setWicketAjaxReference() and 
setWicketAjaxDebugReference() methods should be used.

2) If I have a subclass of AbstractDefaultAjaxBehavior which depends on 
jQuery, I must still add that dependency in order to "protect" my code 
from changes in the backing library.

3) A subclass of JQueryPluginResourceReference will always have a jQuery 
dependency no matter what the backing library is.

> Blame Emond for that. He changed it and he didn't change the docs in the Wiki...
Ok but I wasn't really looking for someone to blame, but just to 
contribute to the beta testing! :)

Thanks for the explanation!

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jul 25, 2012 at 5:47 PM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
>
>>> -There are references to
>>> IJavaScriptLibrarySettings#setBackingLibraryReference which does not
>>> exist
>>> anymore. Is it still possible to change the backing library? I personally
>>> don't want to, but the disparity between the doc and the code confused
>>> me.
>>
>> Fixed!
>> org.apache.wicket.settings.IJavaScriptLibrarySettings#setJQueryReference
>>
>
> Maybe I don't understand it properly, but the possibility of changing the
> Wicket's backing library does not seem consistent. The names of the classes
> and methods for this functionality are one source of confusion. In the first
> versions of this code, the term "BackingLibrary" was used all over the place
> but it is now replaced by "JQuery".

Blame Emond for that. He changed it and he didn't change the docs in the Wiki...

> For me, it is confusing that
> Application.get().getJavaScriptLibrarySettings().getJQueryReference() could
> return a reference to something which is not jQuery at all (e.g. DOJO).

It wont. It will return jQuery - one version or another.
If you use Dojo then you will need WicketDojoAjaxReference which will
depend on DojoAjaxReference (DAR), but DAR should not be registered in
IJSLibrarySettings at all.

>
> Consider a subclass of JQueryPluginResourceReference whose javadoc states :
>  * Base class for JavaScript resources that are JQuery plugins. This class
> already defines a
>  * dependency on JQuery.
> In its getDependencies() method, it looks up
> Application.get().getJavaScriptLibrarySettings().getJQueryReference() which
> can actually be something other than jQuery.
>
> To get around this and protect my ResourceReference from a backing library
> change, I thought I would add the jQuery dependency myself with
> JQueryResourceReference, but its javadoc states:
>  * The resource reference for the jquery javascript library as released with
> Wicket. To add a JQuery
>  * resource reference to a component, do not use this reference, but use
>  * {@link IJavaScriptLibrarySettings#getJQueryReference()} to prevent
> version conflicts.
> So I'm back to square one.
>
> Of course, personally I don't plan on using another backing library, but if
> this is something which Wicket wants to allow, I think it would be essential
> to address these issues. I wish I could offer a solution, but I don't
> currently have one so I decided to share this before 6.0 is released.

To re-iterate - #setJQueryReference() should be used only to change
the version of jquery.js if you need.
I'll update the Wiki page.

>
> Regards,
> Bertrand



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
>> -There are references to
>> IJavaScriptLibrarySettings#setBackingLibraryReference which does not exist
>> anymore. Is it still possible to change the backing library? I personally
>> don't want to, but the disparity between the doc and the code confused me.
> Fixed!
> org.apache.wicket.settings.IJavaScriptLibrarySettings#setJQueryReference
>

Maybe I don't understand it properly, but the possibility of changing 
the Wicket's backing library does not seem consistent. The names of the 
classes and methods for this functionality are one source of confusion. 
In the first versions of this code, the term "BackingLibrary" was used 
all over the place but it is now replaced by "JQuery".

For me, it is confusing that 
Application.get().getJavaScriptLibrarySettings().getJQueryReference() 
could return a reference to something which is not jQuery at all (e.g. 
DOJO).

Consider a subclass of JQueryPluginResourceReference whose javadoc states :
  * Base class for JavaScript resources that are JQuery plugins. This 
class already defines a
  * dependency on JQuery.
In its getDependencies() method, it looks up 
Application.get().getJavaScriptLibrarySettings().getJQueryReference() 
which can actually be something other than jQuery.

To get around this and protect my ResourceReference from a backing 
library change, I thought I would add the jQuery dependency myself with 
JQueryResourceReference, but its javadoc states:
  * The resource reference for the jquery javascript library as released 
with Wicket. To add a JQuery
  * resource reference to a component, do not use this reference, but use
  * {@link IJavaScriptLibrarySettings#getJQueryReference()} to prevent 
version conflicts.
So I'm back to square one.

Of course, personally I don't plan on using another backing library, but 
if this is something which Wicket wants to allow, I think it would be 
essential to address these issues. I wish I could offer a solution, but 
I don't currently have one so I decided to share this before 6.0 is 
released.

Regards,
Bertrand

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jul 25, 2012 at 6:42 PM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
> Here's what I have:
>
> /jqueryui/jquery-ui-1.8.17.custom.min.js
> /myWicketMountedPage <== wicket page which references jqueryui lib
> /myStaticPage.html <== a non-wicket page (static html or php or ...) which
> also references jqueryui lib
>
> Assume all paths have "servletroot/" pre-pended so absolute urls cannot be
> used.
>
> What I meant is that jquery ui's lib must be shared between wicket and
> static (non-wicket) pages.
> [see below]
>
>
>>> Currently, I use the following code in my base page class:
>>>
>>> public void renderHead(IHeaderResponse response) {
>>>
>>> response.render(JavaScriptHeaderItem.forUrl("jqueryui/jquery-ui-1.8.17.custom.min.js"));
>>> }
>>>
>>> "jqueryui/jquery-ui-1.8.17.custom.min.js" is always rendered as a url
>>> relative to Wicket's root. I can't use a PackageResource because this
>>> script
>>> must be accessible by other static pages in the same server root.
>>
>> How using JavaScriptHeaderItem.forUrl() saves you from having
>> duplicated <script>s for a resource which is loaded once by Wicket and
>> additionally by static .html ?
>
> In the wicket pages, I only use:
> response.render(JavaScriptHeaderItem.forUrl("jqueryui/jquery-ui-1.8.17.custom.min.js"));
> to add the jqueryui lib which produces a <script> with a url relative to
> Wicket's root. I never use both the programmatic and static html references
> in the same page.
>
> Here is the very simple diff:
> ---
> a/wicket-core/src/main/java/org/apache/wicket/request/resource/ExternalUrlResourceReference.java
> +++
> b/wicket-core/src/main/java/org/apache/wicket/request/resource/ExternalUrlResourceReference.java
> @@ -41,13 +41,6 @@ public class ExternalUrlResourceReference extends
> ResourceReference
>      public ExternalUrlResourceReference(final Url externalUrl)
>      {
>          super(asName(externalUrl));
> -
> -        if (externalUrl.isAbsolute() == false)
> -        {
> -            throw new
> IllegalArgumentException(ExternalUrlResourceReference.class.getSimpleName()
> +
> -                    " can be used only with absolute urls.");
> -        }
> -
>          this.externalUrl = externalUrl;
>      }
>
> In fact, it's so simple that it prompted me to ask why there is a
> requirement on the absoluteness of the url. If I can find a way to use an
> actual ResourceReference subclass for the jQueryUI lib, I will be able to
> properly use the resource dependencies functionality.
>

Since ExternalLink doesn't require absolute url I don't see reason why
to not relax this too.
Please file a ticket.

> Bertrand



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Here's what I have:

/jqueryui/jquery-ui-1.8.17.custom.min.js
/myWicketMountedPage <== wicket page which references jqueryui lib
/myStaticPage.html <== a non-wicket page (static html or php or ...) 
which also references jqueryui lib

Assume all paths have "servletroot/" pre-pended so absolute urls cannot 
be used.

What I meant is that jquery ui's lib must be shared between wicket and 
static (non-wicket) pages.
[see below]

>> Currently, I use the following code in my base page class:
>>
>> public void renderHead(IHeaderResponse response) {
>> response.render(JavaScriptHeaderItem.forUrl("jqueryui/jquery-ui-1.8.17.custom.min.js"));
>> }
>>
>> "jqueryui/jquery-ui-1.8.17.custom.min.js" is always rendered as a url
>> relative to Wicket's root. I can't use a PackageResource because this script
>> must be accessible by other static pages in the same server root.
> How using JavaScriptHeaderItem.forUrl() saves you from having
> duplicated <script>s for a resource which is loaded once by Wicket and
> additionally by static .html ?
In the wicket pages, I only use:
response.render(JavaScriptHeaderItem.forUrl("jqueryui/jquery-ui-1.8.17.custom.min.js"));
to add the jqueryui lib which produces a <script> with a url relative to 
Wicket's root. I never use both the programmatic and static html 
references in the same page.

Here is the very simple diff:
--- 
a/wicket-core/src/main/java/org/apache/wicket/request/resource/ExternalUrlResourceReference.java
+++ 
b/wicket-core/src/main/java/org/apache/wicket/request/resource/ExternalUrlResourceReference.java
@@ -41,13 +41,6 @@ public class ExternalUrlResourceReference extends 
ResourceReference
      public ExternalUrlResourceReference(final Url externalUrl)
      {
          super(asName(externalUrl));
-
-        if (externalUrl.isAbsolute() == false)
-        {
-            throw new 
IllegalArgumentException(ExternalUrlResourceReference.class.getSimpleName() 
+
-                    " can be used only with absolute urls.");
-        }
-
          this.externalUrl = externalUrl;
      }

In fact, it's so simple that it prompted me to ask why there is a 
requirement on the absoluteness of the url. If I can find a way to use 
an actual ResourceReference subclass for the jQueryUI lib, I will be 
able to properly use the resource dependencies functionality.

Bertrand

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Martin Grigorov <mg...@apache.org>.
Hi,

On Wed, Jul 25, 2012 at 5:13 PM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
> I have now finished porting my jQueryUI integration to Wicket 6 and I really
> like the final result! The "extra parameters" introduced in
> AbstractDefaultAjaxBehavior#getCallbackFunction() really simplified passing
> information back to Wicket.
>
> I am now trying to make good use of the ResourceReferences to include
> jQueryUI's javascript file and hitting a bump. Currently, I use the
> following code in my base page class:
>
> public void renderHead(IHeaderResponse response) {
> response.render(JavaScriptHeaderItem.forUrl("jqueryui/jquery-ui-1.8.17.custom.min.js"));
> }
>
> "jqueryui/jquery-ui-1.8.17.custom.min.js" is always rendered as a url
> relative to Wicket's root. I can't use a PackageResource because this script
> must be accessible by other static pages in the same server root.

How using JavaScriptHeaderItem.forUrl() saves you from having
duplicated <script>s for a resource which is loaded once by Wicket and
additionally by static .html ?

> WICKET-4466 introduced ExternalUrlResourceReference which allows using an
> absolute url for a resource reference (it's meant for CDNs). This is close
> to what I need so I forced it to also accept relative urls and it seems to
> work fine. Is it really necessary to allow only absolute urls? If so, is
> there another way to achieve what I seek?

Please share the diff so we can discuss it.

>
> Regards,
> Bertrand
>
>
>
> On 21/07/2012 9:37 AM, Martin Grigorov wrote:
>>
>>
>>> Some comments and questions regarding the migration docs:
>>> Should be added to migration doc:
>>> -MinimumValidator and MaximumValidator are replaced by
>>> RangeValidator.minimum and RangeValidator.maximum respectively
>>
>> The Wiki is editable by everyone with an account. Just create one and
>> contribute! ;-)
>
> Done!
>
>
>>>  From https://cwiki.apache.org/confluence/display/WICKET/Wicket+Ajax :
>>> -Very interesting read! If feel it really gave me a good overview of the
>>> new
>>> Wicket ajax support.
>>>
>>> -There are references to
>>> IJavaScriptLibrarySettings#setBackingLibraryReference which does not
>>> exist
>>> anymore. Is it still possible to change the backing library? I personally
>>> don't want to, but the disparity between the doc and the code confused
>>> me.
>>
>> Fixed!
>> org.apache.wicket.settings.IJavaScriptLibrarySettings#setJQueryReference
>>
>>
>>> -Both updateAjaxAttributes exemples include a call to super() but the
>>> javadoc does not mention that calling super() is required. Is it?
>>
>> It is not required but it is a good practice.
>> All super impls are currently empty.
>>
>>> -In the AjaxRequestAttributes table, the "preconditions" entry should be
>>> folded in "ajax call listeners" to be consistent. Also, after reading the
>>> code and the text below in "Migration steps", I noticed "ajax call
>>> listeners" is missing the "bsh" and "coh" short names.
>>
>> Improved!
>>
>>> -In the ajax listener points description, does the "complete handler"
>>> execute after "success handler" or "failure handler" or before? The
>>> bullet
>>> point order suggests that it executes after but it's not totally clear.
>>> Perhaps using an ordered list for the listener points or modifying the
>>> description of "complete handler" would clear things up.
>>
>> Complete handles are executed after either the success or the failure
>> handlers (if there are any).
>>
>> I've updated the Wiki page but feel free to further improve it!
>>
>>> Thanks for the great work!
>>> Bertrand
>>
>> Welcome!
>> Thanks for the feedback!
>>
>>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
I have now finished porting my jQueryUI integration to Wicket 6 and I 
really like the final result! The "extra parameters" introduced in 
AbstractDefaultAjaxBehavior#getCallbackFunction() really simplified 
passing information back to Wicket.

I am now trying to make good use of the ResourceReferences to include 
jQueryUI's javascript file and hitting a bump. Currently, I use the 
following code in my base page class:

public void renderHead(IHeaderResponse response) {
response.render(JavaScriptHeaderItem.forUrl("jqueryui/jquery-ui-1.8.17.custom.min.js"));
}

"jqueryui/jquery-ui-1.8.17.custom.min.js" is always rendered as a url 
relative to Wicket's root. I can't use a PackageResource because this 
script must be accessible by other static pages in the same server root. 
WICKET-4466 introduced ExternalUrlResourceReference which allows using 
an absolute url for a resource reference (it's meant for CDNs). This is 
close to what I need so I forced it to also accept relative urls and it 
seems to work fine. Is it really necessary to allow only absolute urls? 
If so, is there another way to achieve what I seek?

Regards,
Bertrand


On 21/07/2012 9:37 AM, Martin Grigorov wrote:
>
>> Some comments and questions regarding the migration docs:
>> Should be added to migration doc:
>> -MinimumValidator and MaximumValidator are replaced by
>> RangeValidator.minimum and RangeValidator.maximum respectively
> The Wiki is editable by everyone with an account. Just create one and
> contribute! ;-)
Done!

>>  From https://cwiki.apache.org/confluence/display/WICKET/Wicket+Ajax :
>> -Very interesting read! If feel it really gave me a good overview of the new
>> Wicket ajax support.
>>
>> -There are references to
>> IJavaScriptLibrarySettings#setBackingLibraryReference which does not exist
>> anymore. Is it still possible to change the backing library? I personally
>> don't want to, but the disparity between the doc and the code confused me.
> Fixed!
> org.apache.wicket.settings.IJavaScriptLibrarySettings#setJQueryReference
>
>
>> -Both updateAjaxAttributes exemples include a call to super() but the
>> javadoc does not mention that calling super() is required. Is it?
> It is not required but it is a good practice.
> All super impls are currently empty.
>
>> -In the AjaxRequestAttributes table, the "preconditions" entry should be
>> folded in "ajax call listeners" to be consistent. Also, after reading the
>> code and the text below in "Migration steps", I noticed "ajax call
>> listeners" is missing the "bsh" and "coh" short names.
> Improved!
>
>> -In the ajax listener points description, does the "complete handler"
>> execute after "success handler" or "failure handler" or before? The bullet
>> point order suggests that it executes after but it's not totally clear.
>> Perhaps using an ordered list for the listener points or modifying the
>> description of "complete handler" would clear things up.
> Complete handles are executed after either the success or the failure
> handlers (if there are any).
>
> I've updated the Wiki page but feel free to further improve it!
>
>> Thanks for the great work!
>> Bertrand
> Welcome!
> Thanks for the feedback!
>
>


Re: Apache Wicket 6.0.0-beta3 is released

Posted by Martin Grigorov <mg...@apache.org>.
Hi,

On Wed, Jul 18, 2012 at 11:10 PM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> wrote:
> Hi,
>
> I finally got around to try Wicket 6 with this release. Porting my
> application from 1.5 has been relatively fast. The only part which is not
> ported yet is my own integration of jQueryUI based on a mix of JQWicket and
> wiQuery.
>
> Besides my custom jQueryUI integration, the modifications requiring the most
> work were the addition of another generic type to IColumn, the changes to
> the Provider interface (longs instead of ints) and the replacement of
> AjaxCallDecorators.
>
> Personally, I'm not a big fan of the change to longs for Providers because
> as noted in WICKET-1175, it doesn't really solve the mismatch between JPA
> and Wicket (see TypedQuery#setFirstResult(int) and friends). Also, using
> lists as a backing store for a provider now requires casting from long to
> int because longs cannot be used with List#subList(). I guess at this point
> however, we'll just have to live with it!
>
> Some comments and questions regarding the migration docs:
> Should be added to migration doc:
> -MinimumValidator and MaximumValidator are replaced by
> RangeValidator.minimum and RangeValidator.maximum respectively

The Wiki is editable by everyone with an account. Just create one and
contribute! ;-)

>
> From https://cwiki.apache.org/confluence/display/WICKET/Wicket+Ajax :
> -Very interesting read! If feel it really gave me a good overview of the new
> Wicket ajax support.
>
> -There are references to
> IJavaScriptLibrarySettings#setBackingLibraryReference which does not exist
> anymore. Is it still possible to change the backing library? I personally
> don't want to, but the disparity between the doc and the code confused me.

Fixed!
org.apache.wicket.settings.IJavaScriptLibrarySettings#setJQueryReference


>
> -Both updateAjaxAttributes exemples include a call to super() but the
> javadoc does not mention that calling super() is required. Is it?

It is not required but it is a good practice.
All super impls are currently empty.

>
> -In the AjaxRequestAttributes table, the "preconditions" entry should be
> folded in "ajax call listeners" to be consistent. Also, after reading the
> code and the text below in "Migration steps", I noticed "ajax call
> listeners" is missing the "bsh" and "coh" short names.

Improved!

>
> -In the ajax listener points description, does the "complete handler"
> execute after "success handler" or "failure handler" or before? The bullet
> point order suggests that it executes after but it's not totally clear.
> Perhaps using an ordered list for the listener points or modifying the
> description of "complete handler" would clear things up.

Complete handles are executed after either the success or the failure
handlers (if there are any).

I've updated the Wiki page but feel free to further improve it!

>
> Thanks for the great work!
> Bertrand

Welcome!
Thanks for the feedback!


-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Re: Apache Wicket 6.0.0-beta3 is released

Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Hi,

I finally got around to try Wicket 6 with this release. Porting my 
application from 1.5 has been relatively fast. The only part which is 
not ported yet is my own integration of jQueryUI based on a mix of 
JQWicket and wiQuery.

Besides my custom jQueryUI integration, the modifications requiring the 
most work were the addition of another generic type to IColumn, the 
changes to the Provider interface (longs instead of ints) and the 
replacement of AjaxCallDecorators.

Personally, I'm not a big fan of the change to longs for Providers 
because as noted in WICKET-1175, it doesn't really solve the mismatch 
between JPA and Wicket (see TypedQuery#setFirstResult(int) and friends). 
Also, using lists as a backing store for a provider now requires casting 
from long to int because longs cannot be used with List#subList(). I 
guess at this point however, we'll just have to live with it!

Some comments and questions regarding the migration docs:
Should be added to migration doc:
-MinimumValidator and MaximumValidator are replaced by 
RangeValidator.minimum and RangeValidator.maximum respectively

 From https://cwiki.apache.org/confluence/display/WICKET/Wicket+Ajax :
-Very interesting read! If feel it really gave me a good overview of the 
new Wicket ajax support.

-There are references to 
IJavaScriptLibrarySettings#setBackingLibraryReference which does not 
exist anymore. Is it still possible to change the backing library? I 
personally don't want to, but the disparity between the doc and the code 
confused me.

-Both updateAjaxAttributes exemples include a call to super() but the 
javadoc does not mention that calling super() is required. Is it?

-In the AjaxRequestAttributes table, the "preconditions" entry should be 
folded in "ajax call listeners" to be consistent. Also, after reading 
the code and the text below in "Migration steps", I noticed "ajax call 
listeners" is missing the "bsh" and "coh" short names.

-In the ajax listener points description, does the "complete handler" 
execute after "success handler" or "failure handler" or before? The 
bullet point order suggests that it executes after but it's not totally 
clear. Perhaps using an ordered list for the listener points or 
modifying the description of "complete handler" would clear things up.

Thanks for the great work!
Bertrand