[jira] Commented: (WICKET-1138) Better warning of design errors during development
[ https://issues.apache.org/jira/browse/WICKET-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542639 ] Eelco Hillenius commented on WICKET-1138: - But the exception is thrown as a ConversionException which is later caught and logged as a feedback message. If it wasn't caught, you would have seen an error page. > Better warning of design errors during development > -- > > Key: WICKET-1138 > URL: https://issues.apache.org/jira/browse/WICKET-1138 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta4 >Reporter: Brill Pappin >Assignee: Eelco Hillenius > Fix For: 1.3.0-rc2 > > > As suggested in this list post: > http://www.nabble.com/Form%3A-onSubmit-not-called-tf4763217.html#a13659761 > > Although it was my own fault hands down (silly me didn't write a test first) > > I'm thinking that I could have saved hours with some sort of indication... > > now that its happened once the lesson is pretty clear, but a lot of people > > are going to stumble over stuff like that when they first get into Wicket. > Yeah. If you can open up a JIRA issue for it, we can think/ discuss > what we could do here. > Eelco -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1138) Better warning of design errors during development
[ https://issues.apache.org/jira/browse/WICKET-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542645 ] Brill Pappin commented on WICKET-1138: -- OK, that works... but the ticket was started because I had *zero* feedback at all, so I think although it might be covered in the code, the issue has not been dealt with. I assume debug mode is having the logger set to debug? Maybe the check should be if the application is in DEVELOPMENT mode instead? or if not in DEVELOPMENT then check the logger for debug... I think that would cover the issue. > Better warning of design errors during development > -- > > Key: WICKET-1138 > URL: https://issues.apache.org/jira/browse/WICKET-1138 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta4 >Reporter: Brill Pappin >Assignee: Eelco Hillenius > Fix For: 1.3.0-rc2 > > > As suggested in this list post: > http://www.nabble.com/Form%3A-onSubmit-not-called-tf4763217.html#a13659761 > > Although it was my own fault hands down (silly me didn't write a test first) > > I'm thinking that I could have saved hours with some sort of indication... > > now that its happened once the lesson is pretty clear, but a lot of people > > are going to stumble over stuff like that when they first get into Wicket. > Yeah. If you can open up a JIRA issue for it, we can think/ discuss > what we could do here. > Eelco -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1138) Better warning of design errors during development
[ https://issues.apache.org/jira/browse/WICKET-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542636 ] Brill Pappin commented on WICKET-1138: -- I'm not sure that would cover the problem. In this case it was a type mismatch (String -> Date) so and exception would have been thrown before it ever made it into a message object. > Better warning of design errors during development > -- > > Key: WICKET-1138 > URL: https://issues.apache.org/jira/browse/WICKET-1138 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta4 >Reporter: Brill Pappin >Assignee: Eelco Hillenius > Fix For: 1.3.0-rc2 > > > As suggested in this list post: > http://www.nabble.com/Form%3A-onSubmit-not-called-tf4763217.html#a13659761 > > Although it was my own fault hands down (silly me didn't write a test first) > > I'm thinking that I could have saved hours with some sort of indication... > > now that its happened once the lesson is pretty clear, but a lot of people > > are going to stumble over stuff like that when they first get into Wicket. > Yeah. If you can open up a JIRA issue for it, we can think/ discuss > what we could do here. > Eelco -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1139) Wicket html files do not have xml prolog
[ https://issues.apache.org/jira/browse/WICKET-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542620 ] Johan Compagner commented on WICKET-1139: - yeah i see your point, we have to fix this and set some encoding in the file so that the readers uses that. because platform specific can be any thing and if we save it in 8859 then another system can be on a completely different encoding and tries to load those files with something else. i just have to check if we change the page (ExceptionErrorPage) then we have to strip that again from the real output because thats by default always utf-8. But maybe we already do that > Wicket html files do not have xml prolog > > > Key: WICKET-1139 > URL: https://issues.apache.org/jira/browse/WICKET-1139 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: n/a >Reporter: Marat Radchenko > Fix For: 1.3.0-rc2 > > > We want to enforce all our pages to explicitly specify xml prolog in order to > avoid troubles with encodings (unfortunately we are not ASCII-speaking). We > want to do that by specifying invalid defaultMarkupEncoding. This way we will > get exceptions for all htmls that didn't declare encoding. However it is not > possible at the moment because many wicket built-in html files do not have > xml prolog. > Fix is very simple: just add to your > html files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1132) Ajax link is different from normal link on Liferay Portal
[
https://issues.apache.org/jira/browse/WICKET-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542541
]
thyzz edited comment on WICKET-1132 at 11/14/07 1:55 PM:
--
I finally had some time to look into this today and I've made some great
progress.
I now know way the url was different. The difference in p_p_id was caused by a
wrong implementation in LiferayToPortalBridgePortletResourceURLFactory as
posted in http://www.nabble.com/forum/ViewPost.jtp?post=13306973&framed=y by
Charles.
It should not use the portletConfig.getPortletName() but a custom Liferay
portletConfig.getPortletId() which gives the full portlet instance name.
Also this class misses things like Windowstate and portletmode.
I have something working now, it's still a bit hacked together with hard coded
windowstate and portletmode. But at least my ajax request is comming through to
the wicket code and is updating my simple counter.
However the ajax response is still not working correctly. First of all I had to
change Liferay to accept response.setContentType("text/xml"). Now I get a full
Liferay page back with in it included the xml part generated by
Wicket. That's what I'll try to dive into tomorrow.
It's a really strange problem because AjaxRequestTarget#respond first calls
WebResponse.setHeader(), then it should call WebResponse.write(..) but my log
never shows any logging from inside that method while I do get (added) logging
from inside setHeader().
was (Author: thyzz):
I finally had some time to look into this today and I've made some great
progress.
I now know way the url was different. The difference in p_p_id was caused by a
wrong implementation in LiferayToPortalBridgePortletResourceURLFactory as
posted in http://www.nabble.com/forum/ViewPost.jtp?post=13306973&framed=y by
Charles.
It should not use the portletConfig.getPortletName() but a custom Liferay
portletConfig.getPortletId() which gives the full portlet instance name.
Also this class misses things like Windowstate and portletmode.
I have something working now, it's still a bit hacked together with hard coded
windowstate and portletmode. But at least my ajax request is comming through to
the wicket code and is updating my simple counter.
However the ajax response is still not working correctly. First of all I had to
change Liferay to except response.setContentType("text/xml"). Now I get a full
Liferay page back with in it included the xml part generated by
Wicket. That's what I'll try to dive into tomorrow.
It's a really strange problem because AjaxRequestTarget#respond first calls
WebResponse.setHeader(), then it should call WebResponse.write(..) but my log
never shows any logging from inside that method while I do get (added) logging
from inside setHeader().
> Ajax link is different from normal link on Liferay Portal
> -
>
> Key: WICKET-1132
> URL: https://issues.apache.org/jira/browse/WICKET-1132
> Project: Wicket
> Issue Type: Bug
> Components: wicket-portlet
>Affects Versions: 1.3.0-beta4
> Environment: Liferay 4.3.3 on Tomcat 6
>Reporter: Thijs Vonk
>Assignee: Ate Douma
> Fix For: 1.3.0-rc2
>
>
> I created 2 simple Links a AjaxLink and a 'normal' link in a portlet. I
> deployed this portlet on Liferay. The normal link works fine. But the Ajax
> links doesn't work. In the generated HTML the url's look like this.
> AJAX link:
> http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet&p_p_action=1&p_p_col_id=column-1&p_p_col_count=1&;',null,null,
> function() {return Wicket.$$(this)}.bind(this));return !wcall;"
> id="id__MiniPortlet__WAR__MiniPortlet1link1">
> Normal link:
> href="http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet_WAR_MiniPortlet1&p_p_action=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_MiniPortlet_WAR_MiniPortlet1__wu=%2Fminiportlet%2F%3Fwicket%3Ainterface%3D%3A0%3Alink2%3A%3AILinkListener%3A%3A";
> wicket:id="link2">
> At this moment the p_p_id is the part that I'm looking into. As you can see
> they are different. And for Liferay this part tels it which portlet it should
> send the request to. The normal link is the correct path to the portlet. as
> this action actually works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1158) DiskPageStore does not cleanup cache files after Web container restarts
[ https://issues.apache.org/jira/browse/WICKET-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1158. --- Resolution: Duplicate this one will be fixed when WICKET-1161 is fixed. > DiskPageStore does not cleanup cache files after Web container restarts > --- > > Key: WICKET-1158 > URL: https://issues.apache.org/jira/browse/WICKET-1158 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta3, 1.3.0-beta4, 1.3.0-rc1 >Reporter: chris lintz > Fix For: 1.3.0-rc2 > > > DiskPageStore does not cleanup cache files after Web container restarts. We > have leaked cache files on disk which is a bad thing from the perspective of > a high traffic site. This occurs when Tomcat (or I am sure other Web > container) is restarted. My theory is the HttpSessionListener bound to the > page store file cannot be called because the session reference is lost. It > can be argued that a framework generating resources on disk is responsible > for the cleanup - with the exception of logs :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1161) DiskPageStore should write the sessions index file to disk on destroy (from WicketFilter.destroy())
DiskPageStore should write the sessions index file to disk on destroy (from WicketFilter.destroy()) --- Key: WICKET-1161 URL: https://issues.apache.org/jira/browse/WICKET-1161 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-rc1 Reporter: Johan Compagner Assignee: Matej Knopp Fix For: 1.3.0-rc2 We have to save the sessions index to disk from the DiskPageStore when we get a shutdown/destroy from the servlet container (I hope that that that event will be called on a servlet container shutdown and on a undeploy/redeploy of the webapp.) Then with a destroy we save it. When we are fired up again we read that file and also delete the file immediantly. Then when the page store is created and the file isn't there it can delete all the page stores files that are currently on disk because the destroy didn't happen so it was a crash or a hard kill and there won't be any sessions anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Spring (page edited)
Page Edited :
WICKET :
Spring
Spring
has been edited by Michael Laccetti
(Nov 14, 2007).
Change summary:
Added warning that Constructor-based injection doesn't work with @SpringBean
(View changes)
Content:
Bookmarkable link
Table of contents
The Issues
Wicket is an unmanaged framework
Wicket components and models are often serialized
Solutions
Application Object Approach
Proxy-based Approach
Annotation-based Approach
Unit Testing the Proxy Approach
Beyond Spring
wicket-spring project is in the subversion alongside wicket
also look at wicket-spring-examples, wicket-spring-annot, and wicket-spring-annot-examples projects.
Some knowledge of spring is required
In wicket the Page class is a subclass of Component, so from here on the word component can represent either a component or a page.
This is only the first pass at the documentation so its far from perfect
Feel free to add new content and fix any mistakes you find.
The Issues
Most problems with injecting dependencies from an IOC container come from the following
wicket is an unmanaged framework
wicket components and models are often serialized
Wicket is an unmanaged framework
Wicket does not manage the lifecycle of its components. This means that a page or a component can be created anywhere in the code by simply using the new operator. This makes it difficult to inject dependencies because it is difficult to intercept the creation of the component. A possible solution can be to use a singleton factory to create the components and subsequently inject them with dependencies. However, this approach is not very flexible because it is often more convinient to have specific constructors in components rather then the default empty constructor. ie
class EditUserPage extends WebPage {
public EditUserPage(long userId) {...}
}
...
setResponsePage(new EditUserPage(userId));
is far more convenient than
class EditUserPage extends WebPage {
public EditUserPage() {...}
void setUserId(long userId) {...}
}
...
PageFactory factory=getPageFactory();
EditUserPage page=(EditUserPage)factory.createPage(EditUserPage.class);
page.setUserId(userId);
setResponsePage(page);
Wicket components and models are often serialized
Wicket keeps its tree of components in the session. In a clustered environment, session data needs to be replicated across the cluster. This is done by serializing objects in a cluster-node's session and deserializing them on another cluster-node's session. This presents a problem for dependency injection because it is not desirable to serialize the dependency. Dependencies often have references to other dependencies in the container, and so if one is serialized it will probably serialize a few others and can possibly cascade to serializing the entire container. To say the least, this is undesirable. Even if the cascading is not a problem and the dependency is serialized, when it deserializes it will no longer be part of the conainer - it will be a stand alone clone. This is also undesirable.
Solutions
Application Object Approach
Wicket applications have a global application object which is a subclass of Application. This global application object is only created once per application and is never serialized (since it contains no user-specific data and thus remains the same across all nodes in the cluster). These qualities make it a good candidate to act as a service locator for the rest of the application. Wicket allows you to provide a custom factory for creating this object, the wicket-contrib-spring project provides such a factory (SpringWebApplicationFactory) that, instead of creating an instance, pulls it out of the spring application context. Wicket keeps the instance of the application object in a threadlocal variable and provides various helper methods in components to get to it, so it is easy to retrieve dependencies in wicket components.
Example:
web.xml:
...
wicket
wicket.protocol.http.WicketServlet
applicationFactoryClassName
wicket.spring.SpringWebApplicationFactory
1
...
contextConfigLocation
/WEB-INF/applicationContext.xml
org.springframework.web.context.ContextLoaderListener
...
applicationContext.xml:
...
"wicketApplication" class="project.MyApplication">
"contactDao" ref="contactDao"/>
...
code:
class MyApplication extends WebApplication {
private ContactDao dao;
public void setContactDao(ContactDao dao) { this.dao=dao; }
public ContactDao getContactDao() { return dao; }
}
class BasePage extends WebPage {
ContactDao getContactDao() {
return ((MyApplication)getApplication()).getContactDao();
}
class EditContact extends BasePage {
public EditContact(long id) {
Form form=new Form("form",...)
[jira] Commented: (WICKET-1139) Wicket html files do not have xml prolog
[ https://issues.apache.org/jira/browse/WICKET-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542555 ] Marat Radchenko commented on WICKET-1139: - Hi, Juergen. I do not ask to specify any encoding to be sent to client. And I do not ask to specify default encoding for parsing of all markup files or for client output. I just ask to explicitly specify any encoding that you consider appropriate for Wicket built-in html files. It doesn't have to be UTF-8. It can have absolutely any value that will allow correct file reading. I know that this encoding is used for loading only. The point is that we want to force all html files in our application to explicitly specify encoding (because platform default may [an will] be inacceptable). And in current situation we have to duplicate all Wicket htmls with addition of xml prolog. As additional argument, you cannot be sure that all current and future encodings that can possibly be set as platform default will correctly load your html files. So explicit specifying will protect you against possible environment-specific errors. > Wicket html files do not have xml prolog > > > Key: WICKET-1139 > URL: https://issues.apache.org/jira/browse/WICKET-1139 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: n/a >Reporter: Marat Radchenko > Fix For: 1.3.0-rc2 > > > We want to enforce all our pages to explicitly specify xml prolog in order to > avoid troubles with encodings (unfortunately we are not ASCII-speaking). We > want to do that by specifying invalid defaultMarkupEncoding. This way we will > get exceptions for all htmls that didn't declare encoding. However it is not > possible at the moment because many wicket built-in html files do not have > xml prolog. > Fix is very simple: just add to your > html files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-1102) Hello World example should use WicketFilter instead of WicketServlet
[ https://issues.apache.org/jira/browse/WICKET-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Sullivan reopened WICKET-1102: --- I am reopening because there is still a minor error on the web page. > Hello World example should use WicketFilter instead of WicketServlet > > > Key: WICKET-1102 > URL: https://issues.apache.org/jira/browse/WICKET-1102 > Project: Wicket > Issue Type: Improvement > Components: site >Affects Versions: 1.3.0-rc1 >Reporter: Sean Sullivan >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 1.3.0-rc2 > > > URL: http://wicket.apache.org/examplehelloworld.html > 1) Wicket's Hello World example should use WicketFilter instead of > WicketServlet > 2) the imports are wrong. Package names should be org.apache.wicket > 3) bad javadoc comment: "WicketServlet class for hello world example" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1102) Hello World example should use WicketFilter instead of WicketServlet
[ https://issues.apache.org/jira/browse/WICKET-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542546 ] Sean Sullivan commented on WICKET-1102: --- Thanks for updating the site: http://wicket.apache.org/examplehelloworld.html There is still a minor problem in the "Ready to deploy" section 1) http://localhost:8080/helloworld/app is incorrect. Please remove the /app 2) http:app is possibly confusing. I would remove the /app > Hello World example should use WicketFilter instead of WicketServlet > > > Key: WICKET-1102 > URL: https://issues.apache.org/jira/browse/WICKET-1102 > Project: Wicket > Issue Type: Improvement > Components: site >Affects Versions: 1.3.0-rc1 >Reporter: Sean Sullivan >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 1.3.0-rc2 > > > URL: http://wicket.apache.org/examplehelloworld.html > 1) Wicket's Hello World example should use WicketFilter instead of > WicketServlet > 2) the imports are wrong. Package names should be org.apache.wicket > 3) bad javadoc comment: "WicketServlet class for hello world example" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1139) Wicket html files do not have xml prolog
[ https://issues.apache.org/jira/browse/WICKET-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542544 ] Juergen Donnerstag commented on WICKET-1139: the encoding given in the markup file is always only used for loading the data and will never be forwarded to the client browser. We use Settings (and configureResponse) to determine what goes into the response and that setting is applied to all responses (except you define different in configureResponse). In my opinion this is not a valid request. Our internal markup files do not contain any none-ascii characters. If a user wants to supersede with an extended subclass and add to the his own markup than that is perfectly fine. As mentioned above we are using it for loading only and it is perfectly fine to mix and match different encoding. No means that the JVM / OS default will be used. > Wicket html files do not have xml prolog > > > Key: WICKET-1139 > URL: https://issues.apache.org/jira/browse/WICKET-1139 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: n/a >Reporter: Marat Radchenko > Fix For: 1.3.0-rc2 > > > We want to enforce all our pages to explicitly specify xml prolog in order to > avoid troubles with encodings (unfortunately we are not ASCII-speaking). We > want to do that by specifying invalid defaultMarkupEncoding. This way we will > get exceptions for all htmls that didn't declare encoding. However it is not > possible at the moment because many wicket built-in html files do not have > xml prolog. > Fix is very simple: just add to your > html files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1132) Ajax link is different from normal link on Liferay Portal
[
https://issues.apache.org/jira/browse/WICKET-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542541
]
Thijs Vonk commented on WICKET-1132:
I finally had some time to look into this today and I've made some great
progress.
I now know way the url was different. The difference in p_p_id was caused by a
wrong implementation in LiferayToPortalBridgePortletResourceURLFactory as
posted in http://www.nabble.com/forum/ViewPost.jtp?post=13306973&framed=y by
Charles.
It should not use the portletConfig.getPortletName() but a custom Liferay
portletConfig.getPortletId() which gives the full portlet instance name.
Also this class misses things like Windowstate and portletmode.
I have something working now, it's still a bit hacked together with hard coded
windowstate and portletmode. But at least my ajax request is comming through to
the wicket code and is updating my simple counter.
However the ajax response is still not working correctly. First of all I had to
change Liferay to except response.setContentType("text/xml"). Now I get a full
Liferay page back with in it included the xml part generated by
Wicket. That's what I'll try to dive into tomorrow.
It's a really strange problem because AjaxRequestTarget#respond first calls
WebResponse.setHeader(), then it should call WebResponse.write(..) but my log
never shows any logging from inside that method while I do get (added) logging
from inside setHeader().
> Ajax link is different from normal link on Liferay Portal
> -
>
> Key: WICKET-1132
> URL: https://issues.apache.org/jira/browse/WICKET-1132
> Project: Wicket
> Issue Type: Bug
> Components: wicket-portlet
>Affects Versions: 1.3.0-beta4
> Environment: Liferay 4.3.3 on Tomcat 6
>Reporter: Thijs Vonk
>Assignee: Ate Douma
> Fix For: 1.3.0-rc2
>
>
> I created 2 simple Links a AjaxLink and a 'normal' link in a portlet. I
> deployed this portlet on Liferay. The normal link works fine. But the Ajax
> links doesn't work. In the generated HTML the url's look like this.
> AJAX link:
> http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet&p_p_action=1&p_p_col_id=column-1&p_p_col_count=1&;',null,null,
> function() {return Wicket.$$(this)}.bind(this));return !wcall;"
> id="id__MiniPortlet__WAR__MiniPortlet1link1">
> Normal link:
> href="http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet_WAR_MiniPortlet1&p_p_action=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_MiniPortlet_WAR_MiniPortlet1__wu=%2Fminiportlet%2F%3Fwicket%3Ainterface%3D%3A0%3Alink2%3A%3AILinkListener%3A%3A";
> wicket:id="link2">
> At this moment the p_p_id is the part that I'm looking into. As you can see
> they are different. And for Liferay this part tels it which portlet it should
> send the request to. The normal link is the correct path to the portlet. as
> this action actually works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1102) Hello World example should use WicketFilter instead of WicketServlet
[ https://issues.apache.org/jira/browse/WICKET-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwyn Evans closed WICKET-1102. -- Resolution: Fixed Thanks for reporting. > Hello World example should use WicketFilter instead of WicketServlet > > > Key: WICKET-1102 > URL: https://issues.apache.org/jira/browse/WICKET-1102 > Project: Wicket > Issue Type: Improvement > Components: site >Affects Versions: 1.3.0-rc1 >Reporter: Sean Sullivan >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 1.3.0-rc2 > > > URL: http://wicket.apache.org/examplehelloworld.html > 1) Wicket's Hello World example should use WicketFilter instead of > WicketServlet > 2) the imports are wrong. Package names should be org.apache.wicket > 3) bad javadoc comment: "WicketServlet class for hello world example" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1132) Ajax link is different from normal link on Liferay Portal
[
https://issues.apache.org/jira/browse/WICKET-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542523
]
Ate Douma commented on WICKET-1132:
---
I've already commented on this issue on the lists and AFAIK this seems to be a
Liferay Portal internal issue, although difficult for me to be sure about
without actually testing/debugging on Liferay myself.
I'm hoping Thijs can get some Liferay developers involved in this, or else I
might need to take this up with some of the Liferay architects directly I know
from the JSR-286 EG team.
I won't have time for this until later *next* week the earliest though, but we
definitely should try to get this working in at least one other portal, like
Liferay, just to prove the point the portlet support really is generic enough.
The fact that Thijs already seems to have it working for the non Ajax cases
really is cool for sure.
> Ajax link is different from normal link on Liferay Portal
> -
>
> Key: WICKET-1132
> URL: https://issues.apache.org/jira/browse/WICKET-1132
> Project: Wicket
> Issue Type: Bug
> Components: wicket-portlet
>Affects Versions: 1.3.0-beta4
> Environment: Liferay 4.3.3 on Tomcat 6
>Reporter: Thijs Vonk
>Assignee: Ate Douma
> Fix For: 1.3.0-rc2
>
>
> I created 2 simple Links a AjaxLink and a 'normal' link in a portlet. I
> deployed this portlet on Liferay. The normal link works fine. But the Ajax
> links doesn't work. In the generated HTML the url's look like this.
> AJAX link:
> http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet&p_p_action=1&p_p_col_id=column-1&p_p_col_count=1&;',null,null,
> function() {return Wicket.$$(this)}.bind(this));return !wcall;"
> id="id__MiniPortlet__WAR__MiniPortlet1link1">
> Normal link:
> href="http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet_WAR_MiniPortlet1&p_p_action=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_MiniPortlet_WAR_MiniPortlet1__wu=%2Fminiportlet%2F%3Fwicket%3Ainterface%3D%3A0%3Alink2%3A%3AILinkListener%3A%3A";
> wicket:id="link2">
> At this moment the p_p_id is the part that I'm looking into. As you can see
> they are different. And for Liferay this part tels it which portlet it should
> send the request to. The normal link is the correct path to the portlet. as
> this action actually works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1102) Hello World example should use WicketFilter instead of WicketServlet
[ https://issues.apache.org/jira/browse/WICKET-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542516 ] Martijn Dashorst commented on WICKET-1102: -- Yep, I saw the issue passing by and figured what the hell If you can check the code and close the issue that would be awesome :) > Hello World example should use WicketFilter instead of WicketServlet > > > Key: WICKET-1102 > URL: https://issues.apache.org/jira/browse/WICKET-1102 > Project: Wicket > Issue Type: Improvement > Components: site >Affects Versions: 1.3.0-rc1 >Reporter: Sean Sullivan >Assignee: Martijn Dashorst >Priority: Minor > Fix For: 1.3.0-rc2 > > > URL: http://wicket.apache.org/examplehelloworld.html > 1) Wicket's Hello World example should use WicketFilter instead of > WicketServlet > 2) the imports are wrong. Package names should be org.apache.wicket > 3) bad javadoc comment: "WicketServlet class for hello world example" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1127) Using Buttons in Palette component
[ https://issues.apache.org/jira/browse/WICKET-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-1127. --- Resolution: Won't Fix those overridable factory methods you use in your patch exist for this exact case - let you customize the palette. i dont see why button components should be the default implementation as opposed to what there is now. like you did, you can always customize it. > Using Buttons in Palette component > -- > > Key: WICKET-1127 > URL: https://issues.apache.org/jira/browse/WICKET-1127 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.2.6 >Reporter: Volodymyr Sobotovich >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.3.0-rc2 > > Attachments: patch.java > > > 1. It would be more convenient to use component Button instead of > WebMarkupContainer for "add", "remove", "up" and "down" buttons. It will > allow user to enable or disable them and update via ajax. > 2. It would be nice to store these buttons as protected members of Palette to > give subclasses access to them. > For the workaround been used to gain the functionality see attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1098) AjaxEditableLabel: add method to override edit-event
[ https://issues.apache.org/jira/browse/WICKET-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kriesten updated WICKET-1098: - Attachment: ael.patch Hi Johan, thanks for looking into it. I attached a small patch which should be sufficient. Best regards, --- Jan. > AjaxEditableLabel: add method to override edit-event > > > Key: WICKET-1098 > URL: https://issues.apache.org/jira/browse/WICKET-1098 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.3.0-beta4 > Environment: any >Reporter: Jan Kriesten >Assignee: Johan Compagner >Priority: Minor > Fix For: 1.3.0-rc2 > > Attachments: ael.patch > > > Currently, as event 'onclick' is hardcoded in AjaxEditableLabel. To change > this behavior, a bunch of logic has to be copied. It would be nice, if there > was a method > newLabelAjaxBehavior(String event) > which could be easily overriden. > Might apply to other AjaxEdit-Components as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-861) NumberFormatException with UrlCompressingWebRequestProcessor in WicketTester
[
https://issues.apache.org/jira/browse/WICKET-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542491
]
Johan Compagner commented on WICKET-861:
do you have a complete unit test case for us?
> NumberFormatException with UrlCompressingWebRequestProcessor in WicketTester
>
>
> Key: WICKET-861
> URL: https://issues.apache.org/jira/browse/WICKET-861
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-beta3
> Environment: Wicket 1.3.0 from Trunk
> JDK 6
>Reporter: Rüdiger Schulz
>Priority: Minor
> Fix For: 1.3.0-rc2
>
>
> In my Application I use UrlCompressingWebRequestProcessor. Now I have a JUnit
> test case with WicketTester and that Application like this:
> tester.startPage(new ITestPageSource() {
> public Page getTestPage() {
> PageParameters params = new PageParameters();
> params.add("0", "param");
> return new MyPage(params);
> }
> });
> I get an Exception:
> java.lang.NumberFormatException: For input string: "testPage"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:447)
> at java.lang.Integer.parseInt(Integer.java:497)
> at
> org.apache.wicket.protocol.http.request.urlcompressing.UrlCompressor.getComponentAndInterfaceForUID(UrlCompressor.java:124)
> at
> org.apache.wicket.protocol.http.request.urlcompressing.UrlCompressingWebRequestProcessor.resolveListenerInterfaceTarget(UrlCompressingWebRequestProcessor.java:81)
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:440)
> at
> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1091)
> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177)
> at org.apache.wicket.RequestCycle.request(RequestCycle.java:500)
> at
> org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(MockWebApplication.java:381)
> at
> org.apache.wicket.protocol.http.MockWebApplication.processRequestCycle(MockWebApplication.java:368)
> at
> org.apache.wicket.util.tester.BaseWicketTester.executeListener(BaseWicketTester.java:239)
> at
> org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:224)
> I could work around this by using WebRequestCycleProcessor for my
> testing-application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-753) mounts stored in non-ordered map
[ https://issues.apache.org/jira/browse/WICKET-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-753. -- Resolution: Won't Fix i just tested it some more. But subclasses are not auto mounted! We do a direct equals check on class And we also should do that because how do we know if we hit a mount point which class or subclass to create? So if you mount subclasses on /bar then that will work fine. i close it for now, if you have another idea or what really doesn't work please reopen. > mounts stored in non-ordered map > > > Key: WICKET-753 > URL: https://issues.apache.org/jira/browse/WICKET-753 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Jonathan Locke >Assignee: Jonathan Locke >Priority: Minor > Fix For: 1.3.0-final > > > Because WebRequestCodingStrategy now uses a map to store mounted encoders (it > was meant to be a list for exactly the reason this bug is being submitted), > it is no longer possible to override encoders based on subclasses. For > example, if you mount Foo on "/foo" and Foo has subclasses Bar and Baz, those > subclasses are also mounted on "/foo", which is good. But then mounting Bar > on "/bar" does not (or at least MAY not) override this functionality even if > you install it before the "/foo" mount (which i would expect to work). To > resolve this issue, encoders ought to be searched for a match in the order > that they were added and not in some random order defined by the map they are > being stored in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-753) mounts stored in non-ordered map
[ https://issues.apache.org/jira/browse/WICKET-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-753: --- Fix Version/s: (was: 1.3.0-final) > mounts stored in non-ordered map > > > Key: WICKET-753 > URL: https://issues.apache.org/jira/browse/WICKET-753 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Jonathan Locke >Assignee: Jonathan Locke >Priority: Minor > > Because WebRequestCodingStrategy now uses a map to store mounted encoders (it > was meant to be a list for exactly the reason this bug is being submitted), > it is no longer possible to override encoders based on subclasses. For > example, if you mount Foo on "/foo" and Foo has subclasses Bar and Baz, those > subclasses are also mounted on "/foo", which is good. But then mounting Bar > on "/bar" does not (or at least MAY not) override this functionality even if > you install it before the "/foo" mount (which i would expect to work). To > resolve this issue, encoders ought to be searched for a match in the order > that they were added and not in some random order defined by the map they are > being stored in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1139) Wicket html files do not have xml prolog
[ https://issues.apache.org/jira/browse/WICKET-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542488 ] Marat Radchenko commented on WICKET-1139: - Your files are ASCII-only and so they do not care a lot about exact encoding. You can specify UTF-8 or ISO 8859-1 (or some other because all encodings (as far as I know) have same byte numbers for ASCII symbols). Affected files (list may be incomplete): org/apache/wicket/markup/html/panel/FeedbackPanel.html org/apache/wicket/markup/html/panel/EmptyPanel.html org/apache/wicket/markup/html/pages/RedirectPage.html org/apache/wicket/markup/html/pages/PageExpiredErrorPage.html org/apache/wicket/markup/html/pages/InternalErrorPage.html org/apache/wicket/markup/html/pages/ExceptionErrorPage.html org/apache/wicket/markup/html/pages/AccessDeniedPage.html > Wicket html files do not have xml prolog > > > Key: WICKET-1139 > URL: https://issues.apache.org/jira/browse/WICKET-1139 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: n/a >Reporter: Marat Radchenko > Fix For: 1.3.0-rc2 > > > We want to enforce all our pages to explicitly specify xml prolog in order to > avoid troubles with encodings (unfortunately we are not ASCII-speaking). We > want to do that by specifying invalid defaultMarkupEncoding. This way we will > get exceptions for all htmls that didn't declare encoding. However it is not > possible at the moment because many wicket built-in html files do not have > xml prolog. > Fix is very simple: just add to your > html files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-753) mounts stored in non-ordered map
[ https://issues.apache.org/jira/browse/WICKET-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542487 ] Johan Compagner commented on WICKET-753: the order is not random! this is the map: map = new TreeMap(LENGTH_COMPARATOR); it is sorted based on the string "length" of the mount point. so that "/foo/bar" is matched before "/foo" Maybe it is better to test if a class has a direct mount hit before also testing if a super class has a mount hit.. Because i think people shouldn't start wondering how they add all there mount points. > mounts stored in non-ordered map > > > Key: WICKET-753 > URL: https://issues.apache.org/jira/browse/WICKET-753 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Jonathan Locke >Assignee: Jonathan Locke >Priority: Minor > Fix For: 1.3.0-final > > > Because WebRequestCodingStrategy now uses a map to store mounted encoders (it > was meant to be a list for exactly the reason this bug is being submitted), > it is no longer possible to override encoders based on subclasses. For > example, if you mount Foo on "/foo" and Foo has subclasses Bar and Baz, those > subclasses are also mounted on "/foo", which is good. But then mounting Bar > on "/bar" does not (or at least MAY not) override this functionality even if > you install it before the "/foo" mount (which i would expect to work). To > resolve this issue, encoders ought to be searched for a match in the order > that they were added and not in some random order defined by the map they are > being stored in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1008) Creating a bookmarkable link in code does not generate "pretty url" when the page has been mounted.
[
https://issues.apache.org/jira/browse/WICKET-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner closed WICKET-1008.
---
Resolution: Cannot Reproduce
Fix Version/s: (was: 1.3.0-rc2)
see http://wicketstuff.org/wicket13/niceurl/the/homepage/path
those are all mounted pages with bookmarkable links:
add(new BookmarkablePageLink("page1Link", Page1.class));
and those are working fine.
Please give us a testcase or quickstart that demonstrates your problem
> Creating a bookmarkable link in code does not generate "pretty url" when the
> page has been mounted.
> ---
>
> Key: WICKET-1008
> URL: https://issues.apache.org/jira/browse/WICKET-1008
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.0-beta3
>Reporter: Michael Chack
>Priority: Minor
>
> I have created mounted pages for my application. When using the wicket:link
> tag, a pretty url is generated. In cases where I use wicket:id and the
> associated BookmarkablePageLink the generated URL does not reflect the mount
> path and uses the "ugly" url.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1127) Using Buttons in Palette component
[ https://issues.apache.org/jira/browse/WICKET-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1127: Fix Version/s: 1.3.0-rc2 Assignee: Igor Vaynberg > Using Buttons in Palette component > -- > > Key: WICKET-1127 > URL: https://issues.apache.org/jira/browse/WICKET-1127 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.2.6 >Reporter: Volodymyr Sobotovich >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.3.0-rc2 > > Attachments: patch.java > > > 1. It would be more convenient to use component Button instead of > WebMarkupContainer for "add", "remove", "up" and "down" buttons. It will > allow user to enable or disable them and update via ajax. > 2. It would be nice to store these buttons as protected members of Palette to > give subclasses access to them. > For the workaround been used to gain the functionality see attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1158) DiskPageStore does not cleanup cache files after Web container restarts
[ https://issues.apache.org/jira/browse/WICKET-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1158: Fix Version/s: 1.3.0-rc2 we could introduce a special property that the developer has to configure with a specific time in minutes or hours and when files are older then that time they are removed. By default this value is 0 or -1 so nothing happens. So you have to configure it before it works. > DiskPageStore does not cleanup cache files after Web container restarts > --- > > Key: WICKET-1158 > URL: https://issues.apache.org/jira/browse/WICKET-1158 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta3, 1.3.0-beta4, 1.3.0-rc1 >Reporter: chris lintz > Fix For: 1.3.0-rc2 > > > DiskPageStore does not cleanup cache files after Web container restarts. We > have leaked cache files on disk which is a bad thing from the perspective of > a high traffic site. This occurs when Tomcat (or I am sure other Web > container) is restarted. My theory is the HttpSessionListener bound to the > page store file cannot be called because the session reference is lost. It > can be argued that a framework generating resources on disk is responsible > for the cleanup - with the exception of logs :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1105) Missing javascript header referencies when there are no body or head tags.
[ https://issues.apache.org/jira/browse/WICKET-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1105: Component/s: (was: wicket-portlet) wicket Fix Version/s: 1.3.0-rc2 Summary: Missing javascript header referencies when there are no body or head tags. (was: Missing javascript header referencies in Wicket portlet) > Missing javascript header referencies when there are no body or head tags. > -- > > Key: WICKET-1105 > URL: https://issues.apache.org/jira/browse/WICKET-1105 > Project: Wicket > Issue Type: Bug > Components: wicket > Environment: wicket trunk revision 588784 > JDK 1.5.0_13-b05 > Maven version: 2.0.7 >Reporter: Michal Capo >Assignee: Juergen Donnerstag > Fix For: 1.3.0-rc2 > > Attachments: wicket-portlets-test.zip > > > I have two wicket portlets using RatingPanel they are almost same. There is > one difference in the markup. > First: > > > > > > > Second: > > > > In first one is request executed via ajax. In second one not. In first one > rendered page contains reference to 'wicket-ajax.js' file but in the second > not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1094) Values over-escaped by FormTester
[
https://issues.apache.org/jira/browse/WICKET-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1094:
Fix Version/s: 1.3.0-rc2
can't this be fixed by not setting that property hard? But by unescaping it
again on the right places where those escaped values are get from?
> Values over-escaped by FormTester
> -
>
> Key: WICKET-1094
> URL: https://issues.apache.org/jira/browse/WICKET-1094
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.3.0-beta4
>Reporter: David Shepherdson
> Fix For: 1.3.0-rc2
>
>
> FormTester's constructor contains code that visits all components on the form
> and calls setFormComponentValue(formComponent, formComponent.getValue()) (or
> variations thereof), to store the component's value in the servlet request
> parameters. However, by default, FormComponent's getValue() method uses
> Strings.escapeMarkup(...) to encode any special characters, such as angle
> brackets. This is fine in a 'real' environment, where a Web browser will be
> responsible for displaying the escaped characters with their proper values,
> and so the proper value will be the one that comes through when the form is
> submitted; however, in the Wicket test environment, there isn't anything to
> do that extra level of 'un-escaping', meaning there's a danger of the form
> components being given escaped values when the form is submitted.
> For example, we have a form that contains a text area, whose value contains a
> URI enclosed in angle brackets, like so:
> < http://test.com/ >
> When we submit the form with a Web browser, the value set on the model is
> exactly that string -- '< http://test.com/ >'. However, when we test our page
> with FormTester, the FormTester constructor calls getValue() on the
> component, which by default returns the escaped form:
> < http://test.com/ >
> When the form is submitted, this is the value set on the model, and so
> comparisons to the original string fail.
> (Extra spaces inserted into the strings above to make them display properly
> in JIRA.)
> However, if FormTester were to call setEscapeModelStrings(false) on the form
> component before calling getValue() (and then restore the original escaping
> setting afterwards), then the value that ends up being provided to the
> component at the end would be the correct (unescaped) value, matching the
> behaviour when using the page in a browser.
> We have worked around this issue by overriding FormTester with a class that
> performs a second traversal of the form component hierarchy after calling the
> FormTester constructor, replacing the incorrectly escaped values with the
> proper ones (changes marked with '// O-P'):
> public OurFormTester(String path, Form workingForm, BaseWicketTester
> wicketTester, boolean fillBlankString) {
> super(path, workingForm, wicketTester, fillBlankString);
> fixFormParameterValues(workingForm, fillBlankString);
> }
>
> protected void fixFormParameterValues(Form workingForm, final boolean
> fillBlankString) {
> workingForm.visitFormComponents(new FormComponent.AbstractVisitor()
> {
> public void onFormComponent(final FormComponent formComponent)
> {
> // do nothing for invisible component
> if (!formComponent.isVisibleInHierarchy())
> {
> return;
> }
> // O-P Preserve old escaping value, then turn escaping off
> // so that values aren't escaped unnecessarily.
> boolean oldEscaping = formComponent.getEscapeModelStrings();
> formComponent.setEscapeModelStrings(false);
>
> // if component is text field and do not have exist value,
> fill
> // blank String if required
> if (formComponent instanceof AbstractTextComponent)
> {
> if (Strings.isEmpty(formComponent.getValue()))
> {
> if (fillBlankString)
> {
> setFormComponentValue(formComponent, "");
> }
> }
> else
> {
> setFormComponentValue(formComponent,
> formComponent.getValue());
> }
> }
> else if ( (formComponent instanceof DropDownChoice) ||
> (formComponent instanceof RadioChoice) ||
> (formComponent instanceof CheckBox))
> {
> setFormComponentValue(formComponent,
> formComponent.getValue());
> }
> else if (formComp
[jira] Updated: (WICKET-1139) Wicket html files do not have xml prolog
[ https://issues.apache.org/jira/browse/WICKET-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1139: Fix Version/s: 1.3.0-rc2 can we just add the UTF-8 encoding to all our files? Are they then saved as UTF-8 as well? Also if it is panel then we can do it. Because that part is just for loading. But if it are pages then it is not that easy because then we also have that in the resulting page as far as i know. > Wicket html files do not have xml prolog > > > Key: WICKET-1139 > URL: https://issues.apache.org/jira/browse/WICKET-1139 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: n/a >Reporter: Marat Radchenko > Fix For: 1.3.0-rc2 > > > We want to enforce all our pages to explicitly specify xml prolog in order to > avoid troubles with encodings (unfortunately we are not ASCII-speaking). We > want to do that by specifying invalid defaultMarkupEncoding. This way we will > get exceptions for all htmls that didn't declare encoding. However it is not > possible at the moment because many wicket built-in html files do not have > xml prolog. > Fix is very simple: just add to your > html files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1093) BaseWicketTester doesn't call detach() for AJAX requests
[
https://issues.apache.org/jira/browse/WICKET-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner closed WICKET-1093.
---
Resolution: Fixed
Fix Version/s: 1.3.0-rc2
> BaseWicketTester doesn't call detach() for AJAX requests
>
>
> Key: WICKET-1093
> URL: https://issues.apache.org/jira/browse/WICKET-1093
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.3.0-beta4
>Reporter: David Shepherdson
> Fix For: 1.3.0-rc2
>
>
> BaseWicketTester doesn't call detach() on the request cycle when clicking an
> AJAX link. This does not match the behaviour when running in a 'real' servlet
> container, when detach() *does* get called for the same AJAX requests.
> One side effect of this is that AJAX header contributions are left in the
> page and cause problems when the next request occurs. For example, we have a
> page that we want to test. It contains an AJAX link and a (non-AJAX) form. We
> click the link, then fill in and submit the form. However, an exception is
> thrown when submitting the form as it tries to render the AJAX header
> contribution left over from the AJAX page. (Exception comes from
> checkHeaderRendering() in AjaxHeaderResponse.)
> We are working around this problem by overriding BaseWicketTester's
> clickLink(String, boolean) method, so as to hang onto the RequestCycle and
> call its detach() method once the response has been made for AJAX requests;
> for example:
> RequestCycle requestCycle = null;
> if (linkComponent instanceof AjaxLink) {
> ...
> setupRequestAndResponse();
> requestCycle = createRequestCycle();
> AjaxRequestTarget target = new AjaxRequestTarget(link.getPage());
> requestCycle.setRequestTarget(target);
> link.onClick(target);
> target.respond(requestCycle);
> }
> ...
> if (requestCycle != null) {
> // Detach the requestCycle, so that state isn't left around
> // for any further use of this page.
> requestCycle.detach();
> }
> This should be a very simple one-line fix (well, 1 x the number of AJAX
> requests made in BaseWicketTester's clickLink(...) method, which is 3).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r594913 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
Author: jcompagner
Date: Wed Nov 14 06:52:38 2007
New Revision: 594913
URL: http://svn.apache.org/viewvc?rev=594913&view=rev
Log:
call detach for all the ajax clicks WICKET-1093
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java?rev=594913&r1=594912&r2=594913&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
Wed Nov 14 06:52:38 2007
@@ -330,7 +330,7 @@
public FormTester newFormTester(String path, boolean fillBlankString)
{
return new FormTester(path,
(Form)getComponentFromLastRenderedPage(path), this,
- fillBlankString);
+ fillBlankString);
}
/**
@@ -467,7 +467,7 @@
if (component == null)
{
fail("path: '" + path + "' does not exist for page: " +
-
Classes.simpleName(getLastRenderedPage().getClass()));
+
Classes.simpleName(getLastRenderedPage().getClass()));
return component;
}
if (component.isVisibleInHierarchy())
@@ -538,8 +538,8 @@
{
Component component = getComponentFromLastRenderedPage(path);
return isTrue("component '" +
Classes.simpleName(component.getClass()) + "' is not type:" +
- Classes.simpleName(expectedComponentClass),
expectedComponentClass
- .isAssignableFrom(component.getClass()));
+ Classes.simpleName(expectedComponentClass),
+
expectedComponentClass.isAssignableFrom(component.getClass()));
}
/**
@@ -555,7 +555,7 @@
if (component == null)
{
fail("path: '" + path + "' does no exist for page: " +
-
Classes.simpleName(getLastRenderedPage().getClass()));
+
Classes.simpleName(getLastRenderedPage().getClass()));
}
return isTrue("component '" + path + "' is not visible",
component.isVisible());
@@ -583,7 +583,7 @@
public Result ifContains(String pattern)
{
return isTrue("pattern '" + pattern + "' not found",
getServletResponse().getDocument()
- .matches("(?s).*" + pattern + ".*"));
+ .matches("(?s).*" + pattern + ".*"));
}
/**
@@ -652,7 +652,7 @@
if (isAjax == false)
{
fail("Link " + path + "is an AjaxLink and will
" +
- "not be invoked when AJAX
(javascript) is disabled.");
+ "not be invoked when AJAX (javascript)
is disabled.");
}
AjaxLink link = (AjaxLink)linkComponent;
@@ -666,6 +666,7 @@
// process the request target
target.respond(requestCycle);
+ requestCycle.detach();
}
// AjaxFallbackLinks is processed like an AjaxLink if isAjax is
true
// If it's not handling of the linkComponent is passed through
to the
@@ -683,6 +684,7 @@
// process the request target
target.respond(requestCycle);
+ requestCycle.detach();
}
// if the link is an AjaxSubmitLink, we need to find the form
// from it using reflection so we know what to submit.
@@ -692,7 +694,7 @@
if (isAjax == false)
{
fail("Link " + path + "is an AjaxSubmitLink and
" +
- "will not be invoked when AJAX
(javascript) is disabled.");
+ "will not be invoked when AJAX
(javascript) is disabled.");
}
AjaxSubmitLink link = (AjaxSubmitLink)linkComponent;
@@ -724,6 +726,7 @@
// process the request target
requestCycle.getRequestTarget().respond(requestCycle);
+ requestCycle.detach();
}
// if the link is a normal link (or ResourceLink)
[jira] Updated: (WICKET-1152) MetaDataRoleAuthorizationStrategy.unauthorize() doesn't work
[ https://issues.apache.org/jira/browse/WICKET-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1152: Fix Version/s: 1.3.0-rc2 do you have a unit testcase for this ? > MetaDataRoleAuthorizationStrategy.unauthorize() doesn't work > > > Key: WICKET-1152 > URL: https://issues.apache.org/jira/browse/WICKET-1152 > Project: Wicket > Issue Type: Bug > Components: wicket-auth-roles >Affects Versions: 1.3.0-rc1 >Reporter: David > Fix For: 1.3.0-rc2 > > > Try this: > MetaDataRoleAuthorizationStrategy.unauthorize(this, RENDER, "USER"); > The page will still be rendered for user with USER role. > The following will work fine to prevent rendering by anybody: > MetaDataRoleAuthorizationStrategy.authorize(this, RENDER, ""); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1102) Hello World example should use WicketFilter instead of WicketServlet
[ https://issues.apache.org/jira/browse/WICKET-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1102: Affects Version/s: 1.3.0-rc1 Fix Version/s: 1.3.0-rc2 Assignee: Gwyn Evans gwyn can you take a look at this? > Hello World example should use WicketFilter instead of WicketServlet > > > Key: WICKET-1102 > URL: https://issues.apache.org/jira/browse/WICKET-1102 > Project: Wicket > Issue Type: Improvement > Components: site >Affects Versions: 1.3.0-rc1 >Reporter: Sean Sullivan >Assignee: Gwyn Evans >Priority: Minor > Fix For: 1.3.0-rc2 > > > URL: http://wicket.apache.org/examplehelloworld.html > 1) Wicket's Hello World example should use WicketFilter instead of > WicketServlet > 2) the imports are wrong. Package names should be org.apache.wicket > 3) bad javadoc comment: "WicketServlet class for hello world example" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1153) Validation with AbstractFormValidator doesn't work if there are DateTimeFields
[
https://issues.apache.org/jira/browse/WICKET-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542465
]
Johan Compagner commented on WICKET-1153:
-
do you have a unit test case for this? So that we can see that it fails? (not
being called so the validator itself does fail so in the output should reflect
that)
> Validation with AbstractFormValidator doesn't work if there are DateTimeFields
> --
>
> Key: WICKET-1153
> URL: https://issues.apache.org/jira/browse/WICKET-1153
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
>Affects Versions: 1.3.0-beta4
>Reporter: Roberto Fasciolo
>Assignee: Johan Compagner
> Fix For: 1.3.0-rc2
>
>
> If in dependentFormComponents of a class extending AbstractFormValidator
> there are some DateTimeFields the validator code is never called. Example:
> public final class DateRangeValidator extends AbstractFormValidator {
> private final transient Logger logger =
> Logger.getLogger(this.getClass().getName());
> private final DateTimeField dateFrom;
> private final DateTimeField dateTo;
> public DateRangeValidator(final DateTimeField dateFrom, final
> DateTimeField dateTo) {
> if (dateFrom == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> if (dateTo == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> this.dateFrom = dateFrom;
> this.dateTo = dateTo;
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Validator constructed");
> }
> }
> @Override
> public FormComponent[] getDependentFormComponents() {
> // TODO this should return an array with the 2 objects, but if
> returning that the
> // validator doesn't work at all.
> // return new FormComponent[] { dateFrom, dateTo };
> return null;
> }
> @Override
> public void validate(final Form form) {
> Date from = (Date) this.dateFrom.getConvertedInput();
> Date to = (Date) this.dateTo.getConvertedInput();
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Date from: '" + from + "'");
> this.logger.debug("Date to: '" + to + "'");
> }
> if (from == null || to == null) {
> return;
> }
> if (to.compareTo(from) <= 0) {
> error(this.dateTo);
> }
> }
> }
> If that class returns the FormComponent[] with the 2 DateTimeFields validate
> is never called, if that method returns null validate is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1124) Inner form validators not skipped when inner form disabled
[ https://issues.apache.org/jira/browse/WICKET-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1124: Fix Version/s: 1.3.0-rc2 are we going to fix this for 1.3? It would be nice to have this in an unit test ! Does anybody has one that we can include? > Inner form validators not skipped when inner form disabled > -- > > Key: WICKET-1124 > URL: https://issues.apache.org/jira/browse/WICKET-1124 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 >Reporter: Gwyn Evans >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.3.0-rc2 > > > The specific issue I've just run across is where I have a outer form and, > depending upon a checkbox, might have an inner form being enabled or not. > (It's an inner form, rather than just a part of the main form as it's off as > a component with it's own panel.) > Anyway, the inner form has password/confirmPassword fields and an > EqualInputValidator, but if the form is displayed but then disabled again > (via Ajax, if significant,) when the form's finally submitted I get a > warning, saying "IFormValidator in form '...' depends on a component that has > been removed from the page or is no longer visible. Offending component id > `password`." > As Igor commented, "looks like we need to update form processing code to skip > inner disabled forms". > /Gwyn -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1115) DownloadLink fix that encodes non-ASCII file names properly
[ https://issues.apache.org/jira/browse/WICKET-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1115: Fix Version/s: 1.4.0-alpha Did you patch it already so that also it works fine in IE7? Also can you make a real patch so not the file itself but a svn-patch? Because the download file is already changed so then the merging is much easier. i don't like that we need to include commons-codec just for this. So if you make a patch please copy them from that lib and include them into a wicket package. > DownloadLink fix that encodes non-ASCII file names properly > --- > > Key: WICKET-1115 > URL: https://issues.apache.org/jira/browse/WICKET-1115 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.2.6 > Environment: Internet Explorer 6, Firefox 2.0.0.8 >Reporter: Volodymyr Sobotovich > Fix For: 1.4.0-alpha > > Attachments: DownloadLink.java > > > When a user tries to download a file with its name consisting of non-ASCII > characters browsers don't display the name correctly in download dialog box. > To fix the problem the proper encoding must be applied to the file name. IE > expects URL-encoding to be used and Firefox Q- or Base64. That's why it's > necessary to detect user's browser type and use the appropriate codec. Codecs > were borrowed from commons-codec library. > This fix works IE6 and FF2. When I tested it in IE7 a discovered that a few > starting characters are displayed incorrectly. I mean that IE7 must use some > variation of URL encoding and that's why this patch must be patched more a > little:) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1132) Ajax link is different from normal link on Liferay Portal
[
https://issues.apache.org/jira/browse/WICKET-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1132:
Fix Version/s: 1.3.0-rc2
Assignee: Ate Douma
ate, can you look at this to see if this needs to be fixed before the final of
1.3?
> Ajax link is different from normal link on Liferay Portal
> -
>
> Key: WICKET-1132
> URL: https://issues.apache.org/jira/browse/WICKET-1132
> Project: Wicket
> Issue Type: Bug
> Components: wicket-portlet
>Affects Versions: 1.3.0-beta4
> Environment: Liferay 4.3.3 on Tomcat 6
>Reporter: Thijs Vonk
>Assignee: Ate Douma
> Fix For: 1.3.0-rc2
>
>
> I created 2 simple Links a AjaxLink and a 'normal' link in a portlet. I
> deployed this portlet on Liferay. The normal link works fine. But the Ajax
> links doesn't work. In the generated HTML the url's look like this.
> AJAX link:
> http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet&p_p_action=1&p_p_col_id=column-1&p_p_col_count=1&;',null,null,
> function() {return Wicket.$$(this)}.bind(this));return !wcall;"
> id="id__MiniPortlet__WAR__MiniPortlet1link1">
> Normal link:
> href="http://localhost:8080/web/guest/admin?p_p_id=MiniPortlet_WAR_MiniPortlet1&p_p_action=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_MiniPortlet_WAR_MiniPortlet1__wu=%2Fminiportlet%2F%3Fwicket%3Ainterface%3D%3A0%3Alink2%3A%3AILinkListener%3A%3A";
> wicket:id="link2">
> At this moment the p_p_id is the part that I'm looking into. As you can see
> they are different. And for Liferay this part tels it which portlet it should
> send the request to. The normal link is the correct path to the portlet. as
> this action actually works.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1128) Option not to use localizer cache in development mode.
[ https://issues.apache.org/jira/browse/WICKET-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1128. --- Resolution: Duplicate duplicate of 1142 > Option not to use localizer cache in development mode. > -- > > Key: WICKET-1128 > URL: https://issues.apache.org/jira/browse/WICKET-1128 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: All >Reporter: Sebastiaan van Erk >Assignee: Juergen Donnerstag > Fix For: 1.3.0-rc2 > > > I was wondering if I could somehow turn off caching of the localizer in > development mode (from the current source it doesn't look like it). > The reason I ask is because now the cache is only flushed if a resource that > is being watched is changed. However: > * if you add a new properties file for a page or component after you already > rendered the page once the cache is not cleared and it keeps finding the > key=null entry in the cache. > * if you add your own database string resource loader, the cache is never > flushed at all. > I know I can add a link to flush the localizer cache if and only if we're in > development mode, but I think a Settings options could be nice to just turn > off caching (my laptop is fast enough, I really don't care if it tries to > resolve all the labels all the time). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1098) AjaxEditableLabel: add method to override edit-event
[ https://issues.apache.org/jira/browse/WICKET-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1098: Component/s: (was: wicket-examples) wicket-extensions Fix Version/s: 1.3.0-rc2 Assignee: Johan Compagner can you create a small patch how it would work for you? > AjaxEditableLabel: add method to override edit-event > > > Key: WICKET-1098 > URL: https://issues.apache.org/jira/browse/WICKET-1098 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.3.0-beta4 > Environment: any >Reporter: Jan Kriesten >Assignee: Johan Compagner >Priority: Minor > Fix For: 1.3.0-rc2 > > > Currently, as event 'onclick' is hardcoded in AjaxEditableLabel. To change > this behavior, a bunch of logic has to be copied. It would be nice, if there > was a method > newLabelAjaxBehavior(String event) > which could be easily overriden. > Might apply to other AjaxEdit-Components as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1160) AjaxEditableLabel#setModel() is broken
[
https://issues.apache.org/jira/browse/WICKET-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner closed WICKET-1160.
---
Resolution: Fixed
Fix Version/s: 1.3.0-rc2
Assignee: Johan Compagner
applied
> AjaxEditableLabel#setModel() is broken
> --
>
> Key: WICKET-1160
> URL: https://issues.apache.org/jira/browse/WICKET-1160
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Reporter: Peter Ertl
>Assignee: Johan Compagner
> Fix For: 1.3.0-rc2
>
> Attachments: AjaxEditableLabel.patch
>
>
> The following code
> AjaxEditableLabel label = new AjaxEditableLabel("someid");
> label.setModel(...);
> will throw an NullPointerException.
> The reason is...
> public final Component setModel(IModel model)
> {
> super.setModel(model);
> *** getLabel().setModel(model);
> getEditor().setModel(model);
> return this;
> }
> getLabel() returns null because the label is not initialized.
> I suggest the following fix:
> protected final Component getLabel()
> {
> return label;
> }
> should be changed to
> protected final Component getLabel()
> {
> if (label == null)
> {
> initLabelAndEditor(getParentModel());
> }
> return label;
> }
> this is similar to getEditor() which already initializes the component if it
> is null...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r594865 - /wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
Author: jcompagner
Date: Wed Nov 14 05:10:17 2007
New Revision: 594865
URL: http://svn.apache.org/viewvc?rev=594865&view=rev
Log:
init the label when getLabel is invoked WICKET-1160
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java?rev=594865&r1=594864&r2=594865&view=diff
==
---
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
(original)
+++
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
Wed Nov 14 05:10:17 2007
@@ -335,6 +335,10 @@
*/
protected final Component getLabel()
{
+ if (label == null)
+ {
+ initLabelAndEditor(getParentModel());
+ }
return label;
}
[jira] Closed: (WICKET-1131) AjaxEditableLabel: defaultNullLabel() should really be a defaultNullorEmptyLabel()
[ https://issues.apache.org/jira/browse/WICKET-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1131. --- Resolution: Fixed Fix Version/s: 1.3.0-rc2 Assignee: Johan Compagner added the test for an empty string > AjaxEditableLabel: defaultNullLabel() should really be a > defaultNullorEmptyLabel() > -- > > Key: WICKET-1131 > URL: https://issues.apache.org/jira/browse/WICKET-1131 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.0-beta4 > Environment: any >Reporter: Jan Kriesten >Assignee: Johan Compagner > Fix For: 1.3.0-rc2 > > > defaultNullLabel() only inserts '...' when the model is NULL, not when the > model contains an empty String. > So right now it's impossible to get empty Strings edited with this component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r594863 - /wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
Author: jcompagner
Date: Wed Nov 14 05:06:29 2007
New Revision: 594863
URL: http://svn.apache.org/viewvc?rev=594863&view=rev
Log:
also test for empty string so that those are also editable WICKET-1131
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
Modified:
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java?rev=594863&r1=594862&r2=594863&view=diff
==
---
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
(original)
+++
wicket/trunk/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/AjaxEditableLabel.java
Wed Nov 14 05:06:29 2007
@@ -298,7 +298,8 @@
protected void onComponentTagBody(MarkupStream
markupStream, ComponentTag openTag)
{
- if (getModelObject() == null)
+ Object modelObject = getModelObject();
+ if (modelObject == null ||
"".equals(modelObject))
{
replaceComponentTagBody(markupStream,
openTag, defaultNullLabel());
}
[jira] Closed: (WICKET-1145) Patch for allowing to be serialized
[ https://issues.apache.org/jira/browse/WICKET-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1145. --- Resolution: Fixed Fix Version/s: 1.3.0-rc2 1.2.7 Assignee: Johan Compagner applied on both > Patch for allowing to be serialized > --- > > Key: WICKET-1145 > URL: https://issues.apache.org/jira/browse/WICKET-1145 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eirik Bjorsnos >Assignee: Johan Compagner > Fix For: 1.2.7, 1.3.0-rc2 > > Attachments: WICKET-1145-searchfield-patch.txt > > > Input field serialization in wicket-ajax.js does not serialize input fields > with type="search" properly. > type=search is supported on Safari and renders like text fields on other > browsers, so it would be cool if Wicket did the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r594862 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
Author: jcompagner
Date: Wed Nov 14 05:02:09 2007
New Revision: 594862
URL: http://svn.apache.org/viewvc?rev=594862&view=rev
Log:
search input field support (safari) WICKET-1145
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js?rev=594862&r1=594861&r2=594862&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/ajax/wicket-ajax.js
Wed Nov 14 05:02:09 2007
@@ -371,7 +371,7 @@
var type = input.type.toLowerCase();
if ((type == "checkbox" || type == "radio") && input.checked) {
return Wicket.Form.encode(input.name) + "=" +
Wicket.Form.encode(input.value) + "&";
-} else if (type == "text" || type == "password" || type == "hidden" ||
type == "textarea") {
+} else if (type == "text" || type == "password" || type == "hidden" ||
type == "textarea" || type == "search") {
return Wicket.Form.encode(input.name) + "=" +
Wicket.Form.encode(input.value) + "&";
} else {
return "";
svn commit: r594861 - /wicket/branches/wicket-1.2.x/wicket/src/main/java/wicket/ajax/wicket-ajax.js
Author: jcompagner
Date: Wed Nov 14 05:02:05 2007
New Revision: 594861
URL: http://svn.apache.org/viewvc?rev=594861&view=rev
Log:
search input field support (safari) WICKET-1145
Modified:
wicket/branches/wicket-1.2.x/wicket/src/main/java/wicket/ajax/wicket-ajax.js
Modified:
wicket/branches/wicket-1.2.x/wicket/src/main/java/wicket/ajax/wicket-ajax.js
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.2.x/wicket/src/main/java/wicket/ajax/wicket-ajax.js?rev=594861&r1=594860&r2=594861&view=diff
==
---
wicket/branches/wicket-1.2.x/wicket/src/main/java/wicket/ajax/wicket-ajax.js
(original)
+++
wicket/branches/wicket-1.2.x/wicket/src/main/java/wicket/ajax/wicket-ajax.js
Wed Nov 14 05:02:05 2007
@@ -273,7 +273,7 @@
var type = input.type.toLowerCase();
if ((type == "checkbox" || type == "radio") && input.checked) {
return Wicket.Form.encode(input.name) + "=" +
Wicket.Form.encode(input.value) + "&";
-} else if (type == "text" || type == "password" || type == "hidden" ||
type == "textarea") {
+} else if (type == "text" || type == "password" || type == "hidden" ||
type == "textarea" || type == "search") {
return Wicket.Form.encode(input.name) + "=" +
Wicket.Form.encode(input.value) + "&";
} else {
return "";
[jira] Updated: (WICKET-1140) Adding WebPage.html after viewing it once requires restart of servlet container for updates in developer mode.
[ https://issues.apache.org/jira/browse/WICKET-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1140: Fix Version/s: 1.4.0-alpha moving this to 1.4, its to hard to do it for 1.3 at this time and it seems thats api changes then has to happen. So for now you have to restart the container or redeploy. > Adding WebPage.html after viewing it once requires restart of servlet > container for updates in developer mode. > -- > > Key: WICKET-1140 > URL: https://issues.apache.org/jira/browse/WICKET-1140 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 >Reporter: Sebastiaan van Erk >Priority: Minor > Fix For: 1.4.0-alpha > > > If you create a WebPage.java (which extends some base page) and view it in > the browser, and afterwards add WebPage.html and update the browser (in > development mode), the page will not be updated. The only way to get Wicket > to see the new WebPage.html file seems to be to restart the servlet > container. It would be nice if Wicket saw the newly added html file and > updated the page accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1141) empty shorthand does not work
[ https://issues.apache.org/jira/browse/WICKET-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1141. --- Resolution: Fixed Assignee: Johan Compagner > empty shorthand does not work > --- > > Key: WICKET-1141 > URL: https://issues.apache.org/jira/browse/WICKET-1141 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta4 >Reporter: Sebastiaan van Erk >Assignee: Johan Compagner >Priority: Minor > Attachments: patch.txt > > > When making an empty fragment like so: > > It does not work, and all the html which follows the fragment until the end > of the file is put into the fragment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1153) Validation with AbstractFormValidator doesn't work if there are DateTimeFields
[
https://issues.apache.org/jira/browse/WICKET-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542445
]
Roberto Fasciolo commented on WICKET-1153:
--
yes, they are valid and visible (and also checked with a required validator)
> Validation with AbstractFormValidator doesn't work if there are DateTimeFields
> --
>
> Key: WICKET-1153
> URL: https://issues.apache.org/jira/browse/WICKET-1153
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
>Affects Versions: 1.3.0-beta4
>Reporter: Roberto Fasciolo
>Assignee: Johan Compagner
> Fix For: 1.3.0-rc2
>
>
> If in dependentFormComponents of a class extending AbstractFormValidator
> there are some DateTimeFields the validator code is never called. Example:
> public final class DateRangeValidator extends AbstractFormValidator {
> private final transient Logger logger =
> Logger.getLogger(this.getClass().getName());
> private final DateTimeField dateFrom;
> private final DateTimeField dateTo;
> public DateRangeValidator(final DateTimeField dateFrom, final
> DateTimeField dateTo) {
> if (dateFrom == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> if (dateTo == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> this.dateFrom = dateFrom;
> this.dateTo = dateTo;
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Validator constructed");
> }
> }
> @Override
> public FormComponent[] getDependentFormComponents() {
> // TODO this should return an array with the 2 objects, but if
> returning that the
> // validator doesn't work at all.
> // return new FormComponent[] { dateFrom, dateTo };
> return null;
> }
> @Override
> public void validate(final Form form) {
> Date from = (Date) this.dateFrom.getConvertedInput();
> Date to = (Date) this.dateTo.getConvertedInput();
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Date from: '" + from + "'");
> this.logger.debug("Date to: '" + to + "'");
> }
> if (from == null || to == null) {
> return;
> }
> if (to.compareTo(from) <= 0) {
> error(this.dateTo);
> }
> }
> }
> If that class returns the FormComponent[] with the 2 DateTimeFields validate
> is never called, if that method returns null validate is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r594860 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
Author: jcompagner
Date: Wed Nov 14 04:53:44 2007
New Revision: 594860
URL: http://svn.apache.org/viewvc?rev=594860&view=rev
Log:
empty shorthand does not work WICKET-1141
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java?rev=594860&r1=594859&r2=594860&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/panel/Fragment.java
Wed Nov 14 04:53:44 2007
@@ -127,7 +127,7 @@
*The model for this fragment
*/
public Fragment(final String id, final String markupId, final
MarkupContainer markupProvider,
- final IModel model)
+ final IModel model)
{
super(id, model);
@@ -199,8 +199,8 @@
if (providerMarkupStream == null)
{
throw new MarkupNotFoundException(
- "Fragment: No markup stream found for
providing markup container " +
-
markupProvider.toString() + ". Fragment: " + toString());
+ "Fragment: No markup stream found for providing
markup container " +
+ markupProvider.toString() + ".
Fragment: " + toString());
}
renderFragment(providerMarkupStream, openTag);
@@ -254,9 +254,9 @@
if (index == -1)
{
throw new MarkupException("Markup of component class `"
+
-
providerMarkupStream.getContainerClass().getName() +
- "` does not contain a fragment with
wicket:id `" + markupId + "`. Context: " +
- toString());
+
providerMarkupStream.getContainerClass().getName() +
+ "` does not contain a fragment with wicket:id
`" + markupId + "`. Context: " +
+ toString());
}
// Set the markup stream position to where the fragment begins
@@ -267,12 +267,16 @@
// Get the fragments open tag
ComponentTag fragmentOpenTag =
providerMarkupStream.getTag();
- // We'll completely ignore the fragments open tag.
It'll not be
- // rendered
- providerMarkupStream.next();
+ // if it is an open close tag, skip this fragment.
+ if (!fragmentOpenTag.isOpenClose())
+ {
+ // We'll completely ignore the fragments open
tag. It'll not be
+ // rendered
+ providerMarkupStream.next();
- // Render the body of the fragment
- super.onComponentTagBody(providerMarkupStream,
fragmentOpenTag);
+ // Render the body of the fragment
+ super.onComponentTagBody(providerMarkupStream,
fragmentOpenTag);
+ }
}
finally
{
@@ -286,7 +290,7 @@
* Position the markup stream at the child component relative to the
provider markup
*
* @param path
-* @return
+* @return The markup stream for the given component.
*/
public MarkupStream findComponentIndex(final String path)
{
@@ -295,9 +299,9 @@
if (index == -1)
{
throw new MarkupException("Markup of component class `"
+
-
markupStream.getContainerClass().getName() +
- "` does not contain a fragment with
wicket:id `" + markupId + "`. Context: " +
- toString());
+ markupStream.getContainerClass().getName() +
+ "` does not contain a fragment with wicket:id
`" + markupId + "`. Context: " +
+ toString());
}
markupStream.setCurrentIndex(index);
return markupStream;
[jira] Updated: (WICKET-1085) Input Text Mask
[
https://issues.apache.org/jira/browse/WICKET-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1085:
Affects Version/s: 1.3.0-rc1
Fix Version/s: 1.3.0-rc2
frank, i am setting this now to 1.3 but move it to 1.4 if you can't get it
right very soon.
> Input Text Mask
> ---
>
> Key: WICKET-1085
> URL: https://issues.apache.org/jira/browse/WICKET-1085
> Project: Wicket
> Issue Type: New Feature
> Components: wicket-extensions
>Affects Versions: 1.3.0-rc1
>Reporter: Will Hoover
>Assignee: Frank Bille Jensen
>Priority: Trivial
> Fix For: 1.3.0-rc2
>
> Attachments: inputTextMask.js
>
>
> Allow developers to designate a keystroke input pattern for the input text
> component. The pattern would be used on the client to control valid
> keystrokes for the current cursor position within the input text field in
> relation to the specified pattern.
> For example, a pattern could be designated as "(999)-" causing only
> number values in each position where a "9" appears and using the "(", ")",
> and "-" as masking characters. When the cursor position reached one of these
> mask characters the cursor position would advance to the next "9" position.
> The resulting mask would appear as "(___)___-" within the input text
> value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1137) Back button and lazyLoadPanel
[ https://issues.apache.org/jira/browse/WICKET-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1137: Fix Version/s: 1.3.0-rc2 Assignee: Johan Compagner a bit more feedback is welcome! > Back button and lazyLoadPanel > - > > Key: WICKET-1137 > URL: https://issues.apache.org/jira/browse/WICKET-1137 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.0-beta4 > Environment: windows/jdk6/ >Reporter: Marc Godin >Assignee: Johan Compagner >Priority: Minor > Fix For: 1.3.0-rc2 > > > using the navigator back button with a lazyLoad panel in form generate an > internal Error > tried to use meta cache-control no-store(as discussed in the forum) dont do > the job :( > the problem happens only when the lazyloadpanel in in a form with a date > Text field > Error trace(on page an trace) > java.lang.IllegalStateException: No behavior listener found with behaviorId > 0; Component: [MarkupContainer [Component id = content, page = > com.essec.espacerecruteur.wicket.web.extraction.ExtractionPage, path = > 2:extractionForm:brochures:content.SelectedListPanel, isVisible = true, > isVersioned = true]] > at > org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:95) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1091) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1166) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1245) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:489) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:319) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:169) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > 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:712) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:281) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) > regards Marc(thks for this great framework !) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1134) Multiple abstract/implement tags instead of child/extend
[ https://issues.apache.org/jira/browse/WICKET-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1134: Affects Version/s: 1.3.0-rc1 Fix Version/s: 1.4.0-alpha move this to 1.4. Then we can look at it if we can put this into the core ( and ) so that everything is backwards compatible has my preference. > Multiple abstract/implement tags instead of child/extend > > > Key: WICKET-1134 > URL: https://issues.apache.org/jira/browse/WICKET-1134 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-rc1 >Reporter: Stefan Fußenegger >Priority: Minor > Fix For: 1.4.0-alpha > > Attachments: wicket-abstract-implement.patch > > > The current implementation of wicket:child and wicket:extend only allows for > a single extension per subpage. However, this restriction is neither mandated > by java class hierarchy nor by any other reason. Therefore, it should be > possible to extend the current implementation to support multiple 'abstract' > sections, just like abstract methods in java classes. This could be done by > replacing > > > some content > > > with > > > some content > > > (new names have been suggested in > http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html) > A possible application is a layout with two columns, e.g. a header with > navigation, a left column with sub-navigation and a right column with content > (where the sub-navigation may change depending on the section. In deed, this > is already possible using panels or similar means. However, it would allow to > take advantage of markup inheritance only: > BasePage extens WebPage: > [left navigation goes > here] > [content goes here] > SectionPage extends BasePage: > [sub navigation links > here] > FooPage extends SectionPage: > [content goes here] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1130) Injection of Bound Instance Fails with Exception
[
https://issues.apache.org/jira/browse/WICKET-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1130:
Fix Version/s: 1.3.0-rc2
Assignee: Alastair Maw
> Injection of Bound Instance Fails with Exception
>
>
> Key: WICKET-1130
> URL: https://issues.apache.org/jira/browse/WICKET-1130
> Project: Wicket
> Issue Type: Bug
> Components: wicket-guice
>Affects Versions: 1.3.0-beta4
>Reporter: Daniel Spiewak
>Assignee: Alastair Maw
> Fix For: 1.3.0-rc2
>
>
> If I try to inject an explicitly bound instance into a component, injection
> fails with an exception in the creation of the CGLIB proxy:
> java.lang.IllegalArgumentException: Superclass has no null constructors but
> no arguments were given
> Stupidly, I forgot to save the whole stack trace and the code is now gone
> from my codebase (since I needed it to work). To repeat:
> @Override
> public void configure() {
> bind(EntityManager.class).toInstance(manager);
> }
> Seems wicket-guice is assuming that it needs to create a new instance of
> everything that's injected, and since EntityManager doesn't have a no-args
> constructor, such an action fails. Just an assumption 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-1153) Validation with AbstractFormValidator doesn't work if there are DateTimeFields
[
https://issues.apache.org/jira/browse/WICKET-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542438
]
Johan Compagner commented on WICKET-1153:
-
but are those 2 date formcomponents valid and visible?
If there aren't then yes the validate isn't called. Because for the validator
to do its job it first checks if the dependend components are visible and
valid.
So is that somehow not the case?
> Validation with AbstractFormValidator doesn't work if there are DateTimeFields
> --
>
> Key: WICKET-1153
> URL: https://issues.apache.org/jira/browse/WICKET-1153
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
>Affects Versions: 1.3.0-beta4
>Reporter: Roberto Fasciolo
> Fix For: 1.3.0-rc2
>
>
> If in dependentFormComponents of a class extending AbstractFormValidator
> there are some DateTimeFields the validator code is never called. Example:
> public final class DateRangeValidator extends AbstractFormValidator {
> private final transient Logger logger =
> Logger.getLogger(this.getClass().getName());
> private final DateTimeField dateFrom;
> private final DateTimeField dateTo;
> public DateRangeValidator(final DateTimeField dateFrom, final
> DateTimeField dateTo) {
> if (dateFrom == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> if (dateTo == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> this.dateFrom = dateFrom;
> this.dateTo = dateTo;
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Validator constructed");
> }
> }
> @Override
> public FormComponent[] getDependentFormComponents() {
> // TODO this should return an array with the 2 objects, but if
> returning that the
> // validator doesn't work at all.
> // return new FormComponent[] { dateFrom, dateTo };
> return null;
> }
> @Override
> public void validate(final Form form) {
> Date from = (Date) this.dateFrom.getConvertedInput();
> Date to = (Date) this.dateTo.getConvertedInput();
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Date from: '" + from + "'");
> this.logger.debug("Date to: '" + to + "'");
> }
> if (from == null || to == null) {
> return;
> }
> if (to.compareTo(from) <= 0) {
> error(this.dateTo);
> }
> }
> }
> If that class returns the FormComponent[] with the 2 DateTimeFields validate
> is never called, if that method returns null validate is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1153) Validation with AbstractFormValidator doesn't work if there are DateTimeFields
[
https://issues.apache.org/jira/browse/WICKET-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1153:
Fix Version/s: 1.3.0-rc2
Assignee: Johan Compagner
> Validation with AbstractFormValidator doesn't work if there are DateTimeFields
> --
>
> Key: WICKET-1153
> URL: https://issues.apache.org/jira/browse/WICKET-1153
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
>Affects Versions: 1.3.0-beta4
>Reporter: Roberto Fasciolo
>Assignee: Johan Compagner
> Fix For: 1.3.0-rc2
>
>
> If in dependentFormComponents of a class extending AbstractFormValidator
> there are some DateTimeFields the validator code is never called. Example:
> public final class DateRangeValidator extends AbstractFormValidator {
> private final transient Logger logger =
> Logger.getLogger(this.getClass().getName());
> private final DateTimeField dateFrom;
> private final DateTimeField dateTo;
> public DateRangeValidator(final DateTimeField dateFrom, final
> DateTimeField dateTo) {
> if (dateFrom == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> if (dateTo == null) {
> throw new NullPointerException("From date field cannot be null");
> }
> this.dateFrom = dateFrom;
> this.dateTo = dateTo;
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Validator constructed");
> }
> }
> @Override
> public FormComponent[] getDependentFormComponents() {
> // TODO this should return an array with the 2 objects, but if
> returning that the
> // validator doesn't work at all.
> // return new FormComponent[] { dateFrom, dateTo };
> return null;
> }
> @Override
> public void validate(final Form form) {
> Date from = (Date) this.dateFrom.getConvertedInput();
> Date to = (Date) this.dateTo.getConvertedInput();
> if (this.logger.isDebugEnabled()) {
> this.logger.debug("Date from: '" + from + "'");
> this.logger.debug("Date to: '" + to + "'");
> }
> if (from == null || to == null) {
> return;
> }
> if (to.compareTo(from) <= 0) {
> error(this.dateTo);
> }
> }
> }
> If that class returns the FormComponent[] with the 2 DateTimeFields validate
> is never called, if that method returns null validate is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1160) AjaxEditableLabel#setModel() is broken
[
https://issues.apache.org/jira/browse/WICKET-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-1160:
---
Attachment: AjaxEditableLabel.patch
Here's a patch
> AjaxEditableLabel#setModel() is broken
> --
>
> Key: WICKET-1160
> URL: https://issues.apache.org/jira/browse/WICKET-1160
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Reporter: Peter Ertl
> Attachments: AjaxEditableLabel.patch
>
>
> The following code
> AjaxEditableLabel label = new AjaxEditableLabel("someid");
> label.setModel(...);
> will throw an NullPointerException.
> The reason is...
> public final Component setModel(IModel model)
> {
> super.setModel(model);
> *** getLabel().setModel(model);
> getEditor().setModel(model);
> return this;
> }
> getLabel() returns null because the label is not initialized.
> I suggest the following fix:
> protected final Component getLabel()
> {
> return label;
> }
> should be changed to
> protected final Component getLabel()
> {
> if (label == null)
> {
> initLabelAndEditor(getParentModel());
> }
> return label;
> }
> this is similar to getEditor() which already initializes the component if it
> is null...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1160) AjaxEditableLabel#setModel() is broken
AjaxEditableLabel#setModel() is broken
--
Key: WICKET-1160
URL: https://issues.apache.org/jira/browse/WICKET-1160
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Reporter: Peter Ertl
The following code
AjaxEditableLabel label = new AjaxEditableLabel("someid");
label.setModel(...);
will throw an NullPointerException.
The reason is...
public final Component setModel(IModel model)
{
super.setModel(model);
*** getLabel().setModel(model);
getEditor().setModel(model);
return this;
}
getLabel() returns null because the label is not initialized.
I suggest the following fix:
protected final Component getLabel()
{
return label;
}
should be changed to
protected final Component getLabel()
{
if (label == null)
{
initLabelAndEditor(getParentModel());
}
return label;
}
this is similar to getEditor() which already initializes the component if it is
null...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1142) Have check isRenderAllowed() to make it work in combination with authorization
[ https://issues.apache.org/jira/browse/WICKET-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1142. --- Resolution: Fixed Fix Version/s: 1.3.0-rc2 Assignee: Igor Vaynberg closing > Have check isRenderAllowed() to make it work in > combination with authorization > - > > Key: WICKET-1142 > URL: https://issues.apache.org/jira/browse/WICKET-1142 > Project: Wicket > Issue Type: Improvement >Reporter: Sebastiaan van Erk >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.3.0-rc2 > > > Currently does not work when a child is not visible due to > it not being allowed to render. It would be nice if this worked. > This was discussed in the following thread on the user list: > http://www.nabble.com/wicket:enclosure-and-authorization-t4727625i20.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1138) Better warning of design errors during development
[
https://issues.apache.org/jira/browse/WICKET-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner updated WICKET-1138:
Fix Version/s: 1.3.0-rc2
Assignee: Eelco Hillenius
we already log it:
final void add(FeedbackMessage message)
{
if (log.isDebugEnabled())
{
log.debug("Adding feedback message " + message);
}
messages.add(message);
}
so if you enable debug logging then you would see a message added to the list.
assigning to eelco so he could see if we close this issue.
> Better warning of design errors during development
> --
>
> Key: WICKET-1138
> URL: https://issues.apache.org/jira/browse/WICKET-1138
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.3.0-beta4
>Reporter: Brill Pappin
>Assignee: Eelco Hillenius
> Fix For: 1.3.0-rc2
>
>
> As suggested in this list post:
> http://www.nabble.com/Form%3A-onSubmit-not-called-tf4763217.html#a13659761
> > Although it was my own fault hands down (silly me didn't write a test first)
> > I'm thinking that I could have saved hours with some sort of indication...
> > now that its happened once the lesson is pretty clear, but a lot of people
> > are going to stumble over stuff like that when they first get into Wicket.
> Yeah. If you can open up a JIRA issue for it, we can think/ discuss
> what we could do here.
> Eelco
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1157) Generic internationalization for Enums
[ https://issues.apache.org/jira/browse/WICKET-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1157: Fix Version/s: 1.4.0-alpha > Generic internationalization for Enums > -- > > Key: WICKET-1157 > URL: https://issues.apache.org/jira/browse/WICKET-1157 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.4.0-alpha >Reporter: Bruno Borges > Fix For: 1.4.0-alpha > > Attachments: EnumDropDownChoice.java, EnumLabel.java > > > Support internationalization for Enums for any Component in the future > (Wicket's Java 5+ version). I attached two components that does this > independently. But maybe it would be a good idea to abstract this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Websphere (comment added)
Comment Added : WICKET : Re: Websphere Websphere commented on by Joshua Partogi (Nov 14, 2007). Comment: An updated site regarding this is located here: http://joshuajava.wordpress.com/2007/11/14/setting-up-spring-wicket-on-websphere-5/ 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-1128) Option not to use localizer cache in development mode.
[ https://issues.apache.org/jira/browse/WICKET-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542402 ] Sebastiaan van Erk commented on WICKET-1128: Well, the caching is fixed, but that was not really the issue anymore (or the reason why it was reopened). The reason it was reopened is because once the property file resource is found, it is cached, and only THAT resource is cached. If the locator changes its mind about the stream it should be using, then the new stream is never loaded. (See also the linked issue 1142). Thus adding a new propertyfile MyPage_en.properties will not see the changes if a BasePage.properties existed and was already loaded when viewing MyPage. However, since what remains is pretty much an exact duplicate of 1142 but then for property files instead of markup files, and the solution is probably exactly the same as well, so I think its probably best to close this one and just keep 1142. Only other difference between the two bugs is their severity (minor vs major). It seems kind of minor (it's a devel mode only thing, and just saves some restarts), but especially with the localization it feels kind of buggy the way it is now. Regards, Sebastiaan > Option not to use localizer cache in development mode. > -- > > Key: WICKET-1128 > URL: https://issues.apache.org/jira/browse/WICKET-1128 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: All >Reporter: Sebastiaan van Erk >Assignee: Juergen Donnerstag > Fix For: 1.3.0-rc2 > > > I was wondering if I could somehow turn off caching of the localizer in > development mode (from the current source it doesn't look like it). > The reason I ask is because now the cache is only flushed if a resource that > is being watched is changed. However: > * if you add a new properties file for a page or component after you already > rendered the page once the cache is not cleared and it keeps finding the > key=null entry in the cache. > * if you add your own database string resource loader, the cache is never > flushed at all. > I know I can add a link to flush the localizer cache if and only if we're in > development mode, but I think a Settings options could be nice to just turn > off caching (my laptop is fast enough, I really don't care if it tries to > resolve all the labels all the time). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1128) Option not to use localizer cache in development mode.
[ https://issues.apache.org/jira/browse/WICKET-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1128: Fix Version/s: 1.3.0-rc2 i guess this one is fixed now enough right? we don't do it for you (we still could do that as a standard setting but i don't care to much, it must be document right) people can just call the localizers public final void setEnableCache(boolean value) now and the caching is disabled > Option not to use localizer cache in development mode. > -- > > Key: WICKET-1128 > URL: https://issues.apache.org/jira/browse/WICKET-1128 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta4 > Environment: All >Reporter: Sebastiaan van Erk >Assignee: Juergen Donnerstag > Fix For: 1.3.0-rc2 > > > I was wondering if I could somehow turn off caching of the localizer in > development mode (from the current source it doesn't look like it). > The reason I ask is because now the cache is only flushed if a resource that > is being watched is changed. However: > * if you add a new properties file for a page or component after you already > rendered the page once the cache is not cleared and it keeps finding the > key=null entry in the cache. > * if you add your own database string resource loader, the cache is never > flushed at all. > I know I can add a link to flush the localizer cache if and only if we're in > development mode, but I think a Settings options could be nice to just turn > off caching (my laptop is fast enough, I really don't care if it tries to > resolve all the labels all the time). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1120) Problem closing a ModalWindow when used through an IFrame
[ https://issues.apache.org/jira/browse/WICKET-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-1120: Component/s: (was: wicket-extensions) wicket Affects Version/s: 1.3.0-rc1 Fix Version/s: 1.3.0-rc2 Assignee: Matej Knopp matej, must this be fixed for 1.3? > Problem closing a ModalWindow when used through an IFrame > - > > Key: WICKET-1120 > URL: https://issues.apache.org/jira/browse/WICKET-1120 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-rc1 >Reporter: Deepak Mahavishnu >Assignee: Matej Knopp >Priority: Blocker > Fix For: 1.3.0-rc2 > > > I'm doing some POC testing to find out how a wicket application could be used > through an IFrame and noticed that closing of a ModalWindow fails. > My setup: > Application A: > -a dummy html page that has an IFrame > -the contents of the IFrame is requested from Application B > http://localhost:8080/mywicketapp/app/"; width="100%" > height="500"> > Application B: > -a Wicket application that uses a ModalWindow > -deployed to tomcat: http://localhost:8080/mywicketapp/ > Problem: > The ModalWindow is not closed when OK ( or Cancel ) button is clicked when > Application B is used throug IFrame of Application A. > OK button performs the actual action (in my case deletes an item from a list) > but is not closed after the execution of the action. > Closing of the ModalWindow works normally when Application B is not used > through an IFrame. > Reproducing the problem: > You can test this by creating a html page with this source: > > > src="http://www.wicket-library.com/wicket-examples/ajax/modal-window.1"; > width="100%" height="100%"> > > > And then open "Show modal dialog with panel" and try to close the dialog. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-982) Add accessibility support
[ https://issues.apache.org/jira/browse/WICKET-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner updated WICKET-982: --- Fix Version/s: (was: 1.3.0-rc2) 1.4.0-alpha this won't make it for 1.3, if somebody have patches for this, thats more then welcome! > Add accessibility support > - > > Key: WICKET-982 > URL: https://issues.apache.org/jira/browse/WICKET-982 > Project: Wicket > Issue Type: New Feature > Components: wicket >Reporter: James Renfro > Fix For: 1.4.0-alpha > > > It would be helpful to have support in Wicket specifically for programmers > looking to develop applications that are accessible to people with > disabilities. This ticket is to provide a base from which to gather specs for > that effort. > Here are some relevant links: > http://www.w3.org/TR/aria-role/ > http://www.smartlabsoftware.com/wai-validator.htm > http://www.w3.org/WAI/wcag-curric/sam119-0.htm > http://www.w3.org/WAI/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1159) IWrapModel implementations should implement detach method (calling the wrapped model), Also AbstractWrapModel shouldn't have an empty detach method (because it has to be i
[ https://issues.apache.org/jira/browse/WICKET-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1159. --- Resolution: Fixed fixed. If developers did extend the AbstractWrapModel then they could get compile errors now because the detach() has to be implemented. > IWrapModel implementations should implement detach method (calling the > wrapped model), Also AbstractWrapModel shouldn't have an empty detach method > (because it has to be implemented) > -- > > Key: WICKET-1159 > URL: https://issues.apache.org/jira/browse/WICKET-1159 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 >Reporter: Johan Compagner > Fix For: 1.3.0-rc2 > > > see subject -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r594820 - in /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model: AbstractWrapModel.java ComponentPropertyModel.java ResourceModel.java
Author: jcompagner
Date: Wed Nov 14 02:11:51 2007
New Revision: 594820
URL: http://svn.apache.org/viewvc?rev=594820&view=rev
Log:
detach of the IWrapModel should be implemented, see WICKET-1159
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/AbstractWrapModel.java
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ComponentPropertyModel.java
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ResourceModel.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/AbstractWrapModel.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/AbstractWrapModel.java?rev=594820&r1=594819&r2=594820&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/AbstractWrapModel.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/AbstractWrapModel.java
Wed Nov 14 02:11:51 2007
@@ -44,12 +44,4 @@
public void setObject(Object object)
{
}
-
- /**
-* @see org.apache.wicket.model.IDetachable#detach()
-*/
- public void detach()
- {
- }
-
}
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ComponentPropertyModel.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ComponentPropertyModel.java?rev=594820&r1=594819&r2=594820&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ComponentPropertyModel.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ComponentPropertyModel.java
Wed Nov 14 02:11:51 2007
@@ -26,8 +26,8 @@
* @author Jonathan Locke
*/
public class ComponentPropertyModel extends AbstractReadOnlyModel
- implements
- IComponentAssignedModel
+ implements
+ IComponentAssignedModel
{
private static final long serialVersionUID = 1L;
@@ -94,7 +94,14 @@
public Object getObject()
{
return PropertyResolver.getValue(propertyName,
component.getParent()
- .getInnermostModel().getObject());
+ .getInnermostModel()
+ .getObject());
+ }
+
+ public void detach()
+ {
+ super.detach();
+ ComponentPropertyModel.this.detach();
}
}
}
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ResourceModel.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ResourceModel.java?rev=594820&r1=594819&r2=594820&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ResourceModel.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/model/ResourceModel.java
Wed Nov 14 02:11:51 2007
@@ -71,7 +71,7 @@
{
// this shouldn't be called always wrapped!
return
Application.get().getResourceSettings().getLocalizer().getString(resourceKey,
- (Component)null, defaultValue);
+ (Component)null, defaultValue);
}
@@ -119,7 +119,14 @@
public Object getObject()
{
return
Application.get().getResourceSettings().getLocalizer().getString(resourceKey,
- component, defaultValue);
+ component, defaultValue);
}
+
+ public void detach()
+ {
+ super.detach();
+ ResourceModel.this.detach();
+ }
+
}
}
[jira] Created: (WICKET-1159) IWrapModel implementations should implement detach method (calling the wrapped model), Also AbstractWrapModel shouldn't have an empty detach method (because it has to be
IWrapModel implementations should implement detach method (calling the wrapped model), Also AbstractWrapModel shouldn't have an empty detach method (because it has to be implemented) -- Key: WICKET-1159 URL: https://issues.apache.org/jira/browse/WICKET-1159 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-rc1 Reporter: Johan Compagner Fix For: 1.3.0-rc2 see subject -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
