[jira] Resolved: (WICKET-1649) Manifests use incorrect Dynamic-ImportPackage header
[ https://issues.apache.org/jira/browse/WICKET-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1649. -- Resolution: Fixed Fix Version/s: 1.4-M2 1.3.4 fixed. thanks > Manifests use incorrect Dynamic-ImportPackage header > > > Key: WICKET-1649 > URL: https://issues.apache.org/jira/browse/WICKET-1649 > Project: Wicket > Issue Type: Bug >Reporter: Andy Wilkinson >Assignee: Gerolf Seitz > Fix For: 1.3.4, 1.4-M2 > > > The OSGi bundle manifests in the Wicket JARs are using the wrong dynamic > import package header. They currently use the header Dynamic-ImportPackage, > the header should be DynamicImport-Package. The current manifests cause a > number of classloading problems with Wicket when running in an OSGi > environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r659735 - /wicket/trunk/pom.xml
Author: gseitz Date: Fri May 23 17:56:38 2008 New Revision: 659735 URL: http://svn.apache.org/viewvc?rev=659735&view=rev Log: WICKET-1649: fix misspelled header Modified: wicket/trunk/pom.xml Modified: wicket/trunk/pom.xml URL: http://svn.apache.org/viewvc/wicket/trunk/pom.xml?rev=659735&r1=659734&r2=659735&view=diff == --- wicket/trunk/pom.xml (original) +++ wicket/trunk/pom.xml Fri May 23 17:56:38 2008 @@ -738,7 +738,7 @@ org.apache.wicket* - * + * <_nouses>true
svn commit: r659733 - /wicket/branches/wicket-1.3.x/pom.xml
Author: gseitz Date: Fri May 23 17:53:55 2008 New Revision: 659733 URL: http://svn.apache.org/viewvc?rev=659733&view=rev Log: WICKET-1649: fix misspelled header Modified: wicket/branches/wicket-1.3.x/pom.xml Modified: wicket/branches/wicket-1.3.x/pom.xml URL: http://svn.apache.org/viewvc/wicket/branches/wicket-1.3.x/pom.xml?rev=659733&r1=659732&r2=659733&view=diff == --- wicket/branches/wicket-1.3.x/pom.xml (original) +++ wicket/branches/wicket-1.3.x/pom.xml Fri May 23 17:53:55 2008 @@ -789,7 +789,7 @@ org.apache.wicket* - * + * <_nouses>true
[jira] Updated: (WICKET-1649) Manifests use incorrect Dynamic-ImportPackage header
[ https://issues.apache.org/jira/browse/WICKET-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz updated WICKET-1649: - Affects Version/s: (was: 1.4-M2) > Manifests use incorrect Dynamic-ImportPackage header > > > Key: WICKET-1649 > URL: https://issues.apache.org/jira/browse/WICKET-1649 > Project: Wicket > Issue Type: Bug >Reporter: Andy Wilkinson >Assignee: Gerolf Seitz > > The OSGi bundle manifests in the Wicket JARs are using the wrong dynamic > import package header. They currently use the header Dynamic-ImportPackage, > the header should be DynamicImport-Package. The current manifests cause a > number of classloading problems with Wicket when running in an OSGi > environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Conditional Validation (page edited)
Page Edited :
WICKET :
Conditional Validation
Conditional Validation
has been edited by John Krasnay
(May 23, 2008).
(View changes)
Content:
Flagging a form field as "required" is the most common kind of validation. In most cases, this can be specified statically as follows:
add(new TextField("foo").setRequired(true));
In some cases, however, whether or not the field is required cannot be determined when the form is created. Like many properties in Wicket, we can override the property setter (isRequired, in this case) to defer the evaluation of the property until the last possible moment:
add(new TextField("foo") {
public boolean isRequired() {
// return true if the field is required
}
}
That's the simple part. Unfortunately, implementing isRequired can be tricky, since it's called very early in the form processing cycle, before values are converted and models are updated. Below we provide a few recipes that cover some common scenarios.
Submit Button
In this recipe, the field is in a form with multiple submit buttons. We only want to require the field when one of the buttons is clicked:
Button submit = new Button("submit") {
public void onSubmit() {
// handle form submission
}
}
form.add(submit);
TextField foo = new TextField("foo") {
public boolean isRequired() {
Form form = (Form) findParent(Form.class);
return form.getRootForm().findSubmittingButton() == submitButton;
}
}
form.add(foo);
Note the call to getRootForm. Technically, this is only required in nested forms.
If you would like to bypass validation altogether you can do so by:
new Button("submit").setDefaultFormProcessing(false);
CheckBox
In this recipe, the field is only required when a checkbox on the form is checked:
final CheckBox checkBox = new CheckBox("cb");
form.add(checkBox);
TextField foo = new TextField("foo") {
public boolean isRequired() {
return Strings.isTrue(checkBox.getValue());
}
}
form.add(foo);
Radio Button
Here the field is only required when a particular radio button on the form is selected:
final RadioGroup radioGroup = new RadioGroup("radioGroup");
form.add(radioGroup);
final Radio radio1 = new Radio("radio1");
radioGroup.add(radio1);
TextField foo = new TextField("foo") {
public boolean isRequired() {
return Strings.isEqual(radioGroup.getInput(), radio1.getValue());
}
}
form.add(foo);
DropDownChoice
Normally, you give a list of domain objects to a DropDownChoice. We can check which one was selected with the getConvertedInput() method as follows:
public class DocumentType {
private String name;
private boolean hasExpiryDate;
// getters and setters omitted
}
List allDocumentTypes = ...;
final DropDownChoice ddc = new DropDownChoice("documentType", allDocumentTypes, new ChoiceRenderer("name"));
form.add(ddc);
TextField expiryDate = new TextField("expiryDate", Date.class) {
public boolean isRequired() {
DocumentType dt = (DocumentType) ddc.getConvertedInput();
return dt != null && dt.getHasExpiryDate();
}
}
form.add(expiryDate);
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-1659) Prolem with 'mouseactive' in wicket-autocomplete.js when AutoCompleteBehaviour is added (twice) during Ajax roundtrip
Prolem with 'mouseactive' in wicket-autocomplete.js when AutoCompleteBehaviour
is added (twice) during Ajax roundtrip
-
Key: WICKET-1659
URL: https://issues.apache.org/jira/browse/WICKET-1659
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.4-M1
Reporter: Roland Huss
Priority: Minor
There is a subtle problem, with the way how the autocomplete menu is created
lazily in wicket-autocomplete.js when
the AbstractAutoCompleteBehaviour is used dynamically in Ajax roundtrips e.g.
for adding addition auto complete
fields dynamically.
The auto complete menu is added as an addition to the document and stays
there even after an Ajax roundtrip, so
the is reused, as well as mouse event listeners on the menu:
function getAutocompleteMenu() {
var choiceDiv=document.getElementById(getMenuId());
if (choiceDiv==null) {
var container = document.createElement("div");
container.onmouseout=function() {
mouseactive=0;
};
container.onmousemove=function() {
mouseactive=1;
}
};
However, since Wicket.AutoComplete get initialized a second time for during the
Ajax update, a new mouseactive variable is created, which
is used in the closures for tweaking the even handling (onChange(), onBlur()),
which never gets updated by these reused container (and hence
is always 0).
One simple solution to this problem is to cleanup the autocomplete menu in the
initialize() if present:
function initialize(){
// Remove the autocompletion menu if still present from
// a previous call. This is required to properly register
// the mouse event handler again (using the new stateful 'mouseactive'
// variable which just gets created)
var choiceDiv=document.getElementById(this.getMenuId());
if (choiceDiv != null) {
choiceDiv.parentNode.parentNode.removeChild(choiceDiv.parentNode);
}
.
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1658) WicketTester#clickLink doesn't update lastRenderedPage
[ https://issues.apache.org/jira/browse/WICKET-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marat Radchenko updated WICKET-1658: Description: If clickLink is used on a link that calls setResponsePage then that page doesn't appear in WicketTester's lastRenderedPage. (was: If clickLink is used on a link that calls setResponsePage then that page doesn't appear in WicketTester's lastRenderedPage. To fix the problem simply call postProcessRequestCycle(requestCycle) between target.respond(requestCycle) and requestCycle.detach()) > WicketTester#clickLink doesn't update lastRenderedPage > -- > > Key: WICKET-1658 > URL: https://issues.apache.org/jira/browse/WICKET-1658 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Marat Radchenko > > If clickLink is used on a link that calls setResponsePage then that page > doesn't appear in WicketTester's lastRenderedPage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1658) WicketTester#clickLink doesn't update lastRenderedPage
WicketTester#clickLink doesn't update lastRenderedPage -- Key: WICKET-1658 URL: https://issues.apache.org/jira/browse/WICKET-1658 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-M1 Reporter: Marat Radchenko If clickLink is used on a link that calls setResponsePage then that page doesn't appear in WicketTester's lastRenderedPage. To fix the problem simply call postProcessRequestCycle(requestCycle) between target.respond(requestCycle) and requestCycle.detach() -- 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 Martijn Dashorst
(May 23, 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: List 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 Model(), Arrays.asList(apple, orange, banana));
is better than
DropDownChoice fruit = new DropDownChoice("fruit", new Model(), 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 typesafe converters AND validators.
(Igor Vaynberg)
If we dont do Component but we do specific subtypes like FormComponent that the above DropDownChoice example still has that signature..
and then i also vote for Repeaters to be generified, because especially in the onPopulate it is very descriptive what you get..
But i think people will then start complaining because they are using Links a lot and there model object.. So then we do get the question constantly on the list Why is this and Why isnt that... (i think)
I still dont find this that bad.. It really describes it:
DropDownChoice fruit = new DropDownChoice("fruit", new Model(), Arrays.asList(apple, orange, banana));
because what you also could do is this:
DropDownChoice fruit = new DropDownChoice("fruit", Arrays.asList(apple, orange, banana));
and yes i know.. this is somewhere not really type safe..because now a CompoundModel is used and that is based on strings..
But in the code is more descriptive.. but i guess somehow we should have a warning
And this is also the reason why i am also working on type safe property models.
(Johan Compagner)
Suggestion 1 - setResponsePage() signature
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Classextends 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 Classextends Page> castCls = (Classextends Page>) cls;
getRequestCycle().setResponsePage(castCls, parameters);
}
Thi
[CONF] Apache Wicket: generics (page edited)
Page Edited :
WICKET :
generics
generics
has been edited by Johan Compagner
(May 23, 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: List 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 Model(), Arrays.asList(apple, orange, banana));
is better than
DropDownChoice fruit = new DropDownChoice("fruit", new Model(), 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 typesafe converters AND validators.
(Igor Vaynberg)
If we dont do Component but we do specific subtypes like FormComponent that the above DropDownChoice example still has that signature..
and then i also vote for Repeaters to be generified, because especially in the onPopulate it is very descriptive what you get..
But i think people will then start complaining because they are using Links a lot and there model object.. So then we do get the question constantly on the list Why is this and Why isnt that... (i think)
I still dont find this that bad.. It really describes it:
DropDownChoice fruit = new DropDownChoice("fruit", new Model(), Arrays.asList(apple, orange, banana));
{code:java}
because what you also could do is this:
{code:java}
DropDownChoice fruit = new DropDownChoice("fruit", Arrays.asList(apple, orange, banana));
{code:java}
and yes i know.. this is somewhere not really type safe..because now a CompoundModel is used and that is based on strings..
But in the code is more descriptive.. but i guess somehow we should have a warning :(
And this is also the reason why i am also working on type safe property models.
(Johan Compagner)
h2. -Suggestion 1 - {{setResponsePage()}} signature-
The initial issue that started this discussion was a problem with this method signature:
public final void setResponsePage(final Class> cls, PageParameters parameters)
Unknown macro: {
getRequestCycle().setResponsePage(cls, parameters);
}
We could change this to:
@SuppressWarnings(Unknown macro: {"unchecked"} )
public final void setResponsePage(final Class cls, PageParameters parameters)
Unknown macro: {
final Class> castCls = (Class>) cls;
getRequest
[jira] Commented: (WICKET-1399) Escaping DiskPageStore SessionFolder needed
[
https://issues.apache.org/jira/browse/WICKET-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599301#action_12599301
]
Vladimir Piskarev commented on WICKET-1399:
---
Should also escape ':'
> Escaping DiskPageStore SessionFolder needed
> ---
>
> Key: WICKET-1399
> URL: https://issues.apache.org/jira/browse/WICKET-1399
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.1
> Environment: win xp, sun jdk 1.5.0_12, jboss-4.2.2.ga+tomcat-5.5
>Reporter: Filippo Guerzoni
>Assignee: Matej Knopp
>
> When sessionId=8y4bxNcyiScVVV6QtVp9lg**.node1 Wicket can't create the temp
> directory because the name contains invalid character (at least on windows).
> So a FileNotFoundException is thrown.
> The use case happens when tomcat is configured as (in order to work with
> apache module mod_jk)
>
> emptySessionPath="true" enableLookups="false" redirectPort="8443" />
>
> My very temp solution (to let things go) is
> private File getSessionFolder(String sessionId, boolean create)
> {
> File storeFolder = getStoreFolder();
> File sessionFolder = new File(storeFolder,
> sessionId.replace('*','_'));
> if (create && sessionFolder.exists() == false)
> {
> mkdirs(sessionFolder);
> }
> return sessionFolder;
> }
> I think that a global solution is needed to fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
