svn commit: r1051001 - in /wicket/branches/wicket-1.4.15: ./ archetypes/quickstart/ archetypes/quickstart/src/main/resources/archetype-resources/ testing/wicket-threadtest/ wicket-auth-roles/ wicket-d
Author: jrthomerson Date: Mon Dec 20 06:55:05 2010 New Revision: 1051001 URL: http://svn.apache.org/viewvc?rev=1051001&view=rev Log: preparing for 1.4.15 release Modified: wicket/branches/wicket-1.4.15/archetypes/quickstart/pom.xml wicket/branches/wicket-1.4.15/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml wicket/branches/wicket-1.4.15/pom.xml wicket/branches/wicket-1.4.15/testing/wicket-threadtest/pom.xml wicket/branches/wicket-1.4.15/wicket-auth-roles/pom.xml wicket/branches/wicket-1.4.15/wicket-datetime/pom.xml wicket/branches/wicket-1.4.15/wicket-devutils/pom.xml wicket/branches/wicket-1.4.15/wicket-examples/pom.xml wicket/branches/wicket-1.4.15/wicket-extensions/pom.xml wicket/branches/wicket-1.4.15/wicket-guice/pom.xml wicket/branches/wicket-1.4.15/wicket-ioc/pom.xml wicket/branches/wicket-1.4.15/wicket-jmx/pom.xml wicket/branches/wicket-1.4.15/wicket-objectssizeof-agent/pom.xml wicket/branches/wicket-1.4.15/wicket-spring/pom.xml wicket/branches/wicket-1.4.15/wicket-velocity/pom.xml wicket/branches/wicket-1.4.15/wicket/pom.xml Modified: wicket/branches/wicket-1.4.15/archetypes/quickstart/pom.xml URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.15/archetypes/quickstart/pom.xml?rev=1051001&r1=1051000&r2=1051001&view=diff == --- wicket/branches/wicket-1.4.15/archetypes/quickstart/pom.xml (original) +++ wicket/branches/wicket-1.4.15/archetypes/quickstart/pom.xml Mon Dec 20 06:55:05 2010 @@ -3,7 +3,7 @@ org.apache.wicket wicket-parent - 1.4-SNAPSHOT + 1.4.15 ../../pom.xml Modified: wicket/branches/wicket-1.4.15/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.15/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml?rev=1051001&r1=1051000&r2=1051001&view=diff == --- wicket/branches/wicket-1.4.15/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml (original) +++ wicket/branches/wicket-1.4.15/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml Mon Dec 20 06:55:05 2010 @@ -20,7 +20,7 @@ - 1.4-SNAPSHOT + 1.4.15 6.1.25 1.5.8 1.2.14 @@ -134,4 +134,4 @@ #end - \ No newline at end of file + Modified: wicket/branches/wicket-1.4.15/pom.xml URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.15/pom.xml?rev=1051001&r1=1051000&r2=1051001&view=diff == --- wicket/branches/wicket-1.4.15/pom.xml (original) +++ wicket/branches/wicket-1.4.15/pom.xml Mon Dec 20 06:55:05 2010 @@ -26,7 +26,7 @@ org.apache.wicket wicket-parent - 1.4-SNAPSHOT + 1.4.15 pom Wicket Parent Wicket is a Java-based open source component web application framework. @@ -285,9 +285,9 @@ http://wicketstuff.org/bamboo - scm:svn:http://svn.apache.org/repos/asf/wicket/trunk - scm:svn:https://svn.apache.org/repos/asf/wicket/trunk - http://svn.apache.org/viewvc/wicket/trunk + scm:svn:http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.15 + scm:svn:https://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.15 + http://svn.apache.org/viewvc/wicket/releases/wicket-1.4.15 Modified: wicket/branches/wicket-1.4.15/testing/wicket-threadtest/pom.xml URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.15/testing/wicket-threadtest/pom.xml?rev=1051001&r1=1051000&r2=1051001&view=diff == --- wicket/branches/wicket-1.4.15/testing/wicket-threadtest/pom.xml (original) +++ wicket/branches/wicket-1.4.15/testing/wicket-threadtest/pom.xml Mon Dec 20 06:55:05 2010 @@ -23,7 +23,7 @@ org.apache.wicket wicket-parent - 1.4-SNAPSHOT + 1.4.15 ../../pom.xml Modified: wicket/branches/wicket-1.4.15/wicket-auth-roles/pom.xml URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.15/wicket-auth-roles/pom.xml?rev=1051001&r1=1051000&r2=1051001&view=diff == --- wicket/branches/wicket-1.4.15/wicket-auth-roles/pom.xml (original) +++ wicket/branches/wicket-1.4.15/wicket-auth-roles/pom.xml Mon Dec 20 06:55:05 2010 @@ -23,7 +23,7 @@ org.apache.wicket wicket-parent - 1.
svn commit: r1050998 - /wicket/branches/wicket-1.4.15/
Author: jrthomerson Date: Mon Dec 20 06:52:16 2010 New Revision: 1050998 URL: http://svn.apache.org/viewvc?rev=1050998&view=rev Log: creating 1.4.15 release branch Added: wicket/branches/wicket-1.4.15/ (props changed) - copied from r1050997, wicket/branches/wicket-1.4.x/ Propchange: wicket/branches/wicket-1.4.15/ -- --- subclipse:tags (added) +++ subclipse:tags Mon Dec 20 06:52:16 2010 @@ -0,0 +1,5 @@ +550610,wicket-1.3.0-beta2,/wicket/tags/wicket-1.3.0-beta2,tag +567792,wicket-1.3.0-beta3,/wicket/tags/wicket-1.3.0-beta3,tag +582590,wicket-1.3.0-beta4,/wicket/tags/wicket-1.3.0-beta4,tag +591745,wicket-1.3.0-rc1,/wicket/tags/wicket-1.3.0-rc1,tag +601799,wicket-1.3.0-rc2,/wicket/tags/wicket-1.3.0-rc2,tag Propchange: wicket/branches/wicket-1.4.15/ -- --- svn:ignore (added) +++ svn:ignore Mon Dec 20 06:52:16 2010 @@ -0,0 +1,4 @@ +target +.metadata +.project +velocity.log Propchange: wicket/branches/wicket-1.4.15/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Mon Dec 20 06:52:16 2010 @@ -0,0 +1,2 @@ +/wicket/sandbox/jthomerson/experimental/wicket-devutils:760296-760351,760353-760355 +/wicket/trunk/wicket-devutils:760352
svn commit: r1050997 - /wicket/branches/wicket-1.4.x/CHANGELOG-1.4
Author: jrthomerson Date: Mon Dec 20 06:49:59 2010 New Revision: 1050997 URL: http://svn.apache.org/viewvc?rev=1050997&view=rev Log: release notes for 1.4.15 Modified: wicket/branches/wicket-1.4.x/CHANGELOG-1.4 Modified: wicket/branches/wicket-1.4.x/CHANGELOG-1.4 URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/CHANGELOG-1.4?rev=1050997&r1=1050996&r2=1050997&view=diff == --- wicket/branches/wicket-1.4.x/CHANGELOG-1.4 (original) +++ wicket/branches/wicket-1.4.x/CHANGELOG-1.4 Mon Dec 20 06:49:59 2010 @@ -1,5 +1,32 @@ This file contains all changes done on the 1.4 version. +Release Notes - Wicket - Version 1.4.15 + +** Bug +* [WICKET-1894] - AjaxFallbackButton: inconsistent submit order +* [WICKET-3136] - JVM 1.6 crash caused by WicketObjectOutputStream, ClassStreamHandler, and Page.writePageObject +* [WICKET-3196] - UrlValidator failes to validate urls that containt multiple dots in path +* [WICKET-3202] - Form with UploadProgressBar and AjaxButton doesn't submit +* [WICKET-3215] - AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 +* [WICKET-3229] - Removing Child in IVisitor affects traversal +* [WICKET-3244] - libxml2 splits large CData section. This breaks the processEvaluate js +* [WICKET-3253] - NPE with nested property models +* [WICKET-3255] - css/js files added as header contribution not added via ajax request +* [WICKET-3259] - Filter path is occasionally null when forwarding a request + +** Improvement +* [WICKET-3154] - test for undefined in the same manner throughtout the code. +* [WICKET-3184] - Make method getContentId of ModalWindow static +* [WICKET-3226] - NavigationToolbar has table instance variable but so does base-class AbstractToolbar +* [WICKET-3235] - AutoCompleteBehavior overwrites base class AbstractAutoCompleteBehavior settings variable +* [WICKET-3254] - Add file name to the exception in case of an error during temp file creation for upload +* [WICKET-3264] - MetaDataEntry set method traverses metaData even after key is found and data set/cleared +* [WICKET-3265] - Component data_remove returns Object which is never used + +** Wish +* [WICKET-3237] - Exception when calling setOutputMarkupId/PlaceholderTag on wicket:container + + Release Notes - Wicket - Version 1.4.14 ** Bug
[jira] Updated: (WICKET-3171) Form components that become visible during submit always set their model to null
[
https://issues.apache.org/jira/browse/WICKET-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Thomerson updated WICKET-3171:
-
Fix Version/s: (was: 1.5-M4)
(was: 1.4.14)
Removing fix versions on things that were marked as fixVersion = (1.4.14 ||
1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so
that they don't show up in release notes when in reality they weren't part of
the release.
> Form components that become visible during submit always set their model to
> null
>
>
> Key: WICKET-3171
> URL: https://issues.apache.org/jira/browse/WICKET-3171
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.9
> Environment: Mac OS X 10.6.4 running Java 1.6.0_22
>Reporter: Jesse Barnum
>Assignee: Igor Vaynberg
>
> It seems that non-visible components initially have a convertedValue of null.
> If they become visible during the form submit processing, they will write
> this null value to their model. This can lead to data loss or exceptions.
> For example, with this sample code, if the checkbox to make the the 'name'
> and 'age' fields visible is checked, null values are written to the data
> object when the form is submitted.
> I'm not that familiar with the Wicket form processing internals, but it seems
> to me that the solution is to gather a list of all visible components before
> processing any of them, and then iterate through that list, ignoring new
> components (with invalid state) that become visible.
>
> package com.prosc.test;
> import org.apache.wicket.markup.html.WebMarkupContainer;
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.markup.html.form.CheckBox;
> import org.apache.wicket.markup.html.form.Form;
> import org.apache.wicket.markup.html.form.TextField;
> import org.apache.wicket.model.CompoundPropertyModel;
> public class FormVisibilityTest extends WebPage {
> private SampleBean bean = new SampleBean();
>
> public FormVisibilityTest() {
> Form form = new Form("form", new
> CompoundPropertyModel(bean) );
> add(form);
> form.add( new CheckBox("showName" ) );
> WebMarkupContainer nameSection = new WebMarkupContainer(
> "nameSection" ) {
> public boolean isVisible() {
> //return true; //If everything is visible,
> values are pulled from default SampleBean values and everything works as
> expected
> return bean.isShowName(); //If visibility
> starts off false when the form is initially submitted but then becomes true
> during the submit process, null values are submitted to the model
> }
> };
> form.add( nameSection );
> nameSection.add( new TextField( "name" ) );
> nameSection.add( new TextField( "age" ) );
> }
> }
> ===
> package com.prosc.test;
> import java.io.Serializable;
> public class SampleBean implements Serializable {
> private boolean showName = false;
> private String name = "John";
> private int age = 34;
> public boolean isShowName() {
> return showName;
> }
> public void setShowName( boolean showName ) {
> this.showName = showName;
> }
> public String getName() {
> return name;
> }
> public void setName( String name ) {
> this.name = name;
> }
> public int getAge() {
> return age;
> }
> public void setAge( int age ) {
> this.age = age;
> }
> }
>
>
>
>
>
> Is name section
> visible?
>
>
>
> Name:
> Age:
>
>
>
>
>
>
>
> ===
> package com.prosc.test;
> import org.apache.wicket.util.tester.WicketTester;
> import junit.framework.TestCase;
> public class FormVisibilityTestcase extends TestCase {
> public void testSubmit() {
> WicketTester tester = new WicketTester();
> tester.startPage( FormVisibilityTest.class );
> tester.setParameterForNextRequest( "form:showName",
> Boolean.TRUE );
> tester.submitForm( "form" ); //This causes an exception because
> it tries to submit a null value to a setter that expects an int primitive for
> 'age'
> //org.apache.wicket.util.convert.ConversionException: Can't
> convert null value to a primitive class: int for setting it on
> com.prosc.test.sampleb...@5289e2f1
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a com
[jira] Updated: (WICKET-3179) Default Component Behaviors
[ https://issues.apache.org/jira/browse/WICKET-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3179: - Fix Version/s: (was: 1.5-M4) (was: 1.4.14) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Default Component Behaviors > --- > > Key: WICKET-3179 > URL: https://issues.apache.org/jira/browse/WICKET-3179 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.13 > Environment: Java 1.6, Windows. >Reporter: Jean-Francois Larouche >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > Weve got a little problem and i dont know if theres another way to do this. > Ive searched and found nothing. > We need to add some sort of ErrorBehavior to all of our form components. And > the code duplication starts to be very ugly. > Would this be possible/make sense: > When the components renders, they call getBehaviors(); > getBehaviors() could then not only get the Component one but also call > Application.get().getDefaultComponentBehavior(); and return the merged list. > This does not affect anything in current wicket implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3230) Without Cookie Support, Pages expire instantly in FireFox
[ https://issues.apache.org/jira/browse/WICKET-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3230: - Fix Version/s: (was: 1.4.15) (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Without Cookie Support, Pages expire instantly in FireFox > - > > Key: WICKET-3230 > URL: https://issues.apache.org/jira/browse/WICKET-3230 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14 > Environment: FireFox 3.6.12 >Reporter: bernard >Assignee: Martin Grigorov > Attachments: ExpiryNoCookies.zip, FireFoxSettings.gif > > > It appears that Wicket functionality such as AJAX stops working in FireFox if > cookies are disabled. Please refer to the attached quickstart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1242) IE quirks mode
[ https://issues.apache.org/jira/browse/WICKET-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-1242: - Fix Version/s: (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > IE quirks mode > -- > > Key: WICKET-1242 > URL: https://issues.apache.org/jira/browse/WICKET-1242 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc2 >Reporter: Juergen Donnerstag >Assignee: Juergen Donnerstag > > on the one hand side we'd like to have (and some users even want the ability > to enforce it - see jira issues) that all markup files have a xml > declaration. On the other hand most current IE browser are not able to handle > is properly and switch to quirks mode which has several drawbacks. A posible > solutiion could be to > a) change our default to > getMarkupSettings().setStripXmlDeclarationFromOutput(true) > and > b) check the doc type exists and proper html tag exists. > Else log a big warning that output will force IE into quirks mode -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3238) Required checkbox behaves differently in tests and in real application
[ https://issues.apache.org/jira/browse/WICKET-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3238: - Fix Version/s: (was: 1.4.15) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Required checkbox behaves differently in tests and in real application > -- > > Key: WICKET-3238 > URL: https://issues.apache.org/jira/browse/WICKET-3238 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.13 >Reporter: Marius Bauer >Priority: Minor > Attachments: wicket-3238.tgz > > > Create a form and add a required checkbox to it. If you run the application, > you will not be allowed to submit the form without ticking the checkbox, but > if you use the WicketTester and submit the form using the FormTester in a > JUnit test, you are able to submit the form without ticking that checkbox > (onSubmit() is executed). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3251) How to set custom HTTP response header in Wicket's Ajax responses?
[ https://issues.apache.org/jira/browse/WICKET-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3251: - Fix Version/s: (was: 1.4.15) (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > How to set custom HTTP response header in Wicket's Ajax responses? > -- > > Key: WICKET-3251 > URL: https://issues.apache.org/jira/browse/WICKET-3251 > Project: Wicket > Issue Type: Bug >Reporter: Martin Funk > Attachments: Wicket-3251.diff > > > http://stackoverflow.com/questions/4397211/how-to-set-custom-http-response-header-in-wickets-ajax-responses/4399434#4399434 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3236) File upload with inner form and modal window
[ https://issues.apache.org/jira/browse/WICKET-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3236: - Fix Version/s: (was: 1.4.15) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > File upload with inner form and modal window > > > Key: WICKET-3236 > URL: https://issues.apache.org/jira/browse/WICKET-3236 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14 >Reporter: Cedric Thiebault > Attachments: wicket-modal-upload.zip > > > I want to upload file with an Ajax form that is in a modal window. The modal > and its form are part of the main form. > 1) I'm able to upload a file but once the modal is closed, when I submit the > main form (not the one for uploading), I get an exception: > java.lang.IllegalStateException: ServletRequest does not contain multipart > content. One possible solution is to explicitly call Form.setMultipart(true), > Wicket tries its best to auto-detect multipart forms but there are certain > situation where it cannot. > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(MultipartServletWebRequest.java:113) > at > org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.(MultipartServletWebRequest.java:83) > at > org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:489) > at > org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1708) > at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:886) > at > org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135) > at > org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177) > at > org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300) > at > org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:142) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:319) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:324) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) > at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) > Use the quick start I've uploaded to reproduce this: > - mvn jetty:run > - click on "Add new file (panel modal)" and upload a file > - then, once the modal is closed, click on "Submit input text" > --> exception > 2) I've also tried to use a modal with a WebPage instead of a Panel: it works > well except that the DataTable does not reflect the new uploaded files... > even if everything is fine in background with models. > Any ideas of what I did wrong here? Is it because of AjaxRequestTarget > between pages and panels? > Thanks for your
[jira] Updated: (WICKET-3262) MountedMapper defined in WicketApplication doesn't accept /mount/paramval0/paramval1
[ https://issues.apache.org/jira/browse/WICKET-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3262: - Fix Version/s: (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > MountedMapper defined in WicketApplication doesn't accept > /mount/paramval0/paramval1 > > > Key: WICKET-3262 > URL: https://issues.apache.org/jira/browse/WICKET-3262 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-M3 >Reporter: Andrew Lombardi >Assignee: Martin Grigorov > Attachments: mountedmapper_test.tar.gz > > > If you utilize mountPage or create a MountedMapper with parameters, it fails > to represent that URL similar to the IndexedParamUrlCodingStrategy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3248) WicketRuntimeException: component not found on page
[ https://issues.apache.org/jira/browse/WICKET-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3248: - Fix Version/s: (was: 1.4.15) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > WicketRuntimeException: component not found on page > --- > > Key: WICKET-3248 > URL: https://issues.apache.org/jira/browse/WICKET-3248 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.12 > Environment: with wiquery 1.1.2, wiquery-plugins > (other-plugins-1.1.jar) >Reporter: Takeo Hosomi > Attachments: panels.zip > > > Hello, > I have the same issue which is discussed in the following link: > http://apache-wicket.1842946.n4.nabble.com/WicketRuntimeException-component-not-found-on-page-td3055902.html > I made a quickstart to reproduce it. Any idea on how to workaround this > behavior? > I'm using wicket 1.4.12, wiquery 1.1.2, and wiquery-plugin for tooltip > (other-plugins-1.1.jar). > How to reproduce: > When clicking the paging navigator, quickly move the mouse to the table > region. Then sometimes following error messages are shown: > ERROR - RequestCycle - > org.apache.wicket.WicketRuntimeException: component > tabs:container:user:2 not found on page gvc.web.webpages.TestPage[id = 4], > listener interface = [RequestListenerInterface > name=IActivePageBehaviorListener, method=public abstract void > org.apache.wicket.behavior.IBehaviorListener.onRequest()] > org.apache.wicket.protocol.http.request.InvalidUrlException: > org.apache.wicket.WicketRuntimeException: component > tabs:container:user:2 not found on page gvc.web.webpages.TestPage[id = 4], > listener interface = [RequestListenerInterface > name=IActivePageBehaviorListener, method=public abstract void > org.apache.wicket.behavior.IBehaviorListener.onRequest()] > at > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484) > at > org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:138) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:527) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1216) > at > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1187) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:421) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:493) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:930) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:866) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113) > at org.eclipse.jetty.server.Server.handle(Server.java:351) > at > org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:594) > at > org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1041) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211) > at > org.e
[jira] Updated: (WICKET-3234) Wicket 'quickstart' archetype requires dependencies not in Maven.
[ https://issues.apache.org/jira/browse/WICKET-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3234: - Fix Version/s: (was: 1.4.15) (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Wicket 'quickstart' archetype requires dependencies not in Maven. > -- > > Key: WICKET-3234 > URL: https://issues.apache.org/jira/browse/WICKET-3234 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart > Environment: Ubuntu Lucid, Bash, Maven >Reporter: Cefn Hoile >Priority: Minor > > I tried to configure and test an artifact which combines Wicket and > Hibernate, following quickstart instructions, invoked with these three > steps... > mvn archetype:generate -B > -DarchetypeCatalog=http://legup.googlecode.com/svn/repo/archetype-catalog.xml > -DarchetypeArtifactId=wicket-warp-hibernate-archetype > -DarchetypeGroupId=com.jweekend -DarchetypeVersion=0.8.4 > -DgroupId=com.cefn.filesystem.wicket -DartifactId=cefn-wicket > -Dversion=1.0-SNAPSHOT -Dpackage=com.cefn.filesystem.wicket > cd cefn-wicket > mvn test > I encounter the build error below. Great error message by the way. Really > informative and offers an immediate workaround. > However, is it possible for future users attempting a 'quick start' to > establish a stable artefact combining Hibernate and Wicket which has all its > dependencies met by the current Maven repository? > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.wideplay.warp:warp-persist:jar:2.0-20090214 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.wideplay.warp > -DartifactId=warp-persist -Dversion=2.0-20090214 -Dpackaging=jar > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.wideplay.warp > -DartifactId=warp-persist -Dversion=2.0-20090214 -Dpackaging=jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.cefn.filesystem.wicket:cefn-wicket:war:1.0-SNAPSHOT > 2) com.wideplay.warp:warp-persist:jar:2.0-20090214 > -- > 1 required artifact is missing. > for artifact: > com.cefn.filesystem.wicket:cefn-wicket:war:1.0-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > jboss (https://repository.jboss.org/nexus/content/groups/public/) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3216) Url Page Parameters are coming null when mounted a page with IndexedParamUrlCodingStrategy
[
https://issues.apache.org/jira/browse/WICKET-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Thomerson updated WICKET-3216:
-
Fix Version/s: (was: 1.4.15)
(was: 1.5-M4)
Removing fix versions on things that were marked as fixVersion = (1.4.14 ||
1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so
that they don't show up in release notes when in reality they weren't part of
the release.
> Url Page Parameters are coming null when mounted a page with
> IndexedParamUrlCodingStrategy
> --
>
> Key: WICKET-3216
> URL: https://issues.apache.org/jira/browse/WICKET-3216
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Environment: Windows Xp
>Reporter: shashi
>
> Hi
> My application was developed in wicket 1.3.1 and i am using
> IndexedParamUrlCodingStrategy to mount the book markable page in my
> application class setFriendlyUrls() method like this
> this.mount(new
> IndexedParamUrlCodingStrategy("/trainexception,TrainExceptionsPage.class));
> and my train exception page has overload constructor with page parametrs as
> argument when i type the url as
> http://localhost:8080/itm/secure/jas/trainexception?suiFunctionCommand=te&suiCommandLine=te&suiFunctionTLA=NGT&suiFunctionName=Exceptions%20%28TE%29
> and hit enter constructor with out page parameters are getting called and
> when i debug and see the page parameters are coming a s null.
> my observation is in deCodeParameters method urlFragment is coming as blank
> string.
> if (urlFragment.startsWith("/"))
> {
> urlFragment = urlFragment.substring(1);
> }
> if (urlFragment.length() > 0 && urlFragment.endsWith("/"))
> {
> urlFragment = urlFragment.substring(0,
> urlFragment.length() - 1);
> }
> if (urlFragment.length() > 0)
> {
> String[] parts = urlFragment.split("/");
> for (int i = 0; i < parts.length; i++)
> {
> if
> (WebRequestCodingStrategy.PAGEMAP.equals(parts[i]))
> {
> i++;
>
> params.put(WebRequestCodingStrategy.PAGEMAP, WebRequestCodingStrategy
>
> .decodePageMapName(urlDecode(parts[i])));
> }
> else if
> (WebRequestCodingStrategy.INTERFACE_PARAMETER_NAME.equals(parts[i]))
> {
> i++;
>
> params.put(WebRequestCodingStrategy.INTERFACE_PARAMETER_NAME,
> urlDecode(parts[i]));
> }
> else
> {
> params.put(String.valueOf(i),
> urlDecode(parts[i]));
> }
> }
> }
> so all the below conditions are getting falied and emplty paramers are
> returned.
> but when i put a debug point i saw that the underlying array in urlFragment
> string us having the values but the string is empty.this is puzzling me.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3180) DropDownChoice should use IAjaxIndicatorAware like AbstractDefaultAjaxBehavior.findIndicatorId()
[ https://issues.apache.org/jira/browse/WICKET-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3180: - Fix Version/s: (was: 1.5-M4) (was: 1.4.14) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > DropDownChoice should use IAjaxIndicatorAware like > AbstractDefaultAjaxBehavior.findIndicatorId() > -- > > Key: WICKET-3180 > URL: https://issues.apache.org/jira/browse/WICKET-3180 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.13 >Reporter: Michael Frankerl >Assignee: Martin Grigorov > Attachments: AjaxIndicatorAwareDropDownChoice.java > > > DropDownChoice should use IAjaxIndicatorAware like > AbstractDefaultAjaxBehavior.findIndicatorId() in it's onComponentTag method, > in order to work with the same indicatior mechanism. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3182) Introduce Maven Toolchains to ensure compilation with an appropriate JDK
[ https://issues.apache.org/jira/browse/WICKET-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3182: - Fix Version/s: (was: 1.4.15) (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Introduce Maven Toolchains to ensure compilation with an appropriate JDK > > > Key: WICKET-3182 > URL: https://issues.apache.org/jira/browse/WICKET-3182 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.4.13 >Reporter: Carl-Eric Menzel >Assignee: Martin Grigorov > Attachments: > 0001-introducing-maven-toolchains-plugin-to-make-jdk1.5-c.patch, > toolchains.xml > > > Trying to compile Wicket 1.4.13 recently, I ran into the problem that > ResourceTestPage in wicket-threadtest failed to compile, since it tries to > catch an IOException in line 87. The only line in the catch block, > JPEGImageEncoder.encode(image), doesn't declare that exception, and so the > compiler rejects the catch. > Turns out this is a change in JDK 1.6. After pulling in some old Ubuntu > repositories and actually installing an old 1.5 JDK, and temporarily setting > my JAVA_HOME to that, the build worked fine. > It would be easy to just change this catch clause to Throwable instead of > IOException, that way both JDKs would be satisfied. However, when I hack on > Wicket, I don't want to inadvertently introduce dependencies to JDK 1.6. The > maven compiler settings only check for syntax compatibility, not API > compatibility, so this could easily happen. > On the other hand, I don't want to be setting and re-setting my JAVA_HOME > every time I want to build Wicket, so I looked for a way to tell Maven what > JDK to use, without hardcoding my path into Wicket's pom.xml. > It turns out that you can't do anything like that in your local settings.xml. > Sometimes I really hate Maven ;-) > There is a plugin called maven-toolchains, however, that makes this possible. > You add this plugin to the projects, and add a rather simply toolchains.xml > to your ~/.m2/, and then you can define things like "JDK version: 1.5" or > even "vendor: sun". I wouldn't do the latter, but I found that this way I > could have Maven automatically pick my JDK 1.5 installation for Wicket, and > compile everything else with 1.6. > I'll provide a patch and an example toolchains.xml. What do you think, should > this be integrated? It would amount to a one-time change to each developer's > environment (at least for those that don't use toolchains yet). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3131) Retest all combinations of redirect policies and render strategies
[ https://issues.apache.org/jira/browse/WICKET-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3131: - Fix Version/s: (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Retest all combinations of redirect policies and render strategies > -- > > Key: WICKET-3131 > URL: https://issues.apache.org/jira/browse/WICKET-3131 > Project: Wicket > Issue Type: Sub-task > Components: wicket >Affects Versions: 1.5-M2.1 >Reporter: Martin Grigorov >Assignee: Martin Grigorov > Attachments: WICKET-3131.patch > > > While debugging problem "ajax links example - failure handler is not invoked, > instead error is reported" in WICKET-3114 I found that using redirect policy > "NEVER_REDIRECT" doesn't quite work because the response body is already > written when Wicket tries to write the headers > (org.apache.wicket.request.handler.render.WebPageRenderer.respond(RequestCycle), > around line 203). > So failures in processing Ajax request cannot successfully return http status > "500" to wicket-ajax.js. > I think we need to retest all possible combinations of redirect policies and > render strategies and add unit tests for them if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3243) Datepicker icon link not working in Firefox
[ https://issues.apache.org/jira/browse/WICKET-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-3243: - Fix Version/s: (was: 1.4.15) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Datepicker icon link not working in Firefox > --- > > Key: WICKET-3243 > URL: https://issues.apache.org/jira/browse/WICKET-3243 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.10, 1.4.14 > Environment: Windows Vista > Java version 1.6 > Firefox version 3.6.12 (all add-ons were disabled) >Reporter: kibrahacha >Priority: Critical > > Using the example http://wicketstuff.org/wicket14/dates/ with Firefox version > 3.6.12 (all add-ons disabled) > The calender does not popup when the Datepicker icon has been clicked. > Locally I've tested the Datepicker with a newer version of wicket (1.4.14) > with the same Firefox version with the same result. > The calendar does work in Internet Explorer 8.06 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1847) Custom, user defined, configuration types plus configuration type change during runtime
[ https://issues.apache.org/jira/browse/WICKET-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-1847: - Fix Version/s: (was: 1.5-M4) Removing fix versions on things that were marked as fixVersion = (1.4.14 || 1.5-M4), but also weren't fixed (marked "not a problem", "won't fix", etc) so that they don't show up in release notes when in reality they weren't part of the release. > Custom, user defined, configuration types plus configuration type change > during runtime > --- > > Key: WICKET-1847 > URL: https://issues.apache.org/jira/browse/WICKET-1847 > Project: Wicket > Issue Type: New Feature > Components: wicket >Reporter: Bruno Borges >Assignee: Igor Vaynberg > Attachments: patch.diff > > > Currently, there's only two configuration types (DEVELOPMENT, DEPLOYMENT) and > both are hardcoded. Because Application.configure() is final, there's no > (easy) way to provide customized configurations and no out-of-box API to code > these. > The idea is to give org.apache.wicket.Application a new method called > add(IApplicationConfiguration) and from there, the > user can define custom configuration types. > Wicket's default configuration types will still be there if the user do not > replace them (creating configurators with "deployment" or "development" as > the name, but still is possible to override). > There will be also the possibility to change the configuration type easily > during runtime with setConfigurationType. > The default configuration type will still be defined the current way (VM > parameter, Filter parameter) > The configuration is now made during the initializeComponents() because of > procedural methods. Calling setConfigurationType(String) with the user > defined *hard-coded* getDefaultConfigurationType() during internalInit() > would throw an exception because the custom IApplicationConfigurator hasn't > been added yet (it is added during init() ... usually). > This patch also avoids subsequent calls to initializeComponents(), throwing > an IllegalStateException. > * Issues with this patch > - There are 6 references pointing to getConigurationType comparing the > returned value with Application.DEVELOPMENT to do certain things. > - The method getConfigurationType() is now final (and of course, > implemented). People who wants to change the configuration type, should call > setConfigurationType(String). This will recall configure() method to > reconfigure the application (runtime configuration type change support) > The patch does not break those references at all with current > implementations, as the two default configuration types still live in there, > but it would be better to turn those if conditions to some sort of settings. > Also, the patch fixes WICKET-1317 for 1.4/1.5 as well. > ** IMPORTANT NOTE ** > Because of some problem with Eclipse, the provided code formatter didn't work > well, so before applying the patch, format the code and confirm the > differences with trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-2896) OrderByLink should support a ASCENDING -> DESCENDING -> NONE cycle
[
https://issues.apache.org/jira/browse/WICKET-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Thomerson reopened WICKET-2896:
--
since you made it possible for them to override, i'm reopening to change from
"won't fix" to "resolved"
> OrderByLink should support a ASCENDING -> DESCENDING -> NONE cycle
> --
>
> Key: WICKET-2896
> URL: https://issues.apache.org/jira/browse/WICKET-2896
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
>Affects Versions: 1.4.8
>Reporter: nicolas de loof
>Assignee: Peter Ertl
>Priority: Trivial
> Fix For: 1.5-M4
>
>
> Trying to extend SortableDataProvider to support multiple sorting criteria
> (based on http://www.mail-archive.com/users@wicket.apache.org/msg14246.html),
> the ordering feature on DataTable cannot be used to get back to the "NONE"
> state. A simple change in OrderByLink can be used to fix this :
> int newDir = ISortState.NONE;
> if ( oldDir == ISortState.NONE )
> {
> newDir = ISortState.ASCENDING;
> }
> if ( oldDir == ISortState.ASCENDING )
> {
> newDir = ISortState.DESCENDING;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2896) OrderByLink should support a ASCENDING -> DESCENDING -> NONE cycle
[
https://issues.apache.org/jira/browse/WICKET-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Thomerson resolved WICKET-2896.
--
Resolution: Fixed
> OrderByLink should support a ASCENDING -> DESCENDING -> NONE cycle
> --
>
> Key: WICKET-2896
> URL: https://issues.apache.org/jira/browse/WICKET-2896
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
>Affects Versions: 1.4.8
>Reporter: nicolas de loof
>Assignee: Peter Ertl
>Priority: Trivial
> Fix For: 1.5-M4
>
>
> Trying to extend SortableDataProvider to support multiple sorting criteria
> (based on http://www.mail-archive.com/users@wicket.apache.org/msg14246.html),
> the ordering feature on DataTable cannot be used to get back to the "NONE"
> state. A simple change in OrderByLink can be used to fix this :
> int newDir = ISortState.NONE;
> if ( oldDir == ISortState.NONE )
> {
> newDir = ISortState.ASCENDING;
> }
> if ( oldDir == ISortState.ASCENDING )
> {
> newDir = ISortState.DESCENDING;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-3273) Redo Componet's internal data and ModelImpl methods
[
https://issues.apache.org/jira/browse/WICKET-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Thomerson closed WICKET-3273.
Resolution: Won't Fix
I also don't agree with the proposed changes (and am glad that Richard
acknowledged that we wouldn't in his initial submission). Reasons: same as
Igor's.
Additionally, find it odd that you did this to avoid casting, and in your
example, you don't use generics for the model, and you cast there :)
> Redo Componet's internal data and ModelImpl methods
> ---
>
> Key: WICKET-3273
> URL: https://issues.apache.org/jira/browse/WICKET-3273
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: all
>Reporter: Richard Emberson
>Priority: Minor
> Attachments: TestRun.java
>
>
> I am in the process of adding type parameters to Component and
> those derived classes are not parameterize so that I can
> get strong typing when accessing a Componet's Model. To do this
> a different mechanism is needed for storing the Model object
> in the Component.
> The current "data" storage mechanism is very well optimized for
> low memory usage. The problem is that one can not use it and still
> have typed Models without casting.
> In addition, the data_* methods are not easy to understand
> nor can their data-structure algorithms be tested without
> exercising other methods (like not being able to test an
> ArrayList directly but having to all access mediated by other
> methods).
> So, for my project I've devised a data structure that allows for
> separate testing and Model strong typing (without having to
> use instanceof and casts). Access to the underlying data is
> also faster.
> I also believe that separating out the data structure is a
> good thing; IMHO, Component is rather plump.
> An attached file contains the IHolder class and implementations.
> Using the IHodler classes, the data instance variable, data_* methods
> and ModelImpl access methods become (this is the
> non-type-parameterized version):
> // why is this not private in Wicket?
> private IHolder data = EmptyHolder.instance;
> private final int data_length() {
> return data.length();
> }
> private final Object data_get(int index) {
> return data.get(index);
> }
> private final Object data_set(int index, Object object) {
> data.set(index, obj);
> }
> private final void data_add(Object object) {
> data = data.append(obj);
> }
> private final void data_insert(int position, Object object) {
> data = data.insert(position, obj);
> }
> private final Object data_remove(int position){
> data = data.remove(position);
> }
> final IModel getModelImpl() {
> return data.getModel();
> }
> final void setModelImpl(IModel model) {
> data = data.setModel(model);
> }
> Also, the use of the FLAG_MODEL_SET can be removed throughout
> the rest of Component.
> I actually do not expect the Wicket team to adapt my changes here
> since for Components with data there is an extra reference and
> with Models, yet another reference; which is to say, greater
> memory usage. But, I want strong typing, so this is what I've done.
> Oh, yes, all of the test pass (after adjusting the
> org.apache.wicket.markup.html.debug.WicketComponentTreeTest test).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-3259) Filter path is occasionally null when forwarding a request
[ https://issues.apache.org/jira/browse/WICKET-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson resolved WICKET-3259. -- Resolution: Fixed Fix Version/s: 1.4.15 > Filter path is occasionally null when forwarding a request > -- > > Key: WICKET-3259 > URL: https://issues.apache.org/jira/browse/WICKET-3259 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14, 1.5-M3 >Reporter: Jeremy Thomerson >Assignee: Jeremy Thomerson >Priority: Minor > Fix For: 1.4.15 > > Attachments: relativeurlproblem.tar.gz > > > If you have a 404 specified in your web.xml that points to some wicket page, > and that page throws a RestartResponseAtInterceptPage exception, you end up > with a NullPointerException when trying to create the URL for the page. The > NPE is because forwardUrl is not null, but filterPath is (in > ServletWebRequest#getRelativePathPrefixToWicketHandler()) > See the attached quickstart and go to > http://localhost:8080/app-context-path/mounted-pattern/akdslfjasdklfj (which > doesn't exist) to see the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3264) MetaDataEntry set method traverses metaData even after key is found and data set/cleared
[
https://issues.apache.org/jira/browse/WICKET-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Thomerson updated WICKET-3264:
-
Fix Version/s: 1.4.15
Yes, I did forget to close it. I have a bunch of cleanup stuff I'm trying to
finish today / tonight. Since it was in both branches, I have changed the fix
version to reflect this.
> MetaDataEntry set method traverses metaData even after key is found and data
> set/cleared
>
>
> Key: WICKET-3264
> URL: https://issues.apache.org/jira/browse/WICKET-3264
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: all
>Reporter: Richard Emberson
>Assignee: Jeremy Thomerson
>Priority: Trivial
> Fix For: 1.4.15, 1.5-M4
>
>
> The for-loop in the MetaDataKey set method has a break statement that is only
> called if metaData is set to null. The break statement should be after the
> set = true;
> statement.
> Why? from what I can tell, per-key, data can only be entered into the
> MetaDataEntry
> array once. The data is added only if isSet == false, and this happens only
> if the
> key is not found in the array.
> Also, he get method only returns the first entry found for a given key so
> it makes no sense to actually have more than one entry.
> So, change from:
> else
> {
> metaData = null;
> break;
> }
> }
> set = true;
> }
> to:
> else
> {
> metaData = null;
> }
> }
> set = true;
> break;
> }
> I've made the change on my copy and all of the tests pass.
> If a user is directly playing with the data Object,
> Object data = null;
> in Component rather than using the given methods, then all bets are off
> anyway.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3249) DateConverter improperly converts time, causing different results between DateField and DateTimeField
[ https://issues.apache.org/jira/browse/WICKET-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973044#action_12973044 ] Andera Del Bene commented on WICKET-3249: - Well, what you said is right but as Martin Grigorov pointed out DateTimeField uses "new StyleDateConverter(false)" so it shouldn't apply the timezone difference. Anyway, in the same test method dateField value is 'Sat Nov 06 23:00:00 CET' when we would expect ''Sat Nov 06 08:00:00 CET''. These 23 hours seem a wrong value. As I said before I think that this could be due to a problem in method convertToObject of class DataConverter. The patch I've attached solve this problem using code suggested here: http://joda-time.sourceforge.net/userguide.html#Changing_TimeZone Bye. > DateConverter improperly converts time, causing different results between > DateField and DateTimeField > - > > Key: WICKET-3249 > URL: https://issues.apache.org/jira/browse/WICKET-3249 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4.6 >Reporter: Tauren Mills >Priority: Minor > Attachments: DatePickerTest.java, fix-WICKET-DateConverter.patch, > TestDateConverter.java > > > With a DateTimeField and a DateField in a wicket form, submit the following: > DateTimeField: [ 11/06/2010 ] date, [ 0 ] hour, [ 0 ] min > DateField: [ 11/06/2010 ] date > Those should result in the same value. But look at the converted Date values, > and you'll see this: > dateTimeField: 2010-11-06T07:00:00Z > dateField: 2010-11-06T23:00:00Z > The dateTimeField value is what I'd expect - the UTC value of midnight in my > timezone on 11/6/2010. It look like dateField is just wrong and that > DateConverter isn't dealing with timezone conversions properly. Here's the > scenario: > * Server OS, Java, and Database are all configured to use UTC timezone. > * Web client is configured in America/Los_Angeles timezone (currently > UTC-08:00, or PST). > * Currently logged in member has profile configured to use > America/Los_Angeles timezone. > * Application WebClientInfo has timezone set from the user's profile, like > such: > ClientInfo ci = Session.get().getClientInfo(); > > ((WebClientInfo)ci).getProperties().setTimeZone(TimeZone.getTimeZone(member.getTimezone())); > Anywhere that dates are handled in the application with DateLabel or > DateTimeField, they seem to be properly converted by Wicket to and from > America/Los_Angeles time to UTC time for storage in the database. Examining > the database shows a 7 or 8 hour difference between the time in the UI and > the time in the database (depending on DST or not). > However, when using org.apache.wicket.extensions.yui.calendar.DateField, > dates are getting converted/persisted incorrectly. I just traced through > DateConverter.convertToObject() to see what was happening. Assume it is > currently 2010-12-10 00:43 PST(-8). My client timezone is set to PST (-8), as > is my profile timezone. I specify 2010-11-06 in the DateField. It does this: > 1. Creates a Joda value using DateMidnight right now in UTC (the date/time > right now in UTC, setting the time portion to midnight UTC. This will be a > time before now, not after now, as midnight is the first instant of a day, > not the last instant of a day). 2010-12-10T00:00:00Z > 2. Converts this Joda value to the client's timezone. > 2010-12-09T16:00:00-08:00 > 3. Joda parses the submitted text value into the Joda value. > 2010-11-06T16:00:00-07:00 > 4. Converts the Joda value to the server's timezone. 2010-11-06T23:00:00Z > The value should result in 2010-11-06T07:00:00Z, which converts to > 2010-11-06T00:00:00-08:00, or midnight on 11/6 in the PST timezone, but it > doesn't. Or am I missing something and there is a reason for this? It seems > like a bug to me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1050940 [1/2] - in /wicket/trunk/wicket-examples/src: main/java/org/apache/wicket/examples/resourcedecoration/ main/java/org/apache/wicket/examples/resourcedecoration/httpaggregation/ mai
Author: mgrigorov
Date: Sun Dec 19 20:39:29 2010
New Revision: 1050940
URL: http://svn.apache.org/viewvc?rev=1050940&view=rev
Log:
Add example of resource aggregation.
developed-by: jthomerson
adapted-to-1.5-by: mgrigorov
Added:
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/BasicGroupingKey.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/GroupedAndOrderedResourceReference.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/HomePage.css
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/HomePage.html
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/HomePage.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/HomePage.js
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/HttpAggregatingHeaderResponse.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/HttpAggregatingResourceReferenceCollection.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/MergedResourcesResource.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/ResourceDecorationApplication.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/ajax.css
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/ajax.js
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/app.css
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/footer.css
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/header.css
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/httpaggregation/
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/httpaggregation/GroupLevel.java
(with props)
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/jquery-1.4.3.min.js
(with props)
Modified:
wicket/trunk/wicket-examples/src/main/webapp/WEB-INF/web.xml
wicket/trunk/wicket-examples/src/main/webapp/index.html
wicket/trunk/wicket-examples/src/test/java/org/apache/wicket/util/license/ApacheLicenceHeaderTest.java
Added:
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/BasicGroupingKey.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/BasicGroupingKey.java?rev=1050940&view=auto
==
---
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/BasicGroupingKey.java
(added)
+++
wicket/trunk/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration/BasicGroupingKey.java
Sun Dec 19 20:39:29 2010
@@ -0,0 +1,111 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.examples.resourcedecoration;
+
+import
org.apache.wicket.examples.resourcedecoration.GroupedAndOrderedResourceReference.ResourceGroup;
+
+/**
+ * @author jthomerson
+ */
+public class BasicGroupingKey implements Comparable
+{
+
+ private final ResourceGroup group;
+ private final int loadOrder;
+ private final boolean css;
+
+ /**
+* Construct.
+*
+* @param group
+* @param loadOrder
+* @param css
+*/
+ public BasicGroupingKey(ResourceGroup group, int loadOrder, boolean css)
+ {
+ this
[jira] Commented: (WICKET-3273) Redo Componet's internal data and ModelImpl methods
[
https://issues.apache.org/jira/browse/WICKET-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973039#action_12973039
]
Igor Vaynberg commented on WICKET-3273:
---
i dont like this.
a) we do not want component to have generics for model because it is too
verbose. something we have tried and rolled back in 1.4 milestones.
b) this increases the memory significantly. two extra slots per component is
huge. the data "structure" is there to optimize space, as you have noticed. and
it is there for a reason. historically we had separate slots for models, meta,
etc, but eventually rolled them in because pages were getting too big.
> Redo Componet's internal data and ModelImpl methods
> ---
>
> Key: WICKET-3273
> URL: https://issues.apache.org/jira/browse/WICKET-3273
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: all
>Reporter: Richard Emberson
>Priority: Minor
> Attachments: TestRun.java
>
>
> I am in the process of adding type parameters to Component and
> those derived classes are not parameterize so that I can
> get strong typing when accessing a Componet's Model. To do this
> a different mechanism is needed for storing the Model object
> in the Component.
> The current "data" storage mechanism is very well optimized for
> low memory usage. The problem is that one can not use it and still
> have typed Models without casting.
> In addition, the data_* methods are not easy to understand
> nor can their data-structure algorithms be tested without
> exercising other methods (like not being able to test an
> ArrayList directly but having to all access mediated by other
> methods).
> So, for my project I've devised a data structure that allows for
> separate testing and Model strong typing (without having to
> use instanceof and casts). Access to the underlying data is
> also faster.
> I also believe that separating out the data structure is a
> good thing; IMHO, Component is rather plump.
> An attached file contains the IHolder class and implementations.
> Using the IHodler classes, the data instance variable, data_* methods
> and ModelImpl access methods become (this is the
> non-type-parameterized version):
> // why is this not private in Wicket?
> private IHolder data = EmptyHolder.instance;
> private final int data_length() {
> return data.length();
> }
> private final Object data_get(int index) {
> return data.get(index);
> }
> private final Object data_set(int index, Object object) {
> data.set(index, obj);
> }
> private final void data_add(Object object) {
> data = data.append(obj);
> }
> private final void data_insert(int position, Object object) {
> data = data.insert(position, obj);
> }
> private final Object data_remove(int position){
> data = data.remove(position);
> }
> final IModel getModelImpl() {
> return data.getModel();
> }
> final void setModelImpl(IModel model) {
> data = data.setModel(model);
> }
> Also, the use of the FLAG_MODEL_SET can be removed throughout
> the rest of Component.
> I actually do not expect the Wicket team to adapt my changes here
> since for Components with data there is an extra reference and
> with Models, yet another reference; which is to say, greater
> memory usage. But, I want strong typing, so this is what I've done.
> Oh, yes, all of the test pass (after adjusting the
> org.apache.wicket.markup.html.debug.WicketComponentTreeTest test).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3249) DateConverter improperly converts time, causing different results between DateField and DateTimeField
[ https://issues.apache.org/jira/browse/WICKET-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973037#action_12973037 ] Juergen Donnerstag commented on WICKET-3249: Isn't 'Sat Nov 06 08:00:00 CET' what you would expect? Berlin is 8 hours ahead of LA. assertEquals(date, page.dateTime) must fail because of that. > DateConverter improperly converts time, causing different results between > DateField and DateTimeField > - > > Key: WICKET-3249 > URL: https://issues.apache.org/jira/browse/WICKET-3249 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4.6 >Reporter: Tauren Mills >Priority: Minor > Attachments: DatePickerTest.java, fix-WICKET-DateConverter.patch, > TestDateConverter.java > > > With a DateTimeField and a DateField in a wicket form, submit the following: > DateTimeField: [ 11/06/2010 ] date, [ 0 ] hour, [ 0 ] min > DateField: [ 11/06/2010 ] date > Those should result in the same value. But look at the converted Date values, > and you'll see this: > dateTimeField: 2010-11-06T07:00:00Z > dateField: 2010-11-06T23:00:00Z > The dateTimeField value is what I'd expect - the UTC value of midnight in my > timezone on 11/6/2010. It look like dateField is just wrong and that > DateConverter isn't dealing with timezone conversions properly. Here's the > scenario: > * Server OS, Java, and Database are all configured to use UTC timezone. > * Web client is configured in America/Los_Angeles timezone (currently > UTC-08:00, or PST). > * Currently logged in member has profile configured to use > America/Los_Angeles timezone. > * Application WebClientInfo has timezone set from the user's profile, like > such: > ClientInfo ci = Session.get().getClientInfo(); > > ((WebClientInfo)ci).getProperties().setTimeZone(TimeZone.getTimeZone(member.getTimezone())); > Anywhere that dates are handled in the application with DateLabel or > DateTimeField, they seem to be properly converted by Wicket to and from > America/Los_Angeles time to UTC time for storage in the database. Examining > the database shows a 7 or 8 hour difference between the time in the UI and > the time in the database (depending on DST or not). > However, when using org.apache.wicket.extensions.yui.calendar.DateField, > dates are getting converted/persisted incorrectly. I just traced through > DateConverter.convertToObject() to see what was happening. Assume it is > currently 2010-12-10 00:43 PST(-8). My client timezone is set to PST (-8), as > is my profile timezone. I specify 2010-11-06 in the DateField. It does this: > 1. Creates a Joda value using DateMidnight right now in UTC (the date/time > right now in UTC, setting the time portion to midnight UTC. This will be a > time before now, not after now, as midnight is the first instant of a day, > not the last instant of a day). 2010-12-10T00:00:00Z > 2. Converts this Joda value to the client's timezone. > 2010-12-09T16:00:00-08:00 > 3. Joda parses the submitted text value into the Joda value. > 2010-11-06T16:00:00-07:00 > 4. Converts the Joda value to the server's timezone. 2010-11-06T23:00:00Z > The value should result in 2010-11-06T07:00:00Z, which converts to > 2010-11-06T00:00:00-08:00, or midnight on 11/6 in the PST timezone, but it > doesn't. Or am I missing something and there is a reason for this? It seems > like a bug to me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-3017) Add support for forward and error filter mappings
[ https://issues.apache.org/jira/browse/WICKET-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-3017. --- Resolution: Duplicate all good now i believe > Add support for forward and error filter mappings > - > > Key: WICKET-3017 > URL: https://issues.apache.org/jira/browse/WICKET-3017 > Project: Wicket > Issue Type: Improvement >Reporter: Igor Vaynberg > Fix For: 1.5-M4 > > > need to add support for javax.servlet.error.request_uri and > javax.servlet.forward.servlet_path request variables so we can properly > handle custom error pages, etc. see WICKET-1887 and WICKET-2712 for > quickstarts/examples of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1050931 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/RangeTextField.java
Author: mgrigorov
Date: Sun Dec 19 18:58:09 2010
New Revision: 1050931
URL: http://svn.apache.org/viewvc?rev=1050931&view=rev
Log:
WICKET-3241 Add support for the new HTML 5 input types
Add an component for which is just the same as 'number'.
Added:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/RangeTextField.java
(with props)
Added:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/RangeTextField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/RangeTextField.java?rev=1050931&view=auto
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/RangeTextField.java
(added)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/RangeTextField.java
Sun Dec 19 18:58:09 2010
@@ -0,0 +1,62 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.markup.html.form;
+
+import org.apache.wicket.model.IModel;
+
+/**
+ * A {...@link TextField} for HTML5 with type range.
+ *
+ *
+ * Automatically validates the input against the configured {...@link
#setMinimum(Double) min} and
+ * {...@link #setMaximum(Double) max} attributes. If any of them is
null then
+ * {...@link Double#MIN_VALUE} and {...@link Double#MAX_VALUE} are used
respectfully.
+ */
+public class RangeTextField extends NumberTextField
+{
+ private static final long serialVersionUID = 1L;
+
+ /**
+* Construct.
+*
+* @param id
+*component id
+*/
+ public RangeTextField(String id)
+ {
+ this(id, null);
+ }
+
+ /**
+* Construct.
+*
+* @param id
+*see Component
+* @param model
+*the model
+*/
+ public RangeTextField(String id, IModel model)
+ {
+ super(id, model);
+ }
+
+ @Override
+ protected String getInputType()
+ {
+ return "range";
+ }
+}
Propchange:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/RangeTextField.java
--
svn:eol-style = native
svn commit: r1050930 - in /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form: EmailTextField.java NumberTextField.java UrlTextField.java
Author: mgrigorov
Date: Sun Dec 19 18:55:45 2010
New Revision: 1050930
URL: http://svn.apache.org/viewvc?rev=1050930&view=rev
Log:
WICKET-3241 Add support for the new HTML 5 input types
Javadoc updates
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/UrlTextField.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java?rev=1050930&r1=1050929&r2=1050930&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
Sun Dec 19 18:55:45 2010
@@ -22,7 +22,7 @@ import org.apache.wicket.validation.IVal
import org.apache.wicket.validation.validator.EmailAddressValidator;
/**
- * A {...@link TextField} for HTML5 with type
email.
+ * A {...@link TextField} for HTML5 with type email.
*
*
* Automatically validates that the input is a valid email address.
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java?rev=1050930&r1=1050929&r2=1050930&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
Sun Dec 19 18:55:45 2010
@@ -22,7 +22,7 @@ import org.apache.wicket.util.value.IVal
import org.apache.wicket.validation.validator.RangeValidator;
/**
- * A {...@link TextField} for HTML5 with type
number.
+ * A {...@link TextField} for HTML5 with type number.
*
*
* Automatically validates the input against the configured {...@link
#setMinimum(Double) min} and
@@ -56,7 +56,7 @@ public class NumberTextField extends Tex
* @param id
*see Component
* @param model
-*the model
+*the input value
*/
public NumberTextField(String id, IModel model)
{
@@ -68,6 +68,8 @@ public class NumberTextField extends Tex
}
/**
+* Sets the minimum allowed value
+*
* @param minimum
*the minimum allowed value
* @return this instance
@@ -79,6 +81,8 @@ public class NumberTextField extends Tex
}
/**
+* Sets the maximum allowed value
+*
* @param maximum
*the maximum allowed value
* @return this instance
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/UrlTextField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/UrlTextField.java?rev=1050930&r1=1050929&r2=1050930&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/UrlTextField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/UrlTextField.java
Sun Dec 19 18:55:45 2010
@@ -21,7 +21,7 @@ import org.apache.wicket.model.Model;
import org.apache.wicket.validation.validator.UrlValidator;
/**
- * A {...@link TextField} for HTML5 with type
url.
+ * A {...@link TextField} for HTML5 with type url.
*
*
* Automatically validates the input that it is a valid Url.
@@ -47,16 +47,30 @@ public class UrlTextField extends TextFi
* Construct.
*
* @param id
-*see Component
+*the component id
* @param model
-*the model
+*the input value
*/
public UrlTextField(String id, IModel model)
{
+ this(id, model, new UrlValidator());
+ }
+
+ /**
+* Construct.
+*
+* @param id
+*the component id
+* @param model
+*the input value
+* @param urlValidator
+*the validator that will check the correctness of the
input value
+*/
+ public UrlTextField(String id, IModel model, UrlValidator
urlValidator)
+ {
super(id, model, String.class);
- // XXX does this validator needs UrlValidator#options ?!
- add(new UrlValidator());
+
[jira] Commented: (WICKET-3269) Review AbstractTextComponent's handling of empty Strings in 1.5
[ https://issues.apache.org/jira/browse/WICKET-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973033#action_12973033 ] Juergen Donnerstag commented on WICKET-3269: I tend to agree with Sven. If needed users can create their own Converter > Review AbstractTextComponent's handling of empty Strings in 1.5 > --- > > Key: WICKET-3269 > URL: https://issues.apache.org/jira/browse/WICKET-3269 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M3 >Reporter: Sven Meier > Attachments: AbstractTextComponent_A.diff, > AbstractTextComponent_B.diff, WICKET-3269-test.patch, WICKET-3269.patch > > > Context: > With convertEmptyInputStringToNull set to 'true' (the default), > AbstractTextComponent converts empty strings to 'null'. > This works only if the component doesn't know its model type. > Problem: > In our application we would like to always keep empty Strings as they are. We > tried to use a ComponentInstantiationListener to set > convertEmptyInputStringToNull to 'false', but regretfully > AbstractTextComponent reverts this setting to 'true' in its constructor. > Proposals for 1.5 (either A or B): > A) Change default of convertEmptyInputStringToNull to 'false'. > - allows applications to keep empty strings as they are, > - if needed, clients can use a ComponentInstantiationListener to globally set > convertEmptyInputStringToNull to 'true' for the old default > B) Remove support for special handling of empty strings. > - no special handling in #convertValue(String[]) and #resolveType() needed, > - no more ambiguity whether ConvertEmptyInputStringToNull has any effect > (model type known or not), > - if needed, clients can use a custom Converter to convert empty strings to > 'null'. > See attached patches, note that no unit tests changes were required. > Thanks for your consideration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973030#action_12973030 ] James Carman commented on WICKET-3274: -- Agreed > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973029#action_12973029 ] Sebastian commented on WICKET-3274: --- Event handling, may it be application wide or between specific component instances is basically "just" about routing messages from senders to receivers. I believe a good designed generic event handling solution should work for both use cases. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket > Migration to Wicket 1.5
Migration to Wicket 1.5
Page edited by Martin Grigorov
Changes (1)
...
{code}
h3. (M4) Resource decoration With org.apache.wicket.Application.setHeaderResponseDecorator(IHeaderResponseDecorator) it is possible to intercept the contribution of resources. This way you may specify which resources will be contributed to the part of the page and which will be contributed to the end (after ). Or you may merge several contributions into a bigger one. For more information consult with [Resource decoration|https://cwiki.apache.org/confluence/x/lx1xAQ]
h3. RequestCycle
...
Full Content
Migrating to Wicket 1.5
Environment
Upgraded to JUNIT4
Removed deprecated method, class and interface definitions
Removed FormComponent.setPersistence()
Removed IComponentBorder
Component.getStyle() implementation changed
Removed magic from Border Component
Component rendering
UTF-8 encoded property files
XML based property files
TabbedPanel
MarkupContainer.isTransparentResolver() removed
IComponentResolver.resolve API has changed
Wicket-IOC changes
Visitors
Component Initialization - Component#onInitialize
Request parameters
Switching to/from secured communication over https
HeaderContribution
Component and IBehavior implement IHeaderContributor
Removed HeaderContributor and friends.
(M4) Resource decoration
RequestCycle
Exception handling
ImageMap removed
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() has been replaced
Inter-component events
IEventDispatcher
Default ajax event
(M4) Header render sequence inverted
(M4) WicketTester.startPanel() and WicketTester.assertLabel()
(M4) IBehavior interface refactored to abstract class Behavior
(M4) Added support for 'x-forwarded-for' headers and more
List of renamed classes and methods
Environment
Wicket 1.5 requires at least Java 5
Upgraded to JUNIT4
We changed the root pom.xml to use junit4 (4.7)
Removed deprecated method, class and interface definitions
In order to keep the code clean, we removed all methods, classes and interfaces which were marked deprecated in Wicket 1.4. Before migrating to Wicket 1.5 you should replace all deprecated invocations.
Removed FormComponent.setPersistence()
WICKET-2213: At the very beginning of Wicket we introduced FormComponent.setPersistence() with the idea to make creating Login panels very easy. Basically Wicket would deal with the Cookie handling for the login details. Now some years later it is evident that this feature is not very useful:
It basically is used for login panels only
Even in our examples Password.setPersistence is false which means that "rememberMe" doesn't really work. Only the user name is stored in a Cookie
Forcing formComponent.getPageRelativePath() as the Cookie name is too restrictive
You can not combine username and password into a single Cookie and e.g. decrypt it for safety reasons
So we removed that feature and introduced IAuthenticationStrategy. A default implementation has been provided and the examples have been updated. As usual it gets registered with ISecuritySettings.
In case you want to implement your own IAuthenticationStrategy, a utility class org.apache.wicket.util.cookies.CookieUtils has been added.
Removed IComponentBorder
The interface has been removed since IBehavior can do exactly the same. MarkupComponentBorder has been migrated, which means you can add associated markup to the behavior. Markup which will surround the behavior's component.
Component.getStyle() implementation changed
getStyle() used to return Component.getVariation() + "_" + style. That eventually caused issue such as mentioned in WICKET-2298.
We changed that to getStyle() now returning style only which as a consequence required us to change all resource related APIs to add variation. To migrate your code you might either provide component.getVariation() or null where not relevant.
Removed magic from Border Component
We had several issues with Border such as WICKET-2494 and the fact that all over core you could find code such as "if (comp instanceof Border) {}" . That is now all fixed, though at a (low) price. Because the magic is now gone, we think it is even clearer than it was before. The difference is you have to tell Border where to add the child component. Whether it will be added to .. which is called the "border", or .. which called the "border body". And because the body can be wrapped by a container such as a Form, you need to add (move) the body to the wrapper component via wrapper.add(getBodyContainer()) if needed. By doing so you create a clean component hierarchy with no more magic and ambigu
[jira] Commented: (WICKET-3249) DateConverter improperly converts time, causing different results between DateField and DateTimeField
[
https://issues.apache.org/jira/browse/WICKET-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973014#action_12973014
]
Andera Del Bene commented on WICKET-3249:
-
Hi Juergen,
I've attached a new version of DatePickerTest with my test method test3. The
method is similar to test2 but I added timezone for JVM (Europe/Berlin) and
timezone for client session (America/Los_Angeles).
With these conditions test3 fails because dateTime value is 'Sat Nov 06
08:00:00 CET'. It seems that method convertInput of class DateTimeField
applies always timezone difference with these istructions:
TimeZone zone = getClientTimeZone();
if (zone != null)
{
date.setMillis(getMillis(zone, TimeZone.getDefault(),
date.getMillis()));
}
> DateConverter improperly converts time, causing different results between
> DateField and DateTimeField
> -
>
> Key: WICKET-3249
> URL: https://issues.apache.org/jira/browse/WICKET-3249
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
>Affects Versions: 1.4.6
>Reporter: Tauren Mills
>Priority: Minor
> Attachments: DatePickerTest.java, fix-WICKET-DateConverter.patch,
> TestDateConverter.java
>
>
> With a DateTimeField and a DateField in a wicket form, submit the following:
> DateTimeField: [ 11/06/2010 ] date, [ 0 ] hour, [ 0 ] min
> DateField: [ 11/06/2010 ] date
> Those should result in the same value. But look at the converted Date values,
> and you'll see this:
> dateTimeField: 2010-11-06T07:00:00Z
> dateField: 2010-11-06T23:00:00Z
> The dateTimeField value is what I'd expect - the UTC value of midnight in my
> timezone on 11/6/2010. It look like dateField is just wrong and that
> DateConverter isn't dealing with timezone conversions properly. Here's the
> scenario:
> * Server OS, Java, and Database are all configured to use UTC timezone.
> * Web client is configured in America/Los_Angeles timezone (currently
> UTC-08:00, or PST).
> * Currently logged in member has profile configured to use
> America/Los_Angeles timezone.
> * Application WebClientInfo has timezone set from the user's profile, like
> such:
> ClientInfo ci = Session.get().getClientInfo();
>
> ((WebClientInfo)ci).getProperties().setTimeZone(TimeZone.getTimeZone(member.getTimezone()));
> Anywhere that dates are handled in the application with DateLabel or
> DateTimeField, they seem to be properly converted by Wicket to and from
> America/Los_Angeles time to UTC time for storage in the database. Examining
> the database shows a 7 or 8 hour difference between the time in the UI and
> the time in the database (depending on DST or not).
> However, when using org.apache.wicket.extensions.yui.calendar.DateField,
> dates are getting converted/persisted incorrectly. I just traced through
> DateConverter.convertToObject() to see what was happening. Assume it is
> currently 2010-12-10 00:43 PST(-8). My client timezone is set to PST (-8), as
> is my profile timezone. I specify 2010-11-06 in the DateField. It does this:
> 1. Creates a Joda value using DateMidnight right now in UTC (the date/time
> right now in UTC, setting the time portion to midnight UTC. This will be a
> time before now, not after now, as midnight is the first instant of a day,
> not the last instant of a day). 2010-12-10T00:00:00Z
> 2. Converts this Joda value to the client's timezone.
> 2010-12-09T16:00:00-08:00
> 3. Joda parses the submitted text value into the Joda value.
> 2010-11-06T16:00:00-07:00
> 4. Converts the Joda value to the server's timezone. 2010-11-06T23:00:00Z
> The value should result in 2010-11-06T07:00:00Z, which converts to
> 2010-11-06T00:00:00-08:00, or midnight on 11/6 in the PST timezone, but it
> doesn't. Or am I missing something and there is a reason for this? It seems
> like a bug to me.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3249) DateConverter improperly converts time, causing different results between DateField and DateTimeField
[ https://issues.apache.org/jira/browse/WICKET-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andera Del Bene updated WICKET-3249: Attachment: DatePickerTest.java > DateConverter improperly converts time, causing different results between > DateField and DateTimeField > - > > Key: WICKET-3249 > URL: https://issues.apache.org/jira/browse/WICKET-3249 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4.6 >Reporter: Tauren Mills >Priority: Minor > Attachments: DatePickerTest.java, fix-WICKET-DateConverter.patch, > TestDateConverter.java > > > With a DateTimeField and a DateField in a wicket form, submit the following: > DateTimeField: [ 11/06/2010 ] date, [ 0 ] hour, [ 0 ] min > DateField: [ 11/06/2010 ] date > Those should result in the same value. But look at the converted Date values, > and you'll see this: > dateTimeField: 2010-11-06T07:00:00Z > dateField: 2010-11-06T23:00:00Z > The dateTimeField value is what I'd expect - the UTC value of midnight in my > timezone on 11/6/2010. It look like dateField is just wrong and that > DateConverter isn't dealing with timezone conversions properly. Here's the > scenario: > * Server OS, Java, and Database are all configured to use UTC timezone. > * Web client is configured in America/Los_Angeles timezone (currently > UTC-08:00, or PST). > * Currently logged in member has profile configured to use > America/Los_Angeles timezone. > * Application WebClientInfo has timezone set from the user's profile, like > such: > ClientInfo ci = Session.get().getClientInfo(); > > ((WebClientInfo)ci).getProperties().setTimeZone(TimeZone.getTimeZone(member.getTimezone())); > Anywhere that dates are handled in the application with DateLabel or > DateTimeField, they seem to be properly converted by Wicket to and from > America/Los_Angeles time to UTC time for storage in the database. Examining > the database shows a 7 or 8 hour difference between the time in the UI and > the time in the database (depending on DST or not). > However, when using org.apache.wicket.extensions.yui.calendar.DateField, > dates are getting converted/persisted incorrectly. I just traced through > DateConverter.convertToObject() to see what was happening. Assume it is > currently 2010-12-10 00:43 PST(-8). My client timezone is set to PST (-8), as > is my profile timezone. I specify 2010-11-06 in the DateField. It does this: > 1. Creates a Joda value using DateMidnight right now in UTC (the date/time > right now in UTC, setting the time portion to midnight UTC. This will be a > time before now, not after now, as midnight is the first instant of a day, > not the last instant of a day). 2010-12-10T00:00:00Z > 2. Converts this Joda value to the client's timezone. > 2010-12-09T16:00:00-08:00 > 3. Joda parses the submitted text value into the Joda value. > 2010-11-06T16:00:00-07:00 > 4. Converts the Joda value to the server's timezone. 2010-11-06T23:00:00Z > The value should result in 2010-11-06T07:00:00Z, which converts to > 2010-11-06T00:00:00-08:00, or midnight on 11/6 in the PST timezone, but it > doesn't. Or am I missing something and there is a reason for this? It seems > like a bug to me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972997#action_12972997 ] James Carman commented on WICKET-3274: -- Well, it looks like they're trying to address two different problems. WICKET-1312 seems to be trying to address loosely-coupled, inter-component communication. This aims to be more of a lifecycle event communication mechanism for the overall framework. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972994#action_12972994 ] Sebastian commented on WICKET-3274: --- Is this JIRA about extending the event mechanism introduced with WICKET-1312 or implementing a completely new one? If the latter is the case is it supposed to replace WICKET-1312 or coexist with it? I'd like to see only a single event API in Wicket. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972992#action_12972992 ] James Carman commented on WICKET-3274: -- We may also need to introduce the concept of a "chain" here (like we had in HiveMind). Basically, a "chain" would allow you to have non-void return types. We return the first non-default return value from the items in the chain. So, the exception handling stuff would be a chain, since we have to get an IRequestHandler return value. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1050848 - in /wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket: WicketTestCase.java extensions/yui/calendar/DatePickerTest.java
Author: jdonnerstag
Date: Sun Dec 19 13:41:27 2010
New Revision: 1050848
URL: http://svn.apache.org/viewvc?rev=1050848&view=rev
Log:
enabled tests in wicket-datetime
Added:
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/WicketTestCase.java
Modified:
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java
Added:
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/WicketTestCase.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/WicketTestCase.java?rev=1050848&view=auto
==
---
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/WicketTestCase.java
(added)
+++
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/WicketTestCase.java
Sun Dec 19 13:41:27 2010
@@ -0,0 +1,147 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket;
+
+import junit.framework.TestCase;
+
+import org.apache.wicket.behavior.AbstractAjaxBehavior;
+import org.apache.wicket.request.mapper.parameter.PageParameters;
+import org.apache.wicket.util.tester.WicketTester;
+
+/**
+ * Base class for tests which require comparing wicket response with a file.
+ *
+ * To create/replace the expected result file with the new content, define the
system property like
+ * -Dwicket.replace.expected.results=true
+ *
+ */
+public abstract class WicketTestCase extends TestCase
+{
+ /** */
+ public WicketTester tester;
+
+ @Override
+ protected void setUp() throws Exception
+ {
+ tester = new WicketTester();
+ }
+
+ @Override
+ protected void tearDown() throws Exception
+ {
+ tester.destroy();
+ }
+
+
+ /**
+* Use -Dwicket.replace.expected.results=true to
automatically replace the expected
+* output file.
+*
+* @param
+*
+* @param pageClass
+* @param filename
+* @throws Exception
+*/
+ protected void executeTest(final Class pageClass,
final String filename)
+ throws Exception
+ {
+ System.out.println("=== " + pageClass.getName() + " ===");
+
+ tester.startPage(pageClass);
+ tester.assertRenderedPage(pageClass);
+ tester.assertResultPage(getClass(), filename);
+ }
+
+ /**
+* Use -Dwicket.replace.expected.results=true to
automatically replace the expected
+* output file.
+*
+* @param
+*
+* @param pageClass
+* @param parameters
+* @param filename
+* @throws Exception
+*/
+ protected void executeTest(final Class pageClass,
+ PageParameters parameters, final String filename) throws
Exception
+ {
+ System.out.println("=== " + pageClass.getName() + " ===");
+
+ tester.startPage(pageClass, parameters);
+ tester.assertRenderedPage(pageClass);
+ tester.assertResultPage(getClass(), filename);
+ }
+
+ /**
+*
+* @param clazz
+* @param component
+* @param filename
+* @throws Exception
+*/
+ protected void executedListener(final Class clazz, final Component
component,
+ final String filename) throws Exception
+ {
+ assertNotNull(component);
+
+ System.out.println("=== " + clazz.getName() + " : " +
component.getPageRelativePath() +
+ " ===");
+
+ tester.executeListener(component);
+ tester.assertResultPage(clazz, filename);
+ }
+
+ /**
+*
+* @param clazz
+* @param behavior
+* @param filename
+* @throws Exception
+*/
+ protected void executedBehavior(final Class clazz, final
AbstractAjaxBehavior behavior,
+ final String filename) throws Exception
+ {
+ assertNotNull(behavior);
+
+ System.out.println("=== " + clazz.getName() + " : " +
behavior.toString() + " ===")
[jira] Reopened: (WICKET-3268) Can't generate 1.5-SNAPSHOT project with the quickstart command
[
https://issues.apache.org/jira/browse/WICKET-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov reopened WICKET-3268:
-
May I ask someone with working jekyll to touch the mvn lines in our docs and
replace -DremoteRepositories with -DarchetypeRepository.
jekyll stopped working locally with my version of Ruby (1.9.1).
Index: start/quickstart.md
===
--- start/quickstart.md (revision 1050846)
+++ start/quickstart.md (working copy)
@@ -42,7 +42,8 @@
else
cmd = 'mvn archetype:generate
-DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=' +
version + ' -DgroupId=' + groupId + ' -DartifactId=' + artifactId;
- if (version.match(/.*SNAPSHOT/)) cmd += '
-DremoteRepositories=http://wicketstuff.org/maven/repository/';
+ if (version.match(/.*SNAPSHOT/)) cmd += '
-DarchetypeRepository=http://wicketstuff.org/maven/repository/';
+ cmd += ' -DinteractiveMode=false';
document.getElementById("cmdLine").value = cmd;
}
Additionally I added the property 'interactiveMode=false' that will save the
user two questions.
> Can't generate 1.5-SNAPSHOT project with the quickstart command
> ---
>
> Key: WICKET-3268
> URL: https://issues.apache.org/jira/browse/WICKET-3268
> Project: Wicket
> Issue Type: Bug
> Components: wicket-quickstart
>Reporter: Major Peter
> Fix For: 1.5-M4
>
>
> Currently the command on Wicket site
> (http://wicket.apache.org/start/quickstart.html) is not working with
> 1.5-SNAPSHOT, because the archetype plugin does not care about the
> remoteRepositories parameter
> (http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html).
> Instead it will always generate 1.5-M3 quickstart. (at least this is the
> behavior with Maven 3.0.1)
> The solution is to use the following command:
> mvn archetype:generate -DarchetypeGroupId=org.apache.wicket
> -DarchetypeArtifactId=wicket-archetype-quickstart
> -DarchetypeVersion=1.5-SNAPSHOT -DgroupId=com.mycompany
> -DartifactId=myproject -DinteractiveMode=false
> -DarchetypeRepository=http://wicketstuff.org/maven/repository/
> note the extra -DinteractiveMode=false parameter, which can speed up the
> projectgeneration. ;)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972985#action_12972985 ] James Carman commented on WICKET-3274: -- The proxy stuff isn't really that bad in this case. The proxies aren't used to do drastic, crazy logic. All they're used for is to dispatch the events to all registered listeners, allowing you to merely call the listener method you want with the arguments you want and it will be multicast out to all of the registered listeners. As for the unregister part, I don't really see where you would need to unregister these types of listeners. This is for application-level, cross-cutting concerns, basically all of the "hooks" where plugin/framework developers would need to be able to integrate. Right now, this is very difficult because you have to override factory methods or (with providers) do some sort of wrapping/decorating to allow more than one framework to join in. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3017) Add support for forward and error filter mappings
[ https://issues.apache.org/jira/browse/WICKET-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972984#action_12972984 ] Juergen Donnerstag commented on WICKET-3017: Igor, can this be closed or we do need something else? > Add support for forward and error filter mappings > - > > Key: WICKET-3017 > URL: https://issues.apache.org/jira/browse/WICKET-3017 > Project: Wicket > Issue Type: Improvement >Reporter: Igor Vaynberg > Fix For: 1.5-M4 > > > need to add support for javax.servlet.error.request_uri and > javax.servlet.forward.servlet_path request variables so we can properly > handle custom error pages, etc. see WICKET-1887 and WICKET-2712 for > quickstarts/examples of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3036) Remove dependancy on Java.AWT.*, Javax.Swing.*. classes
[ https://issues.apache.org/jira/browse/WICKET-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Donnerstag updated WICKET-3036: --- Attachment: wicket-3036.patch patch for trunk which introduces a new subproject wicket-awt where I moved all java.awt and javax.swing code to > Remove dependancy on Java.AWT.*, Javax.Swing.*. classes > --- > > Key: WICKET-3036 > URL: https://issues.apache.org/jira/browse/WICKET-3036 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-examples >Affects Versions: 1.4.11, 1.5-M1 >Reporter: Clint Checketts >Priority: Minor > Attachments: wicket-3036.patch > > > Instead of leveraging the existing classes in Java.AWT.*, Javax.Swing.* > Wicket could create its own equivalents or repackage the existing ones. > The motivation behind this is that Google's App Engine blacklists those > packages for web development. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3273) Redo Componet's internal data and ModelImpl methods
[
https://issues.apache.org/jira/browse/WICKET-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Emberson updated WICKET-3273:
-
Description:
I am in the process of adding type parameters to Component and
those derived classes are not parameterize so that I can
get strong typing when accessing a Componet's Model. To do this
a different mechanism is needed for storing the Model object
in the Component.
The current "data" storage mechanism is very well optimized for
low memory usage. The problem is that one can not use it and still
have typed Models without casting.
In addition, the data_* methods are not easy to understand
nor can their data-structure algorithms be tested without
exercising other methods (like not being able to test an
ArrayList directly but having to all access mediated by other
methods).
So, for my project I've devised a data structure that allows for
separate testing and Model strong typing (without having to
use instanceof and casts). Access to the underlying data is
also faster.
I also believe that separating out the data structure is a
good thing; IMHO, Component is rather plump.
An attached file contains the IHolder class and implementations.
Using the IHodler classes, the data instance variable, data_* methods
and ModelImpl access methods become (this is the
non-type-parameterized version):
// why is this not private in Wicket?
private IHolder data = EmptyHolder.instance;
private final int data_length() {
return data.length();
}
private final Object data_get(int index) {
return data.get(index);
}
private final Object data_set(int index, Object object) {
data.set(index, obj);
}
private final void data_add(Object object) {
data = data.append(obj);
}
private final void data_insert(int position, Object object) {
data = data.insert(position, obj);
}
private final Object data_remove(int position){
data = data.remove(position);
}
final IModel getModelImpl() {
return data.getModel();
}
final void setModelImpl(IModel model) {
data = data.setModel(model);
}
Also, the use of the FLAG_MODEL_SET can be removed throughout
the rest of Component.
I actually do not expect the Wicket team to adapt my changes here
since for Components with data there is an extra reference and
with Models, yet another reference; which is to say, greater
memory usage. But, I want strong typing, so this is what I've done.
Oh, yes, all of the test pass (after adjusting the
org.apache.wicket.markup.html.debug.WicketComponentTreeTest test).
was:
I am in the process of adding type parameters to Component and
those derived classes are not parameterize so that I can
get strong typing when accessing a Componet's Model. To do this
a different mechanism is needed for storing the Model object
in the Component.
The current "data" storage mechanism is very well optimized for
low memory usage. The problem is that one can not use it and still
have typed Models without casting.
In addition, the data_* methods are not easy to understand
nor can their data-structure algorithms be tested without
exercising other methods (like not being able to test an
ArrayList directly but having to all access mediated by other
methods).
So, for my project I've devised a data structure that allows for
separate testing and Model strong typing (without having to
use instanceof and casts). Access to the underlying data is
also faster.
I also believe that separating out the data structure is a
good thing; IMHO, Component is rather plumb.
An attached file contains the IHolder class and implementations.
Using the IHodler classes, the data instance variable, data_* methods
and ModelImpl access methods become (this is the
non-type-parameterized version):
// why is this not private in Wicket?
private IHolder data = EmptyHolder.instance;
private final int data_length() {
return data.length();
}
private final Object data_get(int index) {
return data.get(index);
}
private final Object data_set(int index, Object object) {
data.set(index, obj);
}
private final void data_add(Object object) {
data = data.append(obj);
}
private final void data_insert(int position, Object object) {
data = data.insert(position, obj);
}
private final Object data_remove(int position){
data = data.remove(position);
}
final IModel getModelImpl() {
return data.getModel();
}
final void setModelImpl(IModel model) {
data = data.setModel(model);
}
Also, the use of the FLAG_MODEL_SET can be removed throughout
the rest of Component.
I actually do not expect the Wicket team to adapt my changes here
since for Components with data there is an extra reference and
with Models, yet another reference; which is to say, greater
memory usage. But, I want strong typing, so this is what I've done.
Oh, yes, all of the test pass (after adjusting the
org.apache.wicket.mark
[jira] Resolved: (WICKET-3268) Can't generate 1.5-SNAPSHOT project with the quickstart command
[ https://issues.apache.org/jira/browse/WICKET-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov resolved WICKET-3268. - Resolution: Cannot Reproduce Fix Version/s: 1.5-M4 Everything is working here. I tried with and without -DinteractiveMode=false and it generates a project with dependency to 1.5-SNAPSHOT without any problems. I deleted locally ~/.m2/repository/org/apache/wicket/wicket-archetype-quickstart and it was downloaded from http://wicketstuff.org/maven/repository/org/apache/wicket/wicket-archetype-quickstart/1.5-SNAPSHOT/wicket-archetype-quickstart-1.5-SNAPSHOT.jar. Please reopen with more details if you still have the problem. > Can't generate 1.5-SNAPSHOT project with the quickstart command > --- > > Key: WICKET-3268 > URL: https://issues.apache.org/jira/browse/WICKET-3268 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Reporter: Major Peter > Fix For: 1.5-M4 > > > Currently the command on Wicket site > (http://wicket.apache.org/start/quickstart.html) is not working with > 1.5-SNAPSHOT, because the archetype plugin does not care about the > remoteRepositories parameter > (http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html). > Instead it will always generate 1.5-M3 quickstart. (at least this is the > behavior with Maven 3.0.1) > The solution is to use the following command: > mvn archetype:generate -DarchetypeGroupId=org.apache.wicket > -DarchetypeArtifactId=wicket-archetype-quickstart > -DarchetypeVersion=1.5-SNAPSHOT -DgroupId=com.mycompany > -DartifactId=myproject -DinteractiveMode=false > -DarchetypeRepository=http://wicketstuff.org/maven/repository/ > note the extra -DinteractiveMode=false parameter, which can speed up the > projectgeneration. ;) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1050791 - /wicket/trunk/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
Author: mgrigorov
Date: Sun Dec 19 10:29:57 2010
New Revision: 1050791
URL: http://svn.apache.org/viewvc?rev=1050791&view=rev
Log:
WICKET-3262 MountedMapper defined in WicketApplication doesn't accept
/mount/paramval0/paramval1
Remove WicketApplication's constructor and replace it with
WicketApplication#init().
This way users will not confuse to add configuration settings in the
constructor which will be later overridden in Application#internalInit()
Modified:
wicket/trunk/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
Modified:
wicket/trunk/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java?rev=1050791&r1=1050790&r2=1050791&view=diff
==
---
wicket/trunk/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
(original)
+++
wicket/trunk/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
Sun Dec 19 10:29:57 2010
@@ -8,20 +8,24 @@ import org.apache.wicket.protocol.http.W
* @see ${package}.Start#main(String[])
*/
public class WicketApplication extends WebApplication
-{
-/**
- * Constructor
- */
- public WicketApplication()
- {
- }
-
+{
/**
* @see org.apache.wicket.Application#getHomePage()
*/
+ @Override
public Class getHomePage()
{
return HomePage.class;
}
+ /**
+* @see org.apache.wicket.Application#init()
+*/
+ @Override
+ public void init()
+ {
+ super.init();
+
+ // add your configuration here
+ }
}
svn commit: r1050788 - /wicket/trunk/pom.xml
Author: mgrigorov Date: Sun Dec 19 10:10:58 2010 New Revision: 1050788 URL: http://svn.apache.org/viewvc?rev=1050788&view=rev Log: Remove the profile for Bamboo. AFAIK this profile was used once in wicketstuff.org. Now both wicketstuff.org and official Apache CI are Hudson. Modified: wicket/trunk/pom.xml Modified: wicket/trunk/pom.xml URL: http://svn.apache.org/viewvc/wicket/trunk/pom.xml?rev=1050788&r1=1050787&r2=1050788&view=diff == --- wicket/trunk/pom.xml (original) +++ wicket/trunk/pom.xml Sun Dec 19 10:10:58 2010 @@ -37,70 +37,6 @@ - bamboo - - false - - - wicket -wicket-util - wicket-datetime -wicket-request - wicket-devutils - wicket-extensions - wicket-ioc - wicket-spring - wicket-velocity - wicket-auth-roles - wicket-guice - wicket-jmx - wicket-objectssizeof-agent - wicket-examples - archetypes/quickstart - - - - - org.apache.maven.plugins - maven-assembly-plugin - true - - - maven-remote-resources-plugin - true - - - org.apache.maven.plugins - maven-javadoc-plugin - true - - - org.apache.maven.plugins - maven-source-plugin - true - - - org.apache.maven.plugins - maven-surefire-plugin - true - - - org.apache.felix - maven-bundle-plugin - true - - - - - - repo - Local Bamboo/Tomcat repository - file:/home/wicket/tomcat/webapps/maven/repository/ - false - - - - release false
svn commit: r1050785 - /wicket/trunk/pom.xml
Author: mgrigorov Date: Sun Dec 19 10:05:06 2010 New Revision: 1050785 URL: http://svn.apache.org/viewvc?rev=1050785&view=rev Log: Change the CI info Modified: wicket/trunk/pom.xml Modified: wicket/trunk/pom.xml URL: http://svn.apache.org/viewvc/wicket/trunk/pom.xml?rev=1050785&r1=1050784&r2=1050785&view=diff == --- wicket/trunk/pom.xml (original) +++ wicket/trunk/pom.xml Sun Dec 19 10:05:06 2010 @@ -293,8 +293,8 @@ http://issues.apache.org/jira/browse/WICKET - bamboo - http://wicketstuff.org/bamboo + hudson + https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/ scm:svn:http://svn.apache.org/repos/asf/wicket/releases/1.5-SNAPSHOT
svn commit: r1050781 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/event/IEventSource.java
Author: mgrigorov Date: Sun Dec 19 09:47:55 2010 New Revision: 1050781 URL: http://svn.apache.org/viewvc?rev=1050781&view=rev Log: Fix a typo in javadoc Modified: wicket/trunk/wicket/src/main/java/org/apache/wicket/event/IEventSource.java Modified: wicket/trunk/wicket/src/main/java/org/apache/wicket/event/IEventSource.java URL: http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/event/IEventSource.java?rev=1050781&r1=1050780&r2=1050781&view=diff == --- wicket/trunk/wicket/src/main/java/org/apache/wicket/event/IEventSource.java (original) +++ wicket/trunk/wicket/src/main/java/org/apache/wicket/event/IEventSource.java Sun Dec 19 09:47:55 2010 @@ -27,7 +27,7 @@ public interface IEventSource * Sends an event * * @param -*tyep of payload +*type of payload * * @param sink *object that will receive the event
svn commit: r1050780 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/validation/ValidatorAdapter.java
Author: mgrigorov
Date: Sun Dec 19 09:46:01 2010
New Revision: 1050780
URL: http://svn.apache.org/viewvc?rev=1050780&view=rev
Log:
WICKET-3241 Add support for the new HTML 5 input types
Add a check for null when adapting a validator as a behavior
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/validation/ValidatorAdapter.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/validation/ValidatorAdapter.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/validation/ValidatorAdapter.java?rev=1050780&r1=1050779&r2=1050780&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/validation/ValidatorAdapter.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/validation/ValidatorAdapter.java
Sun Dec 19 09:46:01 2010
@@ -17,6 +17,7 @@
package org.apache.wicket.validation;
import org.apache.wicket.behavior.Behavior;
+import org.apache.wicket.util.lang.Args;
/**
* Adapts {...@link IValidator} to Behavior
@@ -39,6 +40,8 @@ public class ValidatorAdapter extends
*/
public ValidatorAdapter(IValidator validator)
{
+ Args.notNull(validator, "validator");
+
this.validator = validator;
}
svn commit: r1050779 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
Author: mgrigorov
Date: Sun Dec 19 09:43:30 2010
New Revision: 1050779
URL: http://svn.apache.org/viewvc?rev=1050779&view=rev
Log:
WICKET-3241 Add support for the new HTML 5 input types
Add/remove "min" and "max" html attributes depending on the set java variables
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java?rev=1050779&r1=1050778&r2=1050779&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/NumberTextField.java
Sun Dec 19 09:43:30 2010
@@ -16,7 +16,9 @@
*/
package org.apache.wicket.markup.html.form;
+import org.apache.wicket.markup.ComponentTag;
import org.apache.wicket.model.IModel;
+import org.apache.wicket.util.value.IValueMap;
import org.apache.wicket.validation.validator.RangeValidator;
/**
@@ -115,6 +117,32 @@ public class NumberTextField extends Tex
}
@Override
+ protected void onComponentTag(final ComponentTag tag)
+ {
+ super.onComponentTag(tag);
+
+ IValueMap attributes = tag.getAttributes();
+
+ if (minimum != null)
+ {
+ attributes.put("min", minimum);
+ }
+ else
+ {
+ attributes.remove("min");
+ }
+
+ if (maximum != null)
+ {
+ attributes.put("max", maximum);
+ }
+ else
+ {
+ attributes.remove("max");
+ }
+ }
+
+ @Override
protected String getInputType()
{
return "number";
svn commit: r1050778 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
Author: mgrigorov
Date: Sun Dec 19 09:43:02 2010
New Revision: 1050778
URL: http://svn.apache.org/viewvc?rev=1050778&view=rev
Log:
WICKET-3241 Add support for the new HTML 5 input types
Add a note that this component does not support "multiple" attribute for now
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java?rev=1050778&r1=1050777&r2=1050778&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
Sun Dec 19 09:43:02 2010
@@ -26,6 +26,11 @@ import org.apache.wicket.validation.vali
*
*
* Automatically validates that the input is a valid email address.
+ *
+ *
+ * Note: This component does not support
multiple values! That is
+ * cannot be validated with
the default email
+ * validator
*/
public class EmailTextField extends TextField
{
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972946#action_12972946 ] Rodolfo Hansen commented on WICKET-3274: To me, this is a more radical and over-arching change than WICKET-1312 It seems to be meant as an alternative of how the extension points are offered to framework developers... So projects like wiquery, databinder and spring can co-exist with less hassle.. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r1050777 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
Author: mgrigorov
Date: Sun Dec 19 09:27:47 2010
New Revision: 1050777
URL: http://svn.apache.org/viewvc?rev=1050777&view=rev
Log:
WICKET-3241 Add support for the new HTML 5 input types
Add possibility to register different validator for emails (e.g.
wicket-extensions' RfcCompliantEmailAddressValidator)
requested-by: Peter Major
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java?rev=1050777&r1=1050776&r2=1050777&view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/form/EmailTextField.java
Sun Dec 19 09:27:47 2010
@@ -18,6 +18,7 @@ package org.apache.wicket.markup.html.fo
import org.apache.wicket.model.IModel;
import org.apache.wicket.model.Model;
+import org.apache.wicket.validation.IValidator;
import org.apache.wicket.validation.validator.EmailAddressValidator;
/**
@@ -53,9 +54,24 @@ public class EmailTextField extends Text
*/
public EmailTextField(String id, IModel model)
{
+ this(id, model, EmailAddressValidator.getInstance());
+ }
+
+ /**
+* Construct.
+*
+* @param id
+*the component id
+* @param model
+*the input value
+* @param emailValidator
+*the validator that will check the correctness of the
input value
+*/
+ public EmailTextField(String id, IModel model,
IValidator emailValidator)
+ {
super(id, model, String.class);
- add(EmailAddressValidator.getInstance());
+ add(emailValidator);
}
@Override
@@ -63,4 +79,5 @@ public class EmailTextField extends Text
{
return "email";
}
+
}
[jira] Commented: (WICKET-3269) Review AbstractTextComponent's handling of empty Strings in 1.5
[ https://issues.apache.org/jira/browse/WICKET-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972938#action_12972938 ] Sven Meier commented on WICKET-3269: Pedro, perhaps I didn't express my intention of this feature request very well: Personally I'd be happy if the default of convertEmptyInputStringToNull could be changed to 'false' in 1.5. For Wicket it would be better if we just dropped this whole feature, in spirit of the python's zen: "There should be one-- and preferably only one --obvious way to do it." IMHO this means ""->null conversion should be done in a converter. > Review AbstractTextComponent's handling of empty Strings in 1.5 > --- > > Key: WICKET-3269 > URL: https://issues.apache.org/jira/browse/WICKET-3269 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M3 >Reporter: Sven Meier > Attachments: AbstractTextComponent_A.diff, > AbstractTextComponent_B.diff, WICKET-3269-test.patch, WICKET-3269.patch > > > Context: > With convertEmptyInputStringToNull set to 'true' (the default), > AbstractTextComponent converts empty strings to 'null'. > This works only if the component doesn't know its model type. > Problem: > In our application we would like to always keep empty Strings as they are. We > tried to use a ComponentInstantiationListener to set > convertEmptyInputStringToNull to 'false', but regretfully > AbstractTextComponent reverts this setting to 'true' in its constructor. > Proposals for 1.5 (either A or B): > A) Change default of convertEmptyInputStringToNull to 'false'. > - allows applications to keep empty strings as they are, > - if needed, clients can use a ComponentInstantiationListener to globally set > convertEmptyInputStringToNull to 'true' for the old default > B) Remove support for special handling of empty strings. > - no special handling in #convertValue(String[]) and #resolveType() needed, > - no more ambiguity whether ConvertEmptyInputStringToNull has any effect > (model type known or not), > - if needed, clients can use a custom Converter to convert empty strings to > 'null'. > See attached patches, note that no unit tests changes were required. > Thanks for your consideration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-3264) MetaDataEntry set method traverses metaData even after key is found and data set/cleared
[
https://issues.apache.org/jira/browse/WICKET-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juergen Donnerstag resolved WICKET-3264.
Resolution: Fixed
Fix Version/s: 1.5-M4
Assignee: Jeremy Thomerson
looks like Jeremy forgot to close it. Source code has been changed already.
> MetaDataEntry set method traverses metaData even after key is found and data
> set/cleared
>
>
> Key: WICKET-3264
> URL: https://issues.apache.org/jira/browse/WICKET-3264
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: all
>Reporter: Richard Emberson
>Assignee: Jeremy Thomerson
>Priority: Trivial
> Fix For: 1.5-M4
>
>
> The for-loop in the MetaDataKey set method has a break statement that is only
> called if metaData is set to null. The break statement should be after the
> set = true;
> statement.
> Why? from what I can tell, per-key, data can only be entered into the
> MetaDataEntry
> array once. The data is added only if isSet == false, and this happens only
> if the
> key is not found in the array.
> Also, he get method only returns the first entry found for a given key so
> it makes no sense to actually have more than one entry.
> So, change from:
> else
> {
> metaData = null;
> break;
> }
> }
> set = true;
> }
> to:
> else
> {
> metaData = null;
> }
> }
> set = true;
> break;
> }
> I've made the change on my copy and all of the tests pass.
> If a user is directly playing with the data Object,
> Object data = null;
> in Component rather than using the given methods, then all bets are off
> anyway.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972935#action_12972935 ] Martin Grigorov commented on WICKET-3274: - Oh, I believed this ticket is created by Rodolfo ... James, you already know about this ... > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3274) Application-Scoped EventBus
[ https://issues.apache.org/jira/browse/WICKET-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972934#action_12972934 ] Martin Grigorov commented on WICKET-3274: - This was discussed the day before yesterday in IRC between Igor Vaynberg and James Carman. James said there is exactly the same functionality in commons-lang: listener + proxy based dispatcher. Igor had concerns for both points: - proxy - hard to debug - listener - you need to unregister the listener when its sink or target gets removed Currently there is a similar functionality in 1.5: org.apache.wicket.IEventDispatcher.dispatchEvent(IEventSink, IEvent). See WICKET-1312 for more details. > Application-Scoped EventBus > --- > > Key: WICKET-3274 > URL: https://issues.apache.org/jira/browse/WICKET-3274 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M3 >Reporter: James Carman > > It would be nice if Wicket had an application-scoped "event bus" that users > could plug into to receive event notifications. Right now, there are > multiple points where you can subscribe to events (and no "global" place to > subscribe to AjaxRequestTarget.IListener events). Wouldn't it be better if > you could just do: > Application.get().getEventBus().subscribe(IRequestCycleListener.class, > myListener); > or perhaps: > Application.get().getEventBus().getChannel(IRequestCycleListener.class).subscribe(myListener); > To fire events, you would do something like: > Application.get().getEventBus().publish(IRequestCycleListener.class).onBeginRequest(requestCycle); > or > Application.get().getEventBus().getChannel(IRequestCycleListener.class).publish().onBeginRequest(requestCycle); > Or course, this approach uses proxies (the publish methods return proxies > which let you fire the events to all listeners) and I know they are > considered somewhat taboo, but I think this is a good use of them and I > really don't see how debugging this could be that difficult really. It would > only need to use JDK proxies, because we'd be dealing with listener > interfaces only. The benefit of this is that there's just one way to > publish/subscribe events in Wicket and it makes it easier for folks to "plug > in." They don't have to override a factory method somewhere to make sure > they add their listener or anything. They just ask for the bus and subscribe > by listener interface. > Now, I like the idea of subscribing to a "channel" by means of the listener > interface, but I'm open to suggestions if other folks don't really like that > idea. I like the type-safety of it. > I have some code, but I'm waiting for more discussion here before I submit a > patch. I'd have to get rid of all of the listener lists that are lying > around and start having the events published through the bus. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
