[jira] Commented: (WICKET-1652) Hard-coded quotes in xml prologue
[ https://issues.apache.org/jira/browse/WICKET-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598945#action_12598945 ] Juergen Donnerstag commented on WICKET-1652: Despite of the XML spec their might as well be a client which is not able to handle quotes. For these none standard compliant client, IMO, it would be good to support both type of quotes. May be a simple method to be subclassed if you want change the quote. I'll have a look over the weekend. Hard-coded quotes in xml prologue - Key: WICKET-1652 URL: https://issues.apache.org/jira/browse/WICKET-1652 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3, 1.4-M1 Reporter: Gwyn Evans Priority: Trivial Fix For: 1.4-M3 Attachments: Page.patch Even if you specify a prologue as: ?xml version=1.0 encoding=UTF-8? (i.e. double quoted) it gets delivered as: ?xml version='1.0' encoding='UTF-8'? XML spec says either should be acceptable but I've come across one case where it would be useful to have it use the quote char that's supplied. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1411) FormTester doesn't initialise values for RadioGroups
[
https://issues.apache.org/jira/browse/WICKET-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Shepherdson closed WICKET-1411.
-
Thank you -- I can confirm that the fix works as of the 1.3.3 release.
FormTester doesn't initialise values for RadioGroups
Key: WICKET-1411
URL: https://issues.apache.org/jira/browse/WICKET-1411
Project: Wicket
Issue Type: Bug
Affects Versions: 1.3.0-final
Reporter: David Shepherdson
Assignee: Igor Vaynberg
Fix For: 1.3.3
In the constructor for FormTester, a visitor runs through all the form
components and sets their initial values in the request. However, the visitor
only deals with components that are instances of specific classes: currently
AbstractTextComponent, DropDownChoice, RadioChoice, CheckBox,
ListMultipleChoice and CheckGroup.
Notably absent from that list is RadioGroup; if a RadioGroup is present in
the form, it won't have any value set in the request and therefore when the
form is submitted, if it's a required field the form validation will fail.
We're working around this by adding the following code to the
onFormComponent(FormComponent) method of the listener:
else if (formComponent instanceof RadioGroup)
{
final String value = formComponent.getValue();
Object choiceValue =
formComponent.visitChildren(Radio.class, new IVisitor()
{
public Object component(Component component)
{
// O-P Preserve old escaping value, then turn
escaping off
// so that values aren't escaped unnecessarily.
boolean oldEscaping =
component.getEscapeModelStrings();
component.setEscapeModelStrings(false);
Radio radio = (Radio)component;
String radioValue = radio.getValue();
// O-P Restore the previous escaping setting.
component.setEscapeModelStrings(oldEscaping);
if
(radio.getModelObject().toString().equals(value))
{
return radioValue;
}
return CONTINUE_TRAVERSAL;
}
});
if (choiceValue != null) {
setFormComponentValue(formComponent, (String)
choiceValue);
}
}
(See issue WICKET-1094 for the reason for the 'O-P' comments about escaping,
though I'm not sure that they're really needed in this case.)
Would it also be sensible to add a fallback case; something like the
following?
else
{
setFormComponentValue(formComponent,
formComponent.getValue());
}
That would deal with any user-defined components that are subclasses of
FormComponent but not of one of the existing Wicket components. (Though I'm
not sure how common that is; we haven't done it ourselves.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1397) AjaxSubmitLink doesn't always find enclosing form properly
[ https://issues.apache.org/jira/browse/WICKET-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Shepherdson closed WICKET-1397. - Thanks -- I can confirm that this is fixed in 1.3.3. AjaxSubmitLink doesn't always find enclosing form properly -- Key: WICKET-1397 URL: https://issues.apache.org/jira/browse/WICKET-1397 Project: Wicket Issue Type: Bug Affects Versions: 1.3.0-final Reporter: David Shepherdson Assignee: Gerolf Seitz Priority: Minor Fix For: 1.3.2 If the AjaxSubmitLink constructor that doesn't take in a form is called, it calls the constructor that does take in a form with null for the form. This seems correct, and it passes the form argument into the constructor of the AjaxFormSubmitBehavior as also seems correct. AjaxFormSubmitBehavior has a private getForm() method that, if the form is null, sensibly searches through the component hierarchy to find a form that contains the component. This is also good. :-) The bit that seems wrong is that the overridden onSubmit(AjaxRequestTarget) and onError(AjaxRequestTarget) methods in AjaxSubmitLink's version of AjaxFormSubmitBehavior call AjaxSubmitLink's onSubmit and onError with the form argument that was originally passed into the constructor. This means that if you originally called the one-argument constructor for AjaxSubmitLink, the onSubmit and onError methods will be called with a null form, rather than the actual form that was submitted. As far as I can see, an easy fix for this would be to make getForm() in AjaxFormSubmitBehavior protected rather than private, and then to call getForm() in the overridden onSubmit and onError in AjaxSubmitLink's version of AjaxFormSubmitBehavior. That way the AjaxSubmitLink's onSubmit and onError would always be called with the actual form that was submitted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1654) Update validators to accept IModel parameter for easy override of error messages
Update validators to accept IModel parameter for easy override of error messages Key: WICKET-1654 URL: https://issues.apache.org/jira/browse/WICKET-1654 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-M1 Environment: N/A Reporter: Will Hoover Priority: Minor Update validators to accept IModel parameter for easy override of error messages. Instead of looking up the resource key in Application.properties and adding to the components properties file, allow a model to be passed into the validators that will override the default validation error message. For example: StringResourceModel srm = new StringResourceModel(my.custom.stringvalidator.message, null); add(new TextField(fname).setLabel(new Model(first name)).add(StringValidator.minimum(5, srm)); 1) This will also allow someone to pass in parameters that they want displayed along with the validation error message (difficult to accomplish when just overriding the resource key- where to pass?) 2) More intuitive because it uses the same concept that is applied to components... i.e. new TextField(id, new Model(...)) VS StringValidator.minimum(5, new Model(...)) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1654) Update validators to accept IModel parameter for easy override of error messages
[ https://issues.apache.org/jira/browse/WICKET-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner reassigned WICKET-1654: --- Assignee: Igor Vaynberg is this a 1.4 thing? i guess it will be 1.5? And does igor wants to polute the IValidator interface with wicket specific interfaces (IModel) ??? Update validators to accept IModel parameter for easy override of error messages Key: WICKET-1654 URL: https://issues.apache.org/jira/browse/WICKET-1654 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-M1 Environment: N/A Reporter: Will Hoover Assignee: Igor Vaynberg Priority: Minor Original Estimate: 24h Remaining Estimate: 24h Update validators to accept IModel parameter for easy override of error messages. Instead of looking up the resource key in Application.properties and adding to the components properties file, allow a model to be passed into the validators that will override the default validation error message. For example: StringResourceModel srm = new StringResourceModel(my.custom.stringvalidator.message, null); add(new TextField(fname).setLabel(new Model(first name)).add(StringValidator.minimum(5, srm)); 1) This will also allow someone to pass in parameters that they want displayed along with the validation error message (difficult to accomplish when just overriding the resource key- where to pass?) 2) More intuitive because it uses the same concept that is applied to components... i.e. new TextField(id, new Model(...)) VS StringValidator.minimum(5, new Model(...)) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1465) AjaxRequestTarget shouldn't throw exception when component is already removed from page (but log warning)
[
https://issues.apache.org/jira/browse/WICKET-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599020#action_12599020
]
David Shepherdson commented on WICKET-1465:
---
This won't actually fix the problem, though, will it? It seems to me that
component.getPage() will never return null, but would instead throw the same
IllegalStateException:
public final Page getPage()
{
// Search for nearest Page
final Page page = findPage();
// If no Page was found
if (page == null)
{
// Give up with a nice exception
throw new IllegalStateException(No Page found for
component + this);
}
return page;
}
In that case, wouldn't AjaxRequestTarget be better off catching the
IllegalStateException from getPage() and printing its debug message instead?
(By the way, I like the comment about it being a 'nice' exception in the code
above... ;-))
AjaxRequestTarget shouldn't throw exception when component is already removed
from page (but log warning)
-
Key: WICKET-1465
URL: https://issues.apache.org/jira/browse/WICKET-1465
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.2
Reporter: Johan Compagner
Assignee: Johan Compagner
Fix For: 1.3.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r659118 - /wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
Author: jcompagner
Date: Thu May 22 07:21:22 2008
New Revision: 659118
URL: http://svn.apache.org/viewvc?rev=659118view=rev
Log:
WICKET-1465 getPage throws an exception, made it findParent(Page.class)
Modified:
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
Modified:
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java?rev=659118r1=659117r2=659118view=diff
==
---
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
(original)
+++
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/AjaxRequestTarget.java
Thu May 22 07:21:22 2008
@@ -726,7 +726,7 @@
RequestCycle.get().setResponse(encodingBodyResponse);
// Initialize temporary variables
- final Page page = component.getPage();
+ final Page page = (Page)component.findParent(Page.class);
if (page == null)
{
// dont throw an exception but just ignore this
component, somehow it got
[jira] Commented: (WICKET-1465) AjaxRequestTarget shouldn't throw exception when component is already removed from page (but log warning)
[ https://issues.apache.org/jira/browse/WICKET-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599025#action_12599025 ] Johan Compagner commented on WICKET-1465: - you are right made it findParent(Page.class) AjaxRequestTarget shouldn't throw exception when component is already removed from page (but log warning) - Key: WICKET-1465 URL: https://issues.apache.org/jira/browse/WICKET-1465 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.2 Reporter: Johan Compagner Assignee: Johan Compagner Fix For: 1.3.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r659120 - /wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/basic/StringRequestTarget.java
Author: jcompagner
Date: Thu May 22 07:21:57 2008
New Revision: 659120
URL: http://svn.apache.org/viewvc?rev=659120view=rev
Log:
content type should be set on the response
Modified:
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/basic/StringRequestTarget.java
Modified:
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/basic/StringRequestTarget.java
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/basic/StringRequestTarget.java?rev=659120r1=659119r2=659120view=diff
==
---
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/basic/StringRequestTarget.java
(original)
+++
wicket/branches/wicket-1.3.x/jdk-1.4/wicket/src/main/java/org/apache/wicket/request/target/basic/StringRequestTarget.java
Thu May 22 07:21:57 2008
@@ -48,7 +48,7 @@
*/
public StringRequestTarget(String string)
{
- this(text, string);
+ this(text/plain, string);
}
/**
@@ -84,6 +84,7 @@
{
// Get servlet response to use when responding with resource
final Response response = requestCycle.getResponse();
+ response.setContentType(contentType);
final StringBufferResourceStream stream = new
StringBufferResourceStream(contentType);
stream.append(string);
[jira] Updated: (WICKET-1654) Update validators to accept IModel parameter for easy override of error messages
[ https://issues.apache.org/jira/browse/WICKET-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-1654: -- Fix Version/s: 1.5-M1 this wont affect the interface. this feature request is to be able to provide an imodel that constructs the entire message instead of always going through resource keys - so it is up to ivalidator implementations to do this. Update validators to accept IModel parameter for easy override of error messages Key: WICKET-1654 URL: https://issues.apache.org/jira/browse/WICKET-1654 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-M1 Environment: N/A Reporter: Will Hoover Assignee: Igor Vaynberg Priority: Minor Fix For: 1.5-M1 Original Estimate: 24h Remaining Estimate: 24h Update validators to accept IModel parameter for easy override of error messages. Instead of looking up the resource key in Application.properties and adding to the components properties file, allow a model to be passed into the validators that will override the default validation error message. For example: StringResourceModel srm = new StringResourceModel(my.custom.stringvalidator.message, null); add(new TextField(fname).setLabel(new Model(first name)).add(StringValidator.minimum(5, srm)); 1) This will also allow someone to pass in parameters that they want displayed along with the validation error message (difficult to accomplish when just overriding the resource key- where to pass?) 2) More intuitive because it uses the same concept that is applied to components... i.e. new TextField(id, new Model(...)) VS StringValidator.minimum(5, new Model(...)) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1653) Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy load panel in IE
[ https://issues.apache.org/jira/browse/WICKET-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reassigned WICKET-1653: - Assignee: Matej Knopp Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy load panel in IE --- Key: WICKET-1653 URL: https://issues.apache.org/jira/browse/WICKET-1653 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Environment: IE6.0.2900.2180 on xp Reporter: Per Newgro Assignee: Matej Knopp see description at http://www.nabble.com/javascript-error-in-internet-explorer-td16732896.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Index (page edited)
Page Edited : WICKET : Index Index has been edited by Martijn Dashorst (May 22, 2008). (View changes) Content: Bookmarkable URL Linking to the wikiTo help with the server loading, please only link to pages under the http://cwiki.apache.org/WICKET/ static root. I'll add Bookmarkable URL links to the pages to help as time allows, but they're not there yet. Generics Warning Wicket 1.4's Generics solution is highly controversial. We have opened a central page for comments and improvements. Discussion should be limited to the list! Click generics to see the page. This wiki is dedicated to documenting the Wicket Java application framework. Wicket takes simplicity, separation of concerns and ease of development to a whole new level. The wiki is currently open to new users and contributors; see the contribution page for more information. To download Wicket, please visit the Wicket site. Table of contents Wish List for Next Version Framework Documentation Migrations Videos, Talks, Screencasts Wicket Press User Stories Framework Comparisons Sites using Wicket Commercial Services Companies Hiring Wicket Developers Other projects related to Wicket External Links IRC Community initiatives Wish List for Next Version Wicket 1.5 Framework Documentation Introduction on Java web applications A must read for anyone developing web applications with Java. We presume you know this before you start working with Wicket. Documentation Index An attempt to provide a one-page overview as to where to look for information. Getting started guide (A little dated/incomplete, so check the Reference library too) Reference library A selection of reference guides and how-tos. Best Practices and Gotchas Wicket FAQs Release notes Notes about the Wiki move Notes: See also the Labels page (via the Browse Space link above) for some indices into the content of this site, e.g. model, component, etc. Migrations Migration from Wicket 1.3 to Wicket 1.4 (1.4 is the current development release) Migration from Wicket 1.2 to Wicket 1.3 (1.3 is the current stable release) Migration to Wicket 1.2 (1.2 is the previous stable release) List of API changes from 1.1.1 to 1.2 (Updated to compare with the released 1.2 jar) migrate2.0Migration from 1.2 to Wicket 2.0 (2.0 as described here is discontinued) Videos, Talks, Screencasts "Wicket Quickstart" - comprehensive screencast about how to use wicket-archetype-quickstart by Al Maw "Generic Bean Edititing with Apache Wicket - Presentation Code" (short talk by Al Maw) Video of an interview with Nick Heudecker on TheServerSide.com Slides and presentations Wicket Press User Stories Articles about Wicket Wicket Blogs User stories Framework Comparisons Wicket and Struts Wicket and Tapestry Kent Tong's blog on the differences between Tapestry and Wicket Wicket and JSF (blog post) Sites using Wicket Sites using Wicket Commercial Services Companies that provide services such as training, consultations and support Companies Hiring Wicket Developers Employers seeking Wicket developers Other projects related to Wicket Project Url Description Wicket Stuff http://wicketstuff.org sandbox for various wicket components that are not in the wicket core (ex: hibernate, rss, scriptaculous integration) Databinder http://databinder.net/ project for building web applications quickly with Wicket and Hibernate Qwicket http://qwicket.sf.net another quickstart project for building spring+hibernate+wicket applications. Support for more persistence layers is forthcoming. Webby http://r8fe.net/webby Webby aims at supporting quick creation of data centric web applications, built upon Wicket, using a bean descriptor like approach. blog Wicket Bench http://www.laughingpanda.org/mediawiki/index.php/Wicket_Bench Eclipse plugin by Laughing Panda Wicket Support http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=3586 NetBeans plugin Shades http://shadesdb.sourceforge.net Interface based Object/Relational Mapping (ORM) framework. The address book example has an example of integration with Wicket. Blog. OPS4J / Pax Wicket http://wiki.ops4j.org/confluence/display/ops4j/Pax+Wicket OSGi service for supporting the creation of Wicket applications running on the OSGi platform Terracotta http://www.terracotta.org is a JVM level clustering solution. Explicit support for Wicket is planned for their next version. Meanwhile, there is a short WIKI article here. Wicket Web Beans http://wicketwebbeans.sourceforge.net is a project that automatically generates AJAX-based forms at runtime from POJOs. You write the model, WWB does the UI. Wicket Tools
[CONF] Apache Wicket: generics (page edited)
Page Edited : WICKET : generics generics has been edited by Martijn Dashorst (May 22, 2008). (View changes) Content: The trouble with Generics Table of contents Generics Rock! Generics Suck! You are kindly requested to modify/tweak and work on this document. Just one thing: KEEP IT CIVIL! This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis. Generics Rock! Java generics are good for type safety throughout your code. They document the code directly with intent: ListPerson leaves little to the imagination as to what goes into the list. These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView: Generics Suck! Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[CONF] Apache Wicket: Wicket form submits, FBML and redirects (page created)
Page Created : WICKET : Wicket form submits, FBML and redirects Wicket form submits, FBML and redirects has been created by Lauri Lehtinen (May 22, 2008). Content: Today I struggled with more redirect related issues as I continued rewriting our Facebook app with Wicket - I'll note my observations here (keep in mind that I am a first-timer with Wicket). When I submit one of my forms, my access log reveals that Wicket follows the "redirect after post" pattern. "POST /appcontext/somepage?wicket:interface=:0:somepanel:someform::IFormSubmitListener:: HTTP/1.1" 200 "POST /appcontext/somepage?wicket:interface=:1 HTTP/1.1" 200 In the context of a Facebook FBML application, the second access log entry never appears, and the url in the browser remains as follows: http://apps.facebook.com/myapp/somepage?wicket:interface=:0:somepanel:someform::IFormSubmitListener:: which seems to represent some expired state of the page. If one does a refresh on the page, the browser's "repost popup" appears, and if one chooses to resubmit the form, Wicket responds with a 404 - Page expired. This is by Facebook's design and the redirect issued by Wicket after the form post is simply ignored and never makes it to the browser. Access log looks like this: "POST /appcontext/somepage?wicket:interface=:0:somepanel:someform::IFormSubmitListener:: HTTP/1.1" 200 Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[jira] Commented: (WICKET-1593) llegalStateException when refreshing a WebMarkupContainer containing a AjaxFallbackDefaultDataTable with one of the columns is a AjaxEditableLabel which refreshes the m
[ https://issues.apache.org/jira/browse/WICKET-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599162#action_12599162 ] Eric Gulatee commented on WICKET-1593: -- Removing the call to super.onSubmit in the overriden onSubmit method resolves the issue. There doesn't seem to be any negative side effects to commentin gout the call to parent.onSubmit() The error message is really hard to follow and misleading. Especially considering, this is all that is in the AjaxEditableLabel.onSubmit() label.setVisible(true); editor.setVisible(false); target.addComponent(AjaxEditableLabel.this); target.appendJavascript(window.status='';); llegalStateException when refreshing a WebMarkupContainer containing a AjaxFallbackDefaultDataTable with one of the columns is a AjaxEditableLabel which refreshes the markup container on submit - Key: WICKET-1593 URL: https://issues.apache.org/jira/browse/WICKET-1593 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Environment: Same behaviour on windows XP macosx 10.5 Reporter: Eric Gulatee Attachments: TestAjaxDataTable.html, TestAjaxDataTable.java llegalStateException when refreshing a WebMarkupContainer containing a AjaxFallbackDefaultDataTable where one of the columns is a AjaxEditableLabel which refreshes the markup container on submit Attached is the html + page + component to recreate the issue. Stack Trace as follows: java.lang.IllegalStateException: No Page found for component [MarkupContainer [Component id = cell, page = No Page, path = 1:cells:5:cell.QuantityLabel]] at org.apache.wicket.Component.getPage(Component.java:1658) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1331) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:363) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1593) llegalStateException when refreshing a WebMarkupContainer containing a AjaxFallbackDefaultDataTable with one of the columns is a AjaxEditableLabel which refreshes the ma
[ https://issues.apache.org/jira/browse/WICKET-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Gulatee resolved WICKET-1593. -- Resolution: Fixed Fix Version/s: 1.3.3 llegalStateException when refreshing a WebMarkupContainer containing a AjaxFallbackDefaultDataTable with one of the columns is a AjaxEditableLabel which refreshes the markup container on submit - Key: WICKET-1593 URL: https://issues.apache.org/jira/browse/WICKET-1593 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Environment: Same behaviour on windows XP macosx 10.5 Reporter: Eric Gulatee Fix For: 1.3.3 Attachments: TestAjaxDataTable.html, TestAjaxDataTable.java llegalStateException when refreshing a WebMarkupContainer containing a AjaxFallbackDefaultDataTable where one of the columns is a AjaxEditableLabel which refreshes the markup container on submit Attached is the html + page + component to recreate the issue. Stack Trace as follows: java.lang.IllegalStateException: No Page found for component [MarkupContainer [Component id = cell, page = No Page, path = 1:cells:5:cell.QuantityLabel]] at org.apache.wicket.Component.getPage(Component.java:1658) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1331) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:363) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1655) Try to see if something can be done to provide better error message if you call parent AjaxEditableLabel.onSubmit() from a subclass.
Try to see if something can be done to provide better error message if you call parent AjaxEditableLabel.onSubmit() from a subclass. Key: WICKET-1655 URL: https://issues.apache.org/jira/browse/WICKET-1655 Project: Wicket Issue Type: Sub-task Components: wicket Affects Versions: 1.3.3 Environment: Windows / MacOS Reporter: Eric Gulatee Priority: Trivial -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r659248 - /wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Author: jcompagner
Date: Thu May 22 13:47:56 2008
New Revision: 659248
URL: http://svn.apache.org/viewvc?rev=659248view=rev
Log:
- speeds up the rendering of the autocomplete menu list;
- speeds up the initial assignment of events (onclick and onmouseover) to items
in the menu list;
- fixes a small glitch in setting the height of the menu container (eventual
padding and margins were ignored and so the height resulted smaller than needed
- vertical scrollbar appeared)
Modified:
wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Modified:
wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js?rev=659248r1=659247r2=659248view=diff
==
---
wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
(original)
+++
wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete/wicket-autocomplete.js
Thu May 22 13:47:56 2008
@@ -52,6 +52,10 @@
var objonkeypress;
var objonchange;
var objonchangeoriginal;
+
+ // holds the eventual margins, padding, etc. of the menu container.
+ // it is computed when the menu is first rendered, and then reused.
+ var initialDelta = -1;
function initialize(){
var obj=wicketGet(elementId);
@@ -279,23 +283,26 @@
var element = getAutocompleteMenu();
element.innerHTML=resp;
if(element.firstChild element.firstChild.childNodes) {
-elementCount=element.firstChild.childNodes.length;
+ elementCount=element.firstChild.childNodes.length;
-for(var i=0;ielementCount;i++){
- var node=element.firstChild.childNodes[i];
-
- node.onclick = function(event){
- mouseactive=0;
-
wicketGet(elementId).value=getSelectedValue();
- if(typeof
objonchange==function)objonchange();
- hideAutoComplete();
- }
-
- node.onmouseover = function(event){
- selected = getElementIndex(this);
- render();
- showAutoComplete();
- }
+ var clickFunc = function(event){
+ mouseactive=0;
+ wicketGet(elementId).value=getSelectedValue();
+ if(typeof objonchange==function)objonchange();
+ hideAutoComplete();
+ };
+
+ var mouseOverFunc = function(event){
+ selected = getElementIndex(this);
+ render();
+ showAutoComplete();
+ };
+
+ var node=element.firstChild.childNodes[0];
+ for(var i=0;ielementCount;i++){
+ node.onclick = clickFunc;
+ node.onmouseover = mouseOverFunc;
+ node = node.nextSibling;
}
} else {
elementCount=0;
@@ -360,26 +367,28 @@
function render(){
var menu=getAutocompleteMenu();
var height=0;
-for(var i=0;ielementCount;i++){
-var node=menu.firstChild.childNodes[i];
-
-var classNames=node.className.split( );
-for (var j=0; jclassNames.length; j++) {
-if (classNames[j]=='selected') {
-classNames[j]='';
-}
-}
-
-if(selected==i){
-classNames.push('selected');
-adjustScrollOffset(menu.parentNode, node);
-}
-
-node.className=classNames.join( );
-height+=node.offsetHeight;
-}
+ var node=menu.firstChild.childNodes[0];
+ var re = /\bselected\b/gi;
+for(var i=0;ielementCount;i++)
+ {
+ var classNames = node.className.replace(re, );
+ if(selected==i){
+ classNames += selected;
+ adjustScrollOffset(menu.parentNode, node);
+ }
+ node.className =
[CONF] Apache Wicket: generics (page edited)
Page Edited :
WICKET :
generics
generics
has been edited by Doug Donohoe
(May 22, 2008).
(View changes)
Content:
The trouble with Generics
Table of contents
Generics Rock!
Generics Suck!
Suggestion 1 - setResponsePage() signature
You are kindly requested to modify/tweak and work on this document. Just one thing: KEEP IT CIVIL!
This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis.
Generics Rock!
Java generics are good for type safety throughout your code. They document the code directly with intent: ListPerson leaves little to the imagination as to what goes into the list.
These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView:
Generics Suck!
TBD
Suggestion 1 - setResponsePage() signature
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Class? extends Page? cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
We could change this to:
@SuppressWarnings({"unchecked"})
public final void setResponsePage(final Class? cls, PageParameters parameters)
{
final Class? extends Page? castCls = (Class? extends Page? cls)
getRequestCycle().setResponsePage(castCls, parameters);
}
This way (a) users migrating to 1.4 don't get tons of warnings/errors and (b) if they pass in the wrong thing, a class cast exception will be thrown quickly.
NOTE: This is just an example - we may wish to move the cast into the getRequestCycle() call ...
My idea is to dial back the generics on some of the API calls like this one and others that cause pain, but leave the generics for useful things like getModelObject().
-Doug Donohoe
Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request
Unsubscribe or edit your notifications preferences
[CONF] Apache Wicket: generics (page edited)
Page Edited :
WICKET :
generics
generics
has been edited by Doug Donohoe
(May 22, 2008).
(View changes)
Content:
The trouble with Generics
Table of contents
Generics Rock!
Generics Suck!
Suggestion 1 - setResponsePage() signature
You are kindly requested to modify/tweak and work on this document. Just one thing: KEEP IT CIVIL!
This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis.
Generics Rock!
Java generics are good for type safety throughout your code. They document the code directly with intent: ListPerson leaves little to the imagination as to what goes into the list.
These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView:
Generics Suck!
TBD
Suggestion 1 - setResponsePage() signature
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Class? extends Page? cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
We could change this to:
@SuppressWarnings({"unchecked"})
public final void setResponsePage(final Class? cls, PageParameters parameters)
{
final Class? extends Page? castCls = (Class? extends Page?) cls;
getRequestCycle().setResponsePage(castCls, parameters);
}
This way (a) users migrating to 1.4 don't get tons of warnings/errors and (b) if they pass in the wrong thing, a class cast exception will be thrown quickly.
NOTE: This is just an example - we may wish to move the cast into the getRequestCycle() call ...
My idea is to dial back the generics on some of the API calls like this one and others that cause pain, but leave the generics for useful things like getModelObject().
-Doug Donohoe
Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request
Unsubscribe or edit your notifications preferences
[CONF] Apache Wicket: generics (page edited)
Page Edited :
WICKET :
generics
generics
has been edited by Doug Donohoe
(May 22, 2008).
(View changes)
Content:
The trouble with Generics
Table of contents
Generics Rock!
Generics Suck!
Suggestion 1 - setResponsePage() signature
You are kindly requested to modify/tweak and work on this document. Just one thing: KEEP IT CIVIL!
This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis.
Generics Rock!
Java generics are good for type safety throughout your code. They document the code directly with intent: ListPerson leaves little to the imagination as to what goes into the list.
These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView:
Generics Suck!
TBD
Suggestion 1 - setResponsePage() signature
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Class? extends Page? cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
We could change this to:
@SuppressWarnings({"unchecked"})
public final void setResponsePage(final Class? cls, PageParameters parameters)
{
final Class? extends Page? castCls = (Class? extends Page? cls)
getRequestCycle().setResponsePage(castCls, parameters);
}
This way (a) users migrating to 1.4 don't get tons of warnings/errors and (b) if they pass in the wrong thing, a class cast exception will be thrown quickly.
NOTE: This is just an example - we may wish to move the cast into the getRequestCycle() call ...
My idea is to dial back the generics on some of the API calls like this one and others that cause pain, but leave the generics for useful things like getModelObject().
-Doug Donohoe
Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request
Unsubscribe or edit your notifications preferences
[CONF] Apache Wicket: generics (comment added)
Comment Added : WICKET : Re: generics generics commented on by Jeremy Thomerson (May 22, 2008). Comment: I agree with Doug, and with suggestion 1 above on setResponsePage changing from setResponsePage(final Class? extends Page? cls to setResponsePage(final Class? cls Another example would be: Change public RestartResponseAtInterceptPageException(final Class ? extends Page ? interceptPageClass) to: public RestartResponseAtInterceptPageException(final Class? interceptPageClass) This, for the same reason as above - it's not very likely that someone is going to pass a non-page-child class into these methods or constructors, so the benefit is minimal, but the strictly generified versions penalize you if your page class is not also generified, which would be confusing to new users. Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[CONF] Apache Wicket: generics (page edited)
Page Edited :
WICKET :
generics
generics
has been edited by Jeremy Thomerson
(May 22, 2008).
(View changes)
Content:
The trouble with Generics
Table of contents
Generics Rock!
Generics Suck!
Suggestion 1 - setResponsePage() signature
Suggestion 2 - RestartResponseAtInterceptPageException constructor
You are kindly requested to modify/tweak and work on this document. Just one thing: KEEP IT CIVIL!
This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis.
Generics Rock!
Java generics are good for type safety throughout your code. They document the code directly with intent: ListPerson leaves little to the imagination as to what goes into the list.
These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView:
Generics Suck!
TBD
Suggestion 1 - setResponsePage() signature
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Class? extends Page? cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
We could change this to:
@SuppressWarnings({"unchecked"})
public final void setResponsePage(final Class? cls, PageParameters parameters)
{
final Class? extends Page? castCls = (Class? extends Page?) cls;
getRequestCycle().setResponsePage(castCls, parameters);
}
This way (a) users migrating to 1.4 don't get tons of warnings/errors and (b) if they pass in the wrong thing, a class cast exception will be thrown quickly.
NOTE: This is just an example - we may wish to move the cast into the getRequestCycle() call ...
My idea is to dial back the generics on some of the API calls like this one and others that cause pain, but leave the generics for useful things like getModelObject().
-Doug Donohoe
Suggestion 2 - RestartResponseAtInterceptPageException constructor
I agree with Doug, and with suggestion 1 above on setResponsePage changing to take Class?
I think another example is the constructor of RestartResponseAtInterceptPageException (and similar classes) that take a class as an argument.
public RestartResponseAtInterceptPageException(final Class ? extends Page ? interceptPageClass)
{
if (interceptPageClass == null)
{
throw new IllegalStateException("Argument pageClass cannot be null");
}
redirectToInterceptPage(interceptPageClass);
}
We could change this to:
public RestartResponseAtInterceptPageException(final Class? interceptPageClass)
{
if (interceptPageClass == null || !Page.class.isAssignableFrom(interceptPageClass))
{
throw new IllegalStateException("Argument pageClass cannot be null and must inherit from Page.class");
}
redirectToInterceptPage(interceptPageClass);
}
This, for the same reason as suggestion 1 - it's not very likely that someone is going to pass a non-page-child class into these methods or constructors, so the benefit is minimal, but the strictly generified versions penalize you if your page class is not also generified, which would be confusing to new users.
Powered by
Atlassian Confluence
(Version: 2.2.9 Build:#527 Sep 07, 2006)
-
Bug/feature request
Unsubscribe or edit your notifications preferences
[CONF] Apache Wicket: Migrate-1.4 (page edited)
Page Edited : WICKET : Migrate-1.4 Migrate-1.4 has been edited by Igor Vaynberg (May 22, 2008). (View changes) Content: Full Size| Edit Diagram 1.4 is the current development release. Migrating to Wicket 1.4 Bookmarkable URL Getting and building it http://wicket.apache.org/building-from-svn.html describes how to get and build Wicket 1.4.x. Snapshots can be found in this maven repository and has version 1.4-SNAPSHOT: http://wicketstuff.org/maven/repository Table of contents JDK 1.5 Spring Support Spring Modules SpringWebApplication JDK 1.5 Minimum Java version is now 1.5. Spring Support Spring Modules wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring. SpringWebApplication SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection. Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[CONF] Apache Wicket: Migrate-1.4 (page edited)
Page Edited : WICKET : Migrate-1.4 Migrate-1.4 has been edited by Igor Vaynberg (May 22, 2008). (View changes) Content: 1.4 is the current development release. Migrating to Wicket 1.4 Bookmarkable URLGetting and building it http://wicket.apache.org/building-from-svn.html describes how to get and build Wicket 1.4.x. Snapshots can be found in this maven repository and has version 1.4-SNAPSHOT: http://wicketstuff.org/maven/repository Table of contents JDK 1.5 Spring Support Spring Modules SpringWebApplication JDK 1.5 Minimum Java version is now 1.5. Spring Support Spring Modules wicket-spring and wicket-spring-annot modules have been merged. If your project depends on wicket-spring-annot simply replace it with a dependency on wicket-spring. SpringWebApplication SpringWebApplication has been deprecated in favor of SpringBean annotation. See SpringWebApplication javadoc for how to setup SpringBean based injection. Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[jira] Created: (WICKET-1656) serialVersionUID Errors in Eclipse
serialVersionUID Errors in Eclipse -- Key: WICKET-1656 URL: https://issues.apache.org/jira/browse/WICKET-1656 Project: Wicket Issue Type: Improvement Components: wicket Environment: Eclipse Reporter: Jeremy Thomerson Priority: Trivial Attachments: SERIAL-VERSIONS.patch When you check out wicket trunk (http://svn.apache.org/repos/asf/wicket/trunk) and then import a new project in Eclipse of just the wicket folder under that checkout, it uses the code style / compiler warning and error settings that are checked in to SVN. This creates compiler errors in Eclipse unless you override these settings. The attached patch simply adds the required serialVersionUID's to each class that is missing them (all in the test folder, none in main code). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1656) serialVersionUID Errors in Eclipse
[ https://issues.apache.org/jira/browse/WICKET-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Thomerson updated WICKET-1656: - Attachment: SERIAL-VERSIONS.patch serialVersionUID Errors in Eclipse -- Key: WICKET-1656 URL: https://issues.apache.org/jira/browse/WICKET-1656 Project: Wicket Issue Type: Improvement Components: wicket Environment: Eclipse Reporter: Jeremy Thomerson Priority: Trivial Attachments: SERIAL-VERSIONS.patch When you check out wicket trunk (http://svn.apache.org/repos/asf/wicket/trunk) and then import a new project in Eclipse of just the wicket folder under that checkout, it uses the code style / compiler warning and error settings that are checked in to SVN. This creates compiler errors in Eclipse unless you override these settings. The attached patch simply adds the required serialVersionUID's to each class that is missing them (all in the test folder, none in main code). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1656) serialVersionUID Errors in Eclipse
[ https://issues.apache.org/jira/browse/WICKET-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599236#action_12599236 ] Jeremy Thomerson commented on WICKET-1656: -- I forgot to add that there is a thread on the mailing list with more details. http://www.nabble.com/Setting-up-Wicket-in-Eclipse-td17075862.html serialVersionUID Errors in Eclipse -- Key: WICKET-1656 URL: https://issues.apache.org/jira/browse/WICKET-1656 Project: Wicket Issue Type: Improvement Components: wicket Environment: Eclipse Reporter: Jeremy Thomerson Priority: Trivial Attachments: SERIAL-VERSIONS.patch When you check out wicket trunk (http://svn.apache.org/repos/asf/wicket/trunk) and then import a new project in Eclipse of just the wicket folder under that checkout, it uses the code style / compiler warning and error settings that are checked in to SVN. This creates compiler errors in Eclipse unless you override these settings. The attached patch simply adds the required serialVersionUID's to each class that is missing them (all in the test folder, none in main code). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1656) serialVersionUID Errors in Eclipse
[ https://issues.apache.org/jira/browse/WICKET-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-1656. --- Resolution: Fixed Fix Version/s: 1.4-M2 Assignee: Igor Vaynberg serialVersionUID Errors in Eclipse -- Key: WICKET-1656 URL: https://issues.apache.org/jira/browse/WICKET-1656 Project: Wicket Issue Type: Improvement Components: wicket Environment: Eclipse Reporter: Jeremy Thomerson Assignee: Igor Vaynberg Priority: Trivial Fix For: 1.4-M2 Attachments: SERIAL-VERSIONS.patch When you check out wicket trunk (http://svn.apache.org/repos/asf/wicket/trunk) and then import a new project in Eclipse of just the wicket folder under that checkout, it uses the code style / compiler warning and error settings that are checked in to SVN. This creates compiler errors in Eclipse unless you override these settings. The attached patch simply adds the required serialVersionUID's to each class that is missing them (all in the test folder, none in main code). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r659328 - in /wicket/trunk/wicket/src/test/java/org/apache/wicket: ajax/ ajax/form/ markup/html/internal/ protocol/http/ redirect/intercept/ resource/loader/pages/ util/tester/apps_5/
Author: ivaynberg
Date: Thu May 22 17:21:59 2008
New Revision: 659328
URL: http://svn.apache.org/viewvc?rev=659328view=rev
Log:
WICKET-1656: missing serialuuids
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxBehaviorEnabledPage.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/form/AjaxFormSubmitTestPage.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/internal/EnclosurePage_6.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/FirstPage.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/SecondPage.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/redirect/intercept/HomePage.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/redirect/intercept/InterceptPage.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/redirect/intercept/TargetPage.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/resource/loader/pages/Test1.java
wicket/trunk/wicket/src/test/java/org/apache/wicket/util/tester/apps_5/MockPageWithFormAndContainedLink.java
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxBehaviorEnabledPage.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxBehaviorEnabledPage.java?rev=659328r1=659327r2=659328view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxBehaviorEnabledPage.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxBehaviorEnabledPage.java
Thu May 22 17:21:59 2008
@@ -27,6 +27,8 @@
public class AjaxBehaviorEnabledPage extends WebPageVoid
{
+ private static final long serialVersionUID = 1L;
+
/**
* Construct.
*/
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/form/AjaxFormSubmitTestPage.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/form/AjaxFormSubmitTestPage.java?rev=659328r1=659327r2=659328view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/form/AjaxFormSubmitTestPage.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/form/AjaxFormSubmitTestPage.java
Thu May 22 17:21:59 2008
@@ -29,6 +29,8 @@
*/
public class AjaxFormSubmitTestPage extends WebPageValueMap
{
+ private static final long serialVersionUID = 1L;
+
/**
* Indicates form handled submit.
*/
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/internal/EnclosurePage_6.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/internal/EnclosurePage_6.java?rev=659328r1=659327r2=659328view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/internal/EnclosurePage_6.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/markup/html/internal/EnclosurePage_6.java
Thu May 22 17:21:59 2008
@@ -23,8 +23,10 @@
/**
* @author ivaynberg
*/
-public class EnclosurePage_6 extends WebPageVoid
+public class EnclosurePage_6 extends WebPageVoid
{
+ private static final long serialVersionUID = 1L;
+
private int counter;
/**
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/FirstPage.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/FirstPage.java?rev=659328r1=659327r2=659328view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/FirstPage.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/FirstPage.java
Thu May 22 17:21:59 2008
@@ -21,8 +21,9 @@
import org.apache.wicket.markup.html.link.IPageLink;
import org.apache.wicket.markup.html.link.PageLink;
-public class FirstPage extends WebPageVoid
+public class FirstPage extends WebPageVoid
{
+ private static final long serialVersionUID = 1L;
public FirstPage()
{
Modified:
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/SecondPage.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/SecondPage.java?rev=659328r1=659327r2=659328view=diff
==
---
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/SecondPage.java
(original)
+++
wicket/trunk/wicket/src/test/java/org/apache/wicket/protocol/http/SecondPage.java
Thu May 22 17:21:59 2008
@@ -21,8 +21,9 @@
import org.apache.wicket.markup.html.link.IPageLink;
import
[jira] Created: (WICKET-1657) AjaxFallbackDefaultDataTable gives misleading error when fragment markup cannot be found
AjaxFallbackDefaultDataTable gives misleading error when fragment markup cannot be found Key: WICKET-1657 URL: https://issues.apache.org/jira/browse/WICKET-1657 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 1.3.0-final Reporter: Nick Johnson Priority: Minor If you call cellItem.add(new Fragment(foo,bar, myPage, model), but the fragment markup for bar isn't found in the markup for myPage, AjaxFallbackDefaultDataTable complains, failed to add a component with id [cell] to the provided [cellItem] object. The error suggests making sure that cellItem.add was called. This error can be misleading, especially since cellItem.add was called. What really happened was the fragment with a given ID wasn't found, which should really have been an error in its own right. It would be nice if the error message gave a better description indicating the reason why the component failed to add (e.g., an error in handling the Fragment). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: generics (page edited)
Page Edited :
WICKET :
generics
generics
has been edited by Timo Rantalaiho
(May 22, 2008).
Change summary:
Added my quick 2 cents
(View changes)
Content:
The trouble with Generics
Table of contents
Generics Rock!
Generics Suck!
Generics are warranted for IModel but too much verbosity for Component
Suggestion 1 - setResponsePage() signature
Suggestion 2 - RestartResponseAtInterceptPageException constructor
You are kindly requested to modify/tweak and work on this document. Just one thing: KEEP IT CIVIL!
This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis.
Generics Rock!
Java generics are good for type safety throughout your code. They document the code directly with intent: ListPerson leaves little to the imagination as to what goes into the list.
These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView:
Generics Suck!
TBD
Generics are warranted for IModel but too much verbosity for Component
If there is any place in Wicket which clearly holds typed data, it is the models (the IModel interface). In practice, one ends up creating a lot of custom components without models, such as different subclasses of MarkupContainer and possibly Page, and here the Component generification just adds more verbosity to the code.
Typically when starting to use a custom component, you start by typing its constructor call, so the constructor of a custom component is a crucial place for making clean and easy APIs. The possibility of giving type arguments to the IModel instance being passed in there is great, DropDownChoice is a prime example as it also has constructors with a List that needs to contain objects of the same type as the model. However,
DropDownChoice fruit = new DropDownChoice("fruit", new ModelFruit(), Arrays.asList(apple, orange, banana));
is better than
DropDownChoiceFruit fruit = new DropDownChoiceFruit("fruit", new ModelFruit(), Arrays.asList(apple, orange, banana));
Also when using 2.0 the experience was that IModel type was excellent, but Component type was more like noise. When using 1.3, the lack of types has hardly caused trouble; mostly types would be helpful when first creating a new component. Once you have the component constructed and are calling getModelObject() on it, you're typically sure of what to expect. There have not been difficult problems concerning objects of wrong type inside models.
In this approach, using getModelObject() you cast the same as in 1.3, and for getModel() you can do the necessary casting cleanly, which leaves you in a situation better than in 1.3.
Timo Rantalaiho
Suggestion 1 - setResponsePage() signature
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Class? extends Page? cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
We could change this to:
@SuppressWarnings({"unchecked"})
public final void setResponsePage(final Class? cls, PageParameters parameters)
{
final Class? extends Page? castCls = (Class? extends Page?) cls;
getRequestCycle().setResponsePage(castCls, parameters);
}
This way (a) users migrating to 1.4 don't get tons of warnings/errors and (b) if they pass in the wrong thing, a class cast exception will be thrown quickly.
NOTE: This is just an example - we may wish to move the cast into the getRequestCycle() call ...
My idea is to dial back the generics on some of the API calls like this one and others that cause pain, but leave the generics for useful things like getModelObject().
-Doug Donohoe
This is already resolved with the following signature:
public final C extends Page? void setResponsePage(final ClassC cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
Gerolf Seitz
Suggestion 2 - RestartResponseAtInterceptPageException constructor
I agree with Doug, and with suggestion 1 above on setResponsePage changing to take Class?
I think another example is the constructor of RestartResponseAtInterceptPageException (and similar classes) that take a class as an argument.
public RestartResponseAtInterceptPageException(final Class ? extends Page ? interceptPageClass)
{
if (interceptPageClass == null)
{
throw new IllegalStateException("Argument pageClass cannot be null");
}
redirectToInterceptPage(interceptPageClass);
}
We could change this
[CONF] Apache Wicket: generics (page edited)
Page Edited :
WICKET :
generics
generics
has been edited by Igor Vaynberg
(May 22, 2008).
(View changes)
Content:
The trouble with Generics
Table of contents
Generics Rock!
Generics Suck!
Generics are warranted for IModel but too much verbosity for Component
Suggestion 1 - setResponsePage() signature
Suggestion 2 - RestartResponseAtInterceptPageException constructor
You are kindly requested to modify/tweak and work on this document. Just one thing: KEEP IT CIVIL!
This document tries to capture the benefits and doubts we have regarding generics in Wicket 1.4. Ultimately we need to find a way where the Framework and Wicket Community can move onward to Wicket 1.5/2.0 with Java 5 as a basis.
Generics Rock!
Java generics are good for type safety throughout your code. They document the code directly with intent: ListPerson leaves little to the imagination as to what goes into the list.
These benefits are a great asset to Wicket. Wicket uses the concept of models to provide components with the data that needs to be rendered. Until recently Wicket was Java 1.4 based, and a lot of components suffered from the lack of generified models. Take for instance the ListView:
Generics Suck!
TBD
Generics are warranted for IModel but too much verbosity for Component
If there is any place in Wicket which clearly holds typed data, it is the models (the IModel interface). In practice, one ends up creating a lot of custom components without models, such as different subclasses of MarkupContainer and possibly Page, and here the Component generification just adds more verbosity to the code.
Typically when starting to use a custom component, you start by typing its constructor call, so the constructor of a custom component is a crucial place for making clean and easy APIs. The possibility of giving type arguments to the IModel instance being passed in there is great, DropDownChoice is a prime example as it also has constructors with a List that needs to contain objects of the same type as the model. However,
DropDownChoice fruit = new DropDownChoice("fruit", new ModelFruit(), Arrays.asList(apple, orange, banana));
is better than
DropDownChoiceFruit fruit = new DropDownChoiceFruit("fruit", new ModelFruit(), Arrays.asList(apple, orange, banana));
Also when using 2.0 the experience was that IModel type was excellent, but Component type was more like noise. When using 1.3, the lack of types has hardly caused trouble; mostly types would be helpful when first creating a new component. Once you have the component constructed and are calling getModelObject() on it, you're typically sure of what to expect. There have not been difficult problems concerning objects of wrong type inside models.
In this approach, using getModelObject() you cast the same as in 1.3, and for getModel() you can do the necessary casting cleanly, which leaves you in a situation better than in 1.3.
(Timo Rantalaiho)
I mostly agree with Timo. The only thing we lose from Component is generification of IConverter. Since IConverter is mostly only important in FormComponent perhaps we can fully type FormComponent which would allow us to have typesave converters AND validators.
(Igor Vaynberg)
Suggestion 1 - setResponsePage() signature
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Class? extends Page? cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
We could change this to:
@SuppressWarnings({"unchecked"})
public final void setResponsePage(final Class? cls, PageParameters parameters)
{
final Class? extends Page? castCls = (Class? extends Page?) cls;
getRequestCycle().setResponsePage(castCls, parameters);
}
This way (a) users migrating to 1.4 don't get tons of warnings/errors and (b) if they pass in the wrong thing, a class cast exception will be thrown quickly.
NOTE: This is just an example - we may wish to move the cast into the getRequestCycle() call ...
My idea is to dial back the generics on some of the API calls like this one and others that cause pain, but leave the generics for useful things like getModelObject().
-Doug Donohoe
This is already resolved with the following signature:
public final C extends Page? void setResponsePage(final ClassC cls, PageParameters parameters)
{
getRequestCycle().setResponsePage(cls, parameters);
}
Gerolf Seitz
Suggestion 2 - RestartResponseAtInterceptPageException constructor
I agree with Doug, and with suggestion 1 above on setResponsePage changing to take Class?
I think another example is the constructor of RestartResponseAtInterceptPageException (and similar classes) that take a class as an argument.
public RestartResponseAtInterceptPageException(final Class ? extends
