[jira] Closed: (WICKET-1096) Wicket Javadoc Standardization: org.apache.wicket.util.template, .string.interpolator
[ https://issues.apache.org/jira/browse/WICKET-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Compagner closed WICKET-1096. --- Resolution: Fixed Fix Version/s: 1.3.0-beta5 Assignee: Johan Compagner applied Wicket Javadoc Standardization: org.apache.wicket.util.template, .string.interpolator - Key: WICKET-1096 URL: https://issues.apache.org/jira/browse/WICKET-1096 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta5 Reporter: Nathan Beach Assignee: Johan Compagner Priority: Minor Fix For: 1.3.0-beta5 Attachments: WICKET-1096.patch Javadoc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1090) clean up raw_input after rendering of form components
[
https://issues.apache.org/jira/browse/WICKET-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537283
]
David Shepherdson commented on WICKET-1090:
---
We're currently working around this issue in our system by calling clearInput()
on the form component after setting a new value in its model. It seems to
work...
Is there anything else we should be doing, or is calling clearInput() enough?
clean up raw_input after rendering of form components
-
Key: WICKET-1090
URL: https://issues.apache.org/jira/browse/WICKET-1090
Project: Wicket
Issue Type: Bug
Affects Versions: 1.3.0-beta1, 1.3.0-beta2, 1.3.0-beta3, 1.3.0-beta4
Reporter: Eelco Hillenius
Assignee: Eelco Hillenius
Fix For: 1.3.0-beta5
This code doesn't work like it should:
super(createUserForm, new CompoundPropertyModel(bean));
final TextField passwordField = new TextField(password);
passwordField.setOutputMarkupId(true);
passwordField.setLabel(new ResourceModel(label.createuser.password));
add(passwordField);
add(new AjaxLink(generatePasswordLink) {
@Override
public void onClick(AjaxRequestTarget target) {
bean.setPassword(PasswordGenerator.generate().toString());
target.addComponent(passwordField);
}
});
It should update the label with the new password, but it doesn't when done
after a form submit since it still has the raw_input value it got from that
last form submit. There is no reason (as far as I know) to hold on to that
value after rendering, so the fix is to clean the raw_input at the end of
requests (i.e. onAfterRender).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1097) AjaxEditableLabel: Model change events not propagated from Editor
AjaxEditableLabel: Model change events not propagated from Editor
-
Key: WICKET-1097
URL: https://issues.apache.org/jira/browse/WICKET-1097
Project: Wicket
Issue Type: Improvement
Components: wicket-extensions
Affects Versions: 1.3.0-beta4
Environment: any
Reporter: Jan Kriesten
Model changes are not propagated from the Editor to the AjaxEditableLabel, so
overriding onModelChanging/onModelChanged doesn't work as one might expect. The
implementation should be changed to something like this (code sample by Gerolf):
---
protected FormComponent newEditor(MarkupContainer parent, String componentId,
IModel model)
{
TextField editor = new TextField(componentId, model)
{
private static final long serialVersionUID = 1L;
protected void onModelChanging()
{
super.onModelChanging();
AjaxEditableLabel.this.onModelChanging();
}
protected void onModelChanged()
{
super.onModelChanged();
AjaxEditableLabel.this.onModelChanged();
}
};
editor.setOutputMarkupId(true);
editor.setVisible(false);
editor.add(new EditorAjaxBehavior());
return editor;
}
---
The same issue might apply to the other inline-editors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1095) invisible TransparentResolver skips markup of visible children and thus resulting in an exception in Page#checkRendering (component not found in markup)
[
https://issues.apache.org/jira/browse/WICKET-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerolf Seitz updated WICKET-1095:
-
Attachment: WICKET-1095.zip
attached a simpler scenario
invisible TransparentResolver skips markup of visible children and thus
resulting in an exception in Page#checkRendering (component not found in
markup)
Key: WICKET-1095
URL: https://issues.apache.org/jira/browse/WICKET-1095
Project: Wicket
Issue Type: Bug
Affects Versions: 1.3.0-beta4
Reporter: Gerolf Seitz
Fix For: 1.3.0-beta5
Attachments: WICKET-1095.zip
the code involved can be found at http://papernapkin.org/pastebin/view/13287
if a transparent (= isTransparentResolver() {return true;}) markupContainer
is set to invisible, the component's markup is skipped
(markupStream.skipComponent() in Component.java line 2319).
if the parent containing the transparent markupContainer is added to the ajax
request target and there is a component (in this case a button) inside the
transparent markupcontainer's markup but is actually a child of the
transparent markupcontainer's parent, the button is never actually rendered
(due to skipping the markup of the transparent webmarkupcontainer) but is
still visibleInHierarchy (see Page.java line 1005), because the invisible
transparent markupcontainer is not a parent of the button.
the ultimate question is: what is the desired behavior for an invisible
transparentResolver? render it's children or not?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r588069 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
Author: ate
Date: Wed Oct 24 15:53:52 2007
New Revision: 588069
URL: http://svn.apache.org/viewvc?rev=588069view=rev
Log:
WICKET-1100: Make portlet support configurable and default disabled
See: http://issues.apache.org/jira/browse/WICKET-1100
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java?rev=588069r1=588068r2=588069view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
Wed Oct 24 15:53:52 2007
@@ -21,6 +21,7 @@
import java.io.UnsupportedEncodingException;
import java.text.ParseException;
import java.util.ArrayList;
+import java.util.Properties;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
@@ -99,9 +100,26 @@
* a Portlet context. Value should be true
*/
private final String PORTLET_ONLY_FILTER = portletOnlyFilter;
-
- /* init marker if running in a portlet container context */
- private Boolean portletContextAvailable;
+
+ /**
+* The name of the optional filter parameter indicating a
javax.portlet.PortletContext class should be looked up
+* to determine if portlet support should be provided.
+*/
+ private final String DETECT_PORTLET_CONTEXT = detectPortletContext;
+
+ /**
+* The name of the optional web.xml context parameter indicating if a
portlet context is to be determined
+* by looking up the javax.portlet.PortletContext class. Default value
is false.
+* This context parameter is only queried if the filter parameter
DETECT_PORTLET_CONTEXT isn't provided.
+* If additionally the context parameter is not specified, a
WicketPortlet.properties resource will be looked up
+* through the classpath which, if found, is queried for a property
with the same name.
+*/
+ private final String DETECT_PORTLET_CONTEXT_FULL_NAME =
org.apache.wicket.detectPortletContext;
+
+ /**
+* The classpath resource name of an optional WicketPortlet.properties
file.
+*/
+ private final String WICKET_PORTLET_PROPERTIES =
org/apache/wicket/protocol/http/portlet/WicketPortlet.properties;
/*
* Delegate for handling Portlet specific filtering. Not instantiated
if not running in a
@@ -496,18 +514,9 @@
portletOnlyFilter =
Boolean.valueOf(filterConfig.getInitParameter(PORTLET_ONLY_FILTER))
.booleanValue();
- if (portletContextAvailable == null)
+ if (isPortletContextAvailable(filterConfig))
{
- try
- {
- Class portletClass =
Class.forName(javax.portlet.PortletContext);
- portletContextAvailable = Boolean.TRUE;
- filterPortletContext =
newWicketFilterPortletContext();
- }
- catch (ClassNotFoundException e)
- {
- portletContextAvailable = Boolean.FALSE;
- }
+ filterPortletContext =
newWicketFilterPortletContext();
}
if (filterPortletContext != null)
{
@@ -522,6 +531,56 @@
Thread.currentThread().setContextClassLoader(previousClassLoader);
}
}
+ }
+
+ protected boolean isPortletContextAvailable(FilterConfig config) throws
ServletException
+ {
+ boolean detectPortletContext = false;
+ String parameter =
config.getInitParameter(DETECT_PORTLET_CONTEXT);
+ if (parameter != null)
+ {
+ detectPortletContext =
Boolean.valueOf(parameter).booleanValue();
+ }
+ else
+ {
+ parameter =
config.getServletContext().getInitParameter(DETECT_PORTLET_CONTEXT_FULL_NAME);
+ if (parameter != null)
+ {
+ detectPortletContext =
Boolean.valueOf(parameter).booleanValue();
+ }
+ else
+ {
+ InputStream is =
[jira] Resolved: (WICKET-1100) Make portlet support configurable and default disabled
[ https://issues.apache.org/jira/browse/WICKET-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma resolved WICKET-1100. --- Resolution: Fixed Implemented. For Jetspeed-2 I've also added the org.apache.wicket.detectPortletContext=true property to its WicketPortlet.properties, see: JS2-780 Make portlet support configurable and default disabled -- Key: WICKET-1100 URL: https://issues.apache.org/jira/browse/WICKET-1100 Project: Wicket Issue Type: Improvement Components: wicket-portlet Affects Versions: 1.3.0-beta5 Reporter: Ate Douma Assignee: Ate Douma Priority: Minor Fix For: 1.3.0-beta5 Currently the new portlet support is enabled automatically at runtime when WicketFilter detects the javax.portlet.PortletContext class. When it does find this class, some of the Wicket settings are adjusted/overridden specifically for portlet support, like setting the RenderStrategy to REDIRECT_TO_RENDER. But not always portlet support is used or needed, even if deployed in a portlet supporting web container. The automatic settings changes then can result in unexpected/invalid behavior. To fix this, the default behavior for portlet support will be reverted back to disabled and will need to be specifically enabled. To support transparent configuration of the portlet support, e.g. if needed even without having to change the application web.xml, a flexible layer of configuration settings will be provided: if a Wicket filter parameter detectPortletContext is specified: - detect PortletContext if parameter value == true else if a web.xml context parameter org.apache.wicket.detectPortletContext is specified: - detect PortletContext if parameter value == true else if a org/apache/wicket/protocol/http/portlet/WicketPortlet.properties resource can be found on the classpath: - detect PortletContext if it specifies property/value org.apache.wicket.detectPortletContext=true. Note: the WicketPortlet.properties resource is already used by WicketPortlet itself to determine the ServletContextProvider and/or PortletResourceURLFactory class (if not specified otherwise). This provides a 100% save solution while still allowing transparent enabling portlet support for Portals like Jetspeed-2 which provide a WicketPortlet.properties with appropriate values out-of-the-box. Using this solution, the Wicket Examples still runs without needed changes in Jetspeed-2 but the default behavior will be reverted back to *not* automatically look for a PortletContext and thus by default not provide portlet support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Portal HowTo (page edited)
Page Edited : WICKET : Portal HowTo Portal HowTo has been edited by Ate Douma (Oct 24, 2007). (View changes) Content: Bookmarkable link Table of contents PortletResourceURLFactory ServletContextProvider WicketPortlet web.xml Enabling portlet support portlet.xml To get you started, I'll give the important configuration (and portal runtime) settings/requirements inline here. These will eventually end up tidied up, but for the moment, this is it... PortletResourceURLFactory First of all, you need to make sure the portal (e.g. Liferay ) provides an implementation of the Apache Portals Bridges PortletResourceURLFactory interface, see: PortletResourceURLFactory The related jar containing this interface, portal-bridges-common-1.0.3.jar (available from repo1.maven.org) needs to be in your portlet classpath directly or provided in the shared classpath of your portal. You will have to check if your portal provides support for these kind of RenderURLs which allows direct access to a portlet and full control over its response (like setting content type etc.). A ResourceURL will be a standard JSR-286 (Portlet API 2.0) feature but as it isn't yet released (Oct'07 - it will be soon) for which I created this temporary interface to allow using it in a JSR-186 container as well, as long as a portal provides a propetairy mapping for it. Jetspeed 2 does, and AFAIK, most other portals do as well, you just need to find out how to map this for Liferay and provide (or use) their proprietary api to handle it. ServletContextProvider Secondly, you need also to provide an implementation of the Apache Portals Bridges ServletContextProvider interface, see: ServletContextProvider That I know Liferay already provides as I know it provides support for the Apache Portals Struts Bridge which uses the same interface. Note: this interface also is provided with the portal-bridges-common-1.0.3.jar (and earlier). BTW: this inteface also won't be needed anymore for proper JSR-286 containers. Once they are available I'll upgrade the Wicket Portlet support to really work out-of-the-box and portal specific configurations won't be needed then. WicketPortlet The implementations of these two interfaces need to be provided to the WicketPortlet. There are three ways of doing that, the simplest is providing a WicketPortlet.properties file in the classpath under package org.apache.wicket.protocol.http.portlet. The one I provide with Jetspeed 2 (out-of-the-box through a shared library) contains the following: # Default Jetspeed-2 provided WicketPortlet ServletContextProvider and PortletResourceURLFactory org.apache.portals.bridges.common.ServletContextProvider=org.apache.jetspeed.portlet.ServletContextProviderImpl org.apache.portals.bridges.common.PortletResourceURLFactory=org.apache.jetspeed.portlet.PortletResourceURLFactoryImpl Another way of defining these (maybe easier for testing) is providing them as portlet init parameters (named "ServletContextProvider" and "PortletResourceURLFactory") or even as web.xml context param using their full class name just as in the properties file. Defining these through WicketPortlet.properties though will allow you to keep this portal specific configuration out of your application and thus be more portable. web.xml You will also need to modify the wicket filter mapping in your web.xml to support handling both direct requests as well include dispatch requests, e.g. filter-mapping filter-nameAjaxApplication/filter-name url-pattern/ajax/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping Note: this requires at least a Servlet 2.4 descriptor just as in the wicket-examples application. Enabling portlet support By default portlet support will not be enabled (as of wicket 1.3.0-beta5), because even when deployed in a portlet supporting web container, a Wicket application might not or should not be used as portlet. So, you'll have to provide a configuration setting to let WicketFilter detect if it actually is running in a Portlet Context. This can be done using a boolean (truefalse) value on three different levels: as filter parameter, web.xml context parameter, or finally as property in the above described WicketPortlet.properties. WicketFilter will check for such a configuration in the above order. To define this on filter level (possibly overriding a setting on web.xml or WicketPortlet.properties level): filter filter-nameMyWicketApplication/filter-name filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class init-param param-namedetectPortletContext/param-name param-valuetrue/param-value /init-param ... /filter To define this on web.xml context level as default for the whole of the web application
[jira] Created: (WICKET-1101) NullPointerException in HybridUrlCodingStrategy
NullPointerException in HybridUrlCodingStrategy --- Key: WICKET-1101 URL: https://issues.apache.org/jira/browse/WICKET-1101 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta4 Environment: JRE 1.4.2 Reporter: Sean Sullivan There is a bug in the HybridUrlCodingStrategy My web page contains some Wicket Ajax components. When the browser sends a Wicket Ajax request to the server, I get this: java.lang.NullPointerException at org.apache.wicket.request.target.coding.HybridUrlCodingStrategy$HybridBookmarkablePageRequestTarget.respond(HybridUrlCodingStrategy.java:813) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1097) 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:343) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:193) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:132) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:71) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:974) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:564) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200) at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119) at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276) at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71) at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182) at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334) at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56) at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618) at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:439) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1102) Hello World example should use WicketFilter instead of WicketServlet
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 Reporter: Sean Sullivan Priority: Minor 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-1085) Input Text Mask
[ https://issues.apache.org/jira/browse/WICKET-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537506 ] Sean Sullivan commented on WICKET-1085: --- Cool idea. I'd like to see this feature in Wicket Input Text Mask --- Key: WICKET-1085 URL: https://issues.apache.org/jira/browse/WICKET-1085 Project: Wicket Issue Type: New Feature Components: wicket-extensions Reporter: Will Hoover Assignee: Frank Bille Jensen Priority: Trivial 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.
