|
Administrator
|
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! |
|
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 |
|
p.s. I hope I sent this to the right list! Thunderbird used dev@ as the
reply-to address. |
|
In reply to this post by Bertrand Guay-Paquet
Hi,
On Wed, Jul 18, 2012 at 11:10 PM, Bertrand Guay-Paquet <[hidden email]> 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 |
|
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! > > |
|
Hi,
On Wed, Jul 25, 2012 at 5:13 PM, Bertrand Guay-Paquet <[hidden email]> 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 |
|
In reply to this post by Martin Grigorov-4
>> -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 |
|
On Wed, Jul 25, 2012 at 5:47 PM, Bertrand Guay-Paquet
<[hidden email]> 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 |
|
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! |
|
On Wed, Jul 25, 2012 at 6:18 PM, Bertrand Guay-Paquet
<[hidden email]> 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 |
|
In reply to this post by Martin Grigorov-4
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 ? 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 |
|
On Wed, Jul 25, 2012 at 6:42 PM, Bertrand Guay-Paquet
<[hidden email]> 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 |
| Powered by Nabble | Edit this page |
