[jira] Commented: (WICKET-1635) Stripping javascript comments and whitespace breaks application when using prototype library
[ https://issues.apache.org/jira/browse/WICKET-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599697#action_12599697 ] Carlos Pita commented on WICKET-1635: - Yes, it is. You have already answered it before you noticed about this reminder issue. Stripping javascript comments and whitespace breaks application when using prototype library -- Key: WICKET-1635 URL: https://issues.apache.org/jira/browse/WICKET-1635 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita Assignee: Matej Knopp Priority: Blocker Just to remember about https://issues.apache.org/jira/browse/WICKET-987. I don't seem to be able to reopen it but I added a comment that justifies reconsideration of that issue. Please close this once 987 is open again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-987) Stripping javascript comments and whitespace breaks application when using prototype library
[ https://issues.apache.org/jira/browse/WICKET-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596811#action_12596811 ] Carlos Pita commented on WICKET-987: Line 4025 of prototype 1.6.0.2 gets truncated from document.write(script id=__onDOMContentLoaded defer src=//:\/script); to document.write(script id=__onDOMContentLoaded defer src= on deployment mode. I think this is critical because it would probably be fatal for applications in production that depends on prototype (ours does). Stripping javascript comments and whitespace breaks application when using prototype library Key: WICKET-987 URL: https://issues.apache.org/jira/browse/WICKET-987 Project: Wicket Issue Type: Bug Affects Versions: 1.3.0-beta1, 1.3.0-beta2, 1.3.0-beta3 Environment: wicket-1.3.0-beta3, wicketstuff-scriptaculous-1.3-SNAPSHOT Reporter: Ryan Sonnek Assignee: Matej Knopp Priority: Blocker Fix For: 1.3.0-beta4 Attachments: minify-javascript.zip whenever I enable stripping javascript comments and whitespace, I get javascript errors loading my prototype.js file. Since wicket automatically enables this setting when in DEPLOYMENT mode, this is a real show stopper for releasing my app. This has been talked about recently, but I would recommend using an official javascript minification library instead of this home rolled implementation. The YUI compressor seems to be correctly licensed and would be a great option, but I don't care as long as this is fixed. see WICKET-918 for more info attaching sample project that exhibits the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1635) Stripping javascript comments and whitespace breaks application when using prototype library
Stripping javascript comments and whitespace breaks application when using prototype library -- Key: WICKET-1635 URL: https://issues.apache.org/jira/browse/WICKET-1635 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita Priority: Blocker Just to remember about https://issues.apache.org/jira/browse/WICKET-987. I don't seem to be able to reopen it but I added a comment that justifies reconsideration of that issue. Please close this once 987 is open again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1566) AbstractTransformerBehavior doesn't honor character encoding
[ https://issues.apache.org/jira/browse/WICKET-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-1566: Summary: AbstractTransformerBehavior doesn't honor character encoding (was: AbstractTransformerBehavior doesn't honor the defaultMarkupEncoding) AbstractTransformerBehavior doesn't honor character encoding Key: WICKET-1566 URL: https://issues.apache.org/jira/browse/WICKET-1566 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita Fix: do String charset = component.getApplication().getMarkupSettings().getDefaultMarkupEncoding(); webResponse.write(new ByteArrayInputStream(output).getBytes(charset))); instead of webResponse.write(output); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1566) AbstractTransformerBehavior doesn't honor the defaultMarkupEncoding
[
https://issues.apache.org/jira/browse/WICKET-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592662#action_12592662
]
Carlos Pita commented on WICKET-1566:
-
Now I realize that this problem only happens in a modification of mine that can
also transform pages (see
https://issues.apache.org/jira/browse/WICKET-1565). The problem is that the
stringresponse doesn't forward the content type to the underlying webresponse,
which ultimately configure the httpservletresponse encoding, this last being
the one that determines the servlet response writer charset. A simple
StringResponse subclass forwarding encoding related methods will do the trick,
in case you're interested in implementing 1565.
StringResponse stringResponse = new StringResponse() {
@Override
public void setCharacterEncoding(String
encoding) {
originalResponse.setCharacterEncoding(encoding);
}
@Override
public void setContentType(String mimeType) {
originalResponse.setContentType(mimeType);
}
};
AbstractTransformerBehavior doesn't honor the defaultMarkupEncoding
---
Key: WICKET-1566
URL: https://issues.apache.org/jira/browse/WICKET-1566
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.3
Reporter: Carlos Pita
Fix:
do
String charset =
component.getApplication().getMarkupSettings().getDefaultMarkupEncoding();
webResponse.write(new ByteArrayInputStream(output).getBytes(charset)));
instead of
webResponse.write(output);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1565) AbstractTransformerBehavior can't be added to a page
[ https://issues.apache.org/jira/browse/WICKET-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592664#action_12592664 ] Carlos Pita commented on WICKET-1565: - See also https://issues.apache.org/jira/browse/WICKET-1566, which describes another issue with extending this behavior to pages. AbstractTransformerBehavior can't be added to a page Key: WICKET-1565 URL: https://issues.apache.org/jira/browse/WICKET-1565 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita Fix: leave just tag.put(xmlns:wicket, http://wicket.apache.org;); in onComponentTag. And put the rest (response replacement) into beforeRender. This is because onComponentTag is not called for pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1565) AbstractTransformerBehavior can't be added to a page
AbstractTransformerBehavior can't be added to a page Key: WICKET-1565 URL: https://issues.apache.org/jira/browse/WICKET-1565 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita Fix: leave just tag.put(xmlns:wicket, http://wicket.apache.org;); in onComponentTag. And put the rest (response replacement) into beforeRender. This is because onComponentTag in not called for pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1565) AbstractTransformerBehavior can't be added to a page
[ https://issues.apache.org/jira/browse/WICKET-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-1565: Description: Fix: leave just tag.put(xmlns:wicket, http://wicket.apache.org;); in onComponentTag. And put the rest (response replacement) into beforeRender. This is because onComponentTag is not called for pages. was: Fix: leave just tag.put(xmlns:wicket, http://wicket.apache.org;); in onComponentTag. And put the rest (response replacement) into beforeRender. This is because onComponentTag in not called for pages. AbstractTransformerBehavior can't be added to a page Key: WICKET-1565 URL: https://issues.apache.org/jira/browse/WICKET-1565 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita Fix: leave just tag.put(xmlns:wicket, http://wicket.apache.org;); in onComponentTag. And put the rest (response replacement) into beforeRender. This is because onComponentTag is not called for pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1566) AbstractTransformerBehavior doesn't honor the defaultMarkupEncoding
AbstractTransformerBehavior doesn't honor the defaultMarkupEncoding --- Key: WICKET-1566 URL: https://issues.apache.org/jira/browse/WICKET-1566 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita Fix: do String charset = component.getApplication().getMarkupSettings().getDefaultMarkupEncoding(); webResponse.write(new ByteArrayInputStream(output).getBytes(charset))); instead of webResponse.write(output); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1563) renderOnLoadJavascript being called multiple times
renderOnLoadJavascript being called multiple times -- Key: WICKET-1563 URL: https://issues.apache.org/jira/browse/WICKET-1563 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Carlos Pita There are at least of couple of common scenarios where this happens: - you add the component that is a header contributor to an ajax target: renderHead is called as part of target.respond() and latter by page.detach() - you add the component that is a header contributor more than once to an ajax target. Normally you can't control this, because the component in question is added by another component indirectly, by adding some of its ancestors. renderHead is called multiple times as part of target.respond() and latter yet another time by page.detach() I think there must be a check to avoid repetitions of these nature, maybe by means of an id, the same as renderJavascript() does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1332) AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
[
https://issues.apache.org/jira/browse/WICKET-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581603#action_12581603
]
Carlos Pita commented on WICKET-1332:
-
Johan, after posting this I realized that it should say 'checkbox' instead of
'check', but forgot to comment about it at that time.
AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
--
Key: WICKET-1332
URL: https://issues.apache.org/jira/browse/WICKET-1332
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Carlos Pita
Assignee: Johan Compagner
Fix For: 1.3.3
Up to 1.3.0, there was a bug in that AjaxFormChoiceComponentUpdatingBehavior
updated just the group's direct children. Now it generates the header script
quoted below, that iterates over the direct children and then over the
children of these, triggering the event for the input grandchildren only. So
the situation is even worse. I think that attachChoiceHandlers should descend
recursively and search for input elements along all the group descendants,
not just one arbitrarily chosen level.
function attachChoiceHandlers(markupid, callbackscript) {
var choiceElementGroup = document.getElementById(markupid);
for( var x = 0; x choiceElementGroup.childNodes.length; x++ ) {
var choiceElementList = choiceElementGroup.childNodes[x]; for( var y =
0; y choiceElementList.childNodes.length; y++ ) {
if (choiceElementList.childNodes[y]
choiceElementList.childNodes[y].tagName) {
var tag = choiceElementList.childNodes[y].tagName.toLowerCase();
if (tag == 'input') {
Wicket.Event.add(choiceElementList.childNodes[y],'click',
callbackscript); }
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1420) Allow to change charset in StringRequestTarget
Allow to change charset in StringRequestTarget -- Key: WICKET-1420 URL: https://issues.apache.org/jira/browse/WICKET-1420 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1 Reporter: Carlos Pita It's impossible to access the created StringBufferResourceStream charset without overriding the entire respond method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1332) AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
[
https://issues.apache.org/jira/browse/WICKET-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570459#action_12570459
]
Carlos Pita commented on WICKET-1332:
-
Here is a shorter, safer and faster version that uses getElementsByTagName
instead of a recursive descent. It also checks for the type of input fields in
order to attach handlers just to radios and checkboxes.
asb.append(function attachChoiceHandlers(markupId, callbackScript)
{\n);
asb.append( var inputNodes =
wicketGet(markupId).getElementsByTagName('input');\n);
asb.append( for (var i = 0 ; i inputNodes.length ; i ++) {\n);
asb.append(var inputNode = inputNodes[i];\n);
asb.append(if (!inputNode.type) continue;\n);
asb.append(var inputType = inputNode.type.toLowerCase();\n);
asb.append(if (inputType == 'check' || inputType == 'radio') {\n);
asb.append( Wicket.Event.add(inputNode, 'click',
callbackScript);\n);
asb.append(}\n);
asb.append( }\n);
asb.append(}\n);
AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
--
Key: WICKET-1332
URL: https://issues.apache.org/jira/browse/WICKET-1332
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Carlos Pita
Assignee: Matej Knopp
Up to 1.3.0, there was a bug in that AjaxFormChoiceComponentUpdatingBehavior
updated just the group's direct children. Now it generates the header script
quoted below, that iterates over the direct children and then over the
children of these, triggering the event for the input grandchildren only. So
the situation is even worse. I think that attachChoiceHandlers should descend
recursively and search for input elements along all the group descendants,
not just one arbitrarily chosen level.
function attachChoiceHandlers(markupid, callbackscript) {
var choiceElementGroup = document.getElementById(markupid);
for( var x = 0; x choiceElementGroup.childNodes.length; x++ ) {
var choiceElementList = choiceElementGroup.childNodes[x]; for( var y =
0; y choiceElementList.childNodes.length; y++ ) {
if (choiceElementList.childNodes[y]
choiceElementList.childNodes[y].tagName) {
var tag = choiceElementList.childNodes[y].tagName.toLowerCase();
if (tag == 'input') {
Wicket.Event.add(choiceElementList.childNodes[y],'click',
callbackscript); }
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1360) Wrong path separator in reloading classloader patterns
Wrong path separator in reloading classloader patterns
--
Key: WICKET-1360
URL: https://issues.apache.org/jira/browse/WICKET-1360
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Carlos Pita
public class WildcardMatcherHelper
{
[]
/** Default path separator: / */
public static final char PATHSEP = '/'; should be '.'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1332) AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
--
Key: WICKET-1332
URL: https://issues.apache.org/jira/browse/WICKET-1332
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Carlos Pita
Up to 1.3.0, there was a bug in that AjaxFormChoiceComponentUpdatingBehavior
updated just the group's direct children. Now it generates the header script
quoted below, that iterates over the direct children and then over the children
of these, triggering the event for the input grandchildren only. So the
situation is even worse. I think that attachChoiceHandlers should descend
recursively and search for input elements along all the group descendants, not
just one arbitrarily chosen level.
function attachChoiceHandlers(markupid, callbackscript) {
var choiceElementGroup = document.getElementById(markupid);
for( var x = 0; x choiceElementGroup.childNodes.length; x++ ) {
var choiceElementList = choiceElementGroup.childNodes[x]; for( var y = 0;
y choiceElementList.childNodes.length; y++ ) {
if (choiceElementList.childNodes[y]
choiceElementList.childNodes[y].tagName) {
var tag = choiceElementList.childNodes[y].tagName.toLowerCase();
if (tag == 'input') {
Wicket.Event.add(choiceElementList.childNodes[y],'click',
callbackscript); }
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1332) AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
[
https://issues.apache.org/jira/browse/WICKET-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567355#action_12567355
]
Carlos Pita commented on WICKET-1332:
-
Here is a fix I'm using meanwhile, using proptotype:
function attachChoiceHandlers(markupid, callbackscript) {
$(markupid).descendants().each(function(element) {
if (element element.tagName) {
if (element.tagName.toLowerCase() == 'input') {
Wicket.Event.add(element, 'click', callbackscript); }
}
});
}
AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
--
Key: WICKET-1332
URL: https://issues.apache.org/jira/browse/WICKET-1332
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Carlos Pita
Up to 1.3.0, there was a bug in that AjaxFormChoiceComponentUpdatingBehavior
updated just the group's direct children. Now it generates the header script
quoted below, that iterates over the direct children and then over the
children of these, triggering the event for the input grandchildren only. So
the situation is even worse. I think that attachChoiceHandlers should descend
recursively and search for input elements along all the group descendants,
not just one arbitrarily chosen level.
function attachChoiceHandlers(markupid, callbackscript) {
var choiceElementGroup = document.getElementById(markupid);
for( var x = 0; x choiceElementGroup.childNodes.length; x++ ) {
var choiceElementList = choiceElementGroup.childNodes[x]; for( var y =
0; y choiceElementList.childNodes.length; y++ ) {
if (choiceElementList.childNodes[y]
choiceElementList.childNodes[y].tagName) {
var tag = choiceElementList.childNodes[y].tagName.toLowerCase();
if (tag == 'input') {
Wicket.Event.add(choiceElementList.childNodes[y],'click',
callbackscript); }
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1173) Border bodycontainer doesn't render a markup placeholder
Border bodycontainer doesn't render a markup placeholder Key: WICKET-1173 URL: https://issues.apache.org/jira/browse/WICKET-1173 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-rc1 Reporter: Carlos Pita Fix For: 1.3.0-rc2 Attachments: border.tgz A border with getBodyContainer().setOutputMarkupPlaceholderTag(true); doesn't generate a placeholder after its body is hidden. I've attached an example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1173) Border bodycontainer doesn't render a markup placeholder
[ https://issues.apache.org/jira/browse/WICKET-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-1173: Attachment: border.tgz Border bodycontainer doesn't render a markup placeholder Key: WICKET-1173 URL: https://issues.apache.org/jira/browse/WICKET-1173 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-rc1 Reporter: Carlos Pita Fix For: 1.3.0-rc2 Attachments: border.tgz A border with getBodyContainer().setOutputMarkupPlaceholderTag(true); doesn't generate a placeholder after its body is hidden. I've attached an 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-957) Change default focus component for focus related events to null
[ https://issues.apache.org/jira/browse/WICKET-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539795 ] Carlos Pita commented on WICKET-957: Yes, the decisive factor here is what this other field happens to be. If it is a widget of the browser own ui it won't keep focus after validation takes place. There are some third party components (of which I'm aware of tinymce) that present a similar behavior too. All in all, the resulting user experience is quite odd. Change default focus component for focus related events to null --- Key: WICKET-957 URL: https://issues.apache.org/jira/browse/WICKET-957 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3 Reporter: Carlos Pita Priority: Minor Fix For: 1.3.0-beta5 Currently the default behavior for ajax requests is to restore focus on last focused element. This produces some bizarre situations when onfocus or onblur are used for ajax validation. For example, if the form component to be validated gets its focus transferred to some browser ui widget (say, the location bar), triggering an onblur validation this way, it immediately recaptures focus after validation has been completed (making it impossible to type text at the location bar unless your fingers happen to be faster than the ajax rtt, to follow the example). A similar problem occurs with tinymce editor, at least. This behavior can be circumvented explicitly setting target.focusComponent(null) for validation purposes, but why is it not this way in the first place, at least for the focus related events? With a better behaved default quite a number of ugly situations for such common use case as ajax validation is could be avoided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-992) Field validating behavior
Field validating behavior - Key: WICKET-992 URL: https://issues.apache.org/jira/browse/WICKET-992 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3, 1.3.0-beta4 Reporter: Carlos Pita Priority: Minor Suppose you need to edit a persistent entity progressively ajax-validating it field-by-field (so ajaxformvalidatingbehavior is out of case here). If you use ajaxformcomponentupdatingbehavior you have a number of alternatives: 1) Tolerate partial updating if you use tx-per-request. 2) Use a read-only tx for the presentation layer so partial changes won't be committed to the db. 3) Make your entity serializable, detach it from persistent session and store it into the wicket session as a form (java)field. 4) Clone you entity after loading it, then update and discard the clone, leaving the original entity unmodified. 5) Create a dto and edit it instead of the original entity. Then merge the changes into the entity when the form is finally submitted. It's often the case that partial updating can't be tolerated as suggested in 1. Also, 1,2 and 4 suffer from unnecessary overhead because they all hit the db when the only requirement is validating a field (binding is superfluous, this is clear from the fact that changes are discarded at the final of the request in 2 and 4). 3 suffers from its own overhead too: wicket session space, and also forces you to make your classes serializable, which can be somewhat of a headache when entities are big and composed of a number of embedded components and also undesirable because silent storage into the wicket session could occur later when it isn't really intended; as a rule of thumb i prefer to avoid serialization for big entities when possible. 5 implies redundant code and work, in general practice I find it more cumbersome and not really better than 3. The only step in ajaxformcomponentupdatingbehavior workflow that requires model object access is the line formComponent.updateModel(). Except for this the behavior perfectly fits as a validating behavior. I could copy past everything into a new class of mine and remove the offending line but I feel that a flag that avoids the updating step or another hook or point of extension in order to achieve a validation-only behavior can be of more general use and also orthogonal in the sense that wicket already has validation-only functionality at the form level. Or ajaxformcomponentupdatingbehavior could extend a ajaxformcomponent*validating*behavior adding the updating step. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-965) Link doesn't work when there is an inlineframe in source page and a page hierarchy involved
[ https://issues.apache.org/jira/browse/WICKET-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527183 ] Carlos Pita commented on WICKET-965: It only happens when using the ReloadingWicketServlet. Link doesn't work when there is an inlineframe in source page and a page hierarchy involved --- Key: WICKET-965 URL: https://issues.apache.org/jira/browse/WICKET-965 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3 Reporter: Carlos Pita Fix For: 1.3.0-beta4 Attachments: framelink.tgz I track down this problem until I get the minimal example that is attached. You can see that following the link from page1 to page2 the exception below is thrown: WicketMessage: Markup of type 'html' for component 'web.framelink.Page2' not found. Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried: [Page class = web.framelink.Page2, id = 8, version = 0] Root cause: org.apache.wicket.WicketRuntimeException: Parameter clazz must be an instance of web.framelink.Page2, but is a web.framelink.BasePage at org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:270) at org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.checkForMarkupInheritance(InheritedMarkupMarkupLoader.java:97) at org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:63) This doesn't happen if you remove the iframe from the hierarchy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-957) Change default focus component for focus related events to null
Change default focus component for focus related events to null --- Key: WICKET-957 URL: https://issues.apache.org/jira/browse/WICKET-957 Project: Wicket Issue Type: Improvement Affects Versions: 1.3.0-beta3 Reporter: Carlos Pita Fix For: 1.3.0-beta4 Currently the default behavior for ajax requests is to restore focus on last focused element. This produces some bizarre situations when onfocus or onblur are used for ajax validation. For example, if the form component to be validated gets its focus transferred to some browser ui widget (say, the location bar), triggering an onblur validation this way, it immediately recaptures focus after validation has been completed (making it impossible to type text at the location bar unless your fingers happen to be faster than the ajax rtt, to follow the example). A similar problem occurs with tinymce editor, at least. This behavior can be circumvented explicitly setting target.focusComponent(null) for validation purposes, but why is it not this way in the first place, at least for the focus related events? With a better behaved default quite a number of ugly situations for such common use case as ajax validation is could be avoided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-957) Change default focus component for focus related events to null
[ https://issues.apache.org/jira/browse/WICKET-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-957: --- Component/s: wicket Priority: Minor (was: Major) Change default focus component for focus related events to null --- Key: WICKET-957 URL: https://issues.apache.org/jira/browse/WICKET-957 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3 Reporter: Carlos Pita Priority: Minor Fix For: 1.3.0-beta4 Currently the default behavior for ajax requests is to restore focus on last focused element. This produces some bizarre situations when onfocus or onblur are used for ajax validation. For example, if the form component to be validated gets its focus transferred to some browser ui widget (say, the location bar), triggering an onblur validation this way, it immediately recaptures focus after validation has been completed (making it impossible to type text at the location bar unless your fingers happen to be faster than the ajax rtt, to follow the example). A similar problem occurs with tinymce editor, at least. This behavior can be circumvented explicitly setting target.focusComponent(null) for validation purposes, but why is it not this way in the first place, at least for the focus related events? With a better behaved default quite a number of ugly situations for such common use case as ajax validation is could be avoided. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-910) Add forXXX family of factories for StringHeaderContributor too
Add forXXX family of factories for StringHeaderContributor too -- Key: WICKET-910 URL: https://issues.apache.org/jira/browse/WICKET-910 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3, 1.3.0-beta4 Reporter: Carlos Pita Priority: Minor As there is this family for the other contributors: TextTemplateHeaderContributor and HeaderContributor. This way one could avoid writing boilerplate code like: JavascriptUtils.SCRIPT_OPEN_TAG + myScript + JavascriptUtils.SCRIPT_CLOSE_TAG; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-905) [nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from iframe
[ https://issues.apache.org/jira/browse/WICKET-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-905: --- Attachment: iframe.tgz [nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from iframe Key: WICKET-905 URL: https://issues.apache.org/jira/browse/WICKET-905 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3, 1.3.0-beta4 Reporter: Carlos Pita Attachments: iframe.tgz Below is a description copy pasted from the irc channel. Please take into account that you must mount the attached example at a depth-2 path (as context/app/iframe/wicket) or otherwise fix the url from hideBehavior.getCallback().replace(../, ) (line 60 of WicketAjaxPage, I don't know of a better way of doing this, adding the behavior to the iframe doesn't work either). igor, do you remember that a couple of days ago i asked you about calling an ajax behavior from an iframe? i managed to do it using a vanilla XmlHttpRequest to reenter wicket through the behavior and then parsing the wicket response by hand but i tried a lot of combinations to avoid that hack to, the closer i got was patching the behavior url a bit, to get it relative to the main page, not the iframe, and spitting out a bit of javascript on the top window to be called by the iframe the behavior is executed and the ajax reponse is correctly handled, but then every other ajax request fail with this: uncaught exception: [Exception... Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.open] nsresult: 0x80004005 (NS_ERROR_FAILURE) location: JS frame :: javascript: eval(__firebugTemp__); :: anonymous :: line 1 data: no] I have a quickstart for this, do you think it's a bug in wicket? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-905) [nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from iframe
[nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from iframe Key: WICKET-905 URL: https://issues.apache.org/jira/browse/WICKET-905 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3, 1.3.0-beta4 Reporter: Carlos Pita Attachments: iframe.tgz Below is a description copy pasted from the irc channel. Please take into account that you must mount the attached example at a depth-2 path (as context/app/iframe/wicket) or otherwise fix the url from hideBehavior.getCallback().replace(../, ) (line 60 of WicketAjaxPage, I don't know of a better way of doing this, adding the behavior to the iframe doesn't work either). igor, do you remember that a couple of days ago i asked you about calling an ajax behavior from an iframe? i managed to do it using a vanilla XmlHttpRequest to reenter wicket through the behavior and then parsing the wicket response by hand but i tried a lot of combinations to avoid that hack to, the closer i got was patching the behavior url a bit, to get it relative to the main page, not the iframe, and spitting out a bit of javascript on the top window to be called by the iframe the behavior is executed and the ajax reponse is correctly handled, but then every other ajax request fail with this: uncaught exception: [Exception... Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.open] nsresult: 0x80004005 (NS_ERROR_FAILURE) location: JS frame :: javascript: eval(__firebugTemp__); :: anonymous :: line 1 data: no] I have a quickstart for this, do you think it's a bug in wicket? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-905) [nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from iframe
[ https://issues.apache.org/jira/browse/WICKET-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523733 ] Carlos Pita commented on WICKET-905: One more remark: replacing the onHide behavior callback with a custom handler that does a GET httpxmlrequest or prototype ajax.request to the same -fixed- url, and then parses the response in an adhoc way, lets me do succesive ajax requests without raising the 0x80004005 error. It seems to be something involving firefox and wicket management of ajax requests, maybe it's related to the abort call that's done on the transport, dunno. [nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from iframe Key: WICKET-905 URL: https://issues.apache.org/jira/browse/WICKET-905 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3, 1.3.0-beta4 Reporter: Carlos Pita Attachments: iframe.tgz Below is a description copy pasted from the irc channel. Please take into account that you must mount the attached example at a depth-2 path (as context/app/iframe/wicket) or otherwise fix the url from hideBehavior.getCallback().replace(../, ) (line 60 of WicketAjaxPage, I don't know of a better way of doing this, adding the behavior to the iframe doesn't work either). igor, do you remember that a couple of days ago i asked you about calling an ajax behavior from an iframe? i managed to do it using a vanilla XmlHttpRequest to reenter wicket through the behavior and then parsing the wicket response by hand but i tried a lot of combinations to avoid that hack to, the closer i got was patching the behavior url a bit, to get it relative to the main page, not the iframe, and spitting out a bit of javascript on the top window to be called by the iframe the behavior is executed and the ajax reponse is correctly handled, but then every other ajax request fail with this: uncaught exception: [Exception... Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.open] nsresult: 0x80004005 (NS_ERROR_FAILURE) location: JS frame :: javascript: eval(__firebugTemp__); :: anonymous :: line 1 data: no] I have a quickstart for this, do you think it's a bug in wicket? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-905) [nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from iframe
[
https://issues.apache.org/jira/browse/WICKET-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Pita resolved WICKET-905.
Resolution: Fixed
I solved this wrapping the behavior js call inside
window.setTimeout(function() { }, 0); so that the context *really* is the top
window, as matej wisely pointed out. Later I will post a howto into the wiki
showing how to upload a file from a different iframe and call a behavior on the
top frame to get rid of the iframe or something afterwards.
[nsIXMLHttpRequest.open] nsresult: 0x80004005 after calling behavior from
iframe
Key: WICKET-905
URL: https://issues.apache.org/jira/browse/WICKET-905
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.0-beta3, 1.3.0-beta4
Reporter: Carlos Pita
Attachments: iframe.tgz
Below is a description copy pasted from the irc channel. Please take into
account that you must mount the attached example at a depth-2 path (as
context/app/iframe/wicket) or otherwise fix the url from
hideBehavior.getCallback().replace(../, ) (line 60 of WicketAjaxPage, I
don't know of a better way of doing this, adding the behavior to the iframe
doesn't work either).
igor, do you remember that a couple of days ago i asked you about calling an
ajax behavior from an iframe?
i managed to do it using a vanilla XmlHttpRequest to reenter wicket through
the behavior and then parsing the wicket response by hand
but i tried a lot of combinations to avoid that hack to, the closer i got
was patching the behavior url a bit, to get it relative to the main page,
not the iframe, and spitting out a bit of javascript on the top window to
be called by the iframe
the behavior is executed and the ajax reponse is correctly handled, but
then every other ajax request fail
with this: uncaught exception: [Exception... Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.open] nsresult:
0x80004005 (NS_ERROR_FAILURE) location: JS frame :: javascript:
eval(__firebugTemp__); :: anonymous :: line 1 data: no]
I have a quickstart for this, do you think it's a bug in wicket?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-887) Unable to find InlineFrames when inside ListViews
[ https://issues.apache.org/jira/browse/WICKET-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523029 ] Carlos Pita commented on WICKET-887: Answering your note, from the outer page I need to grab a reference to the pages that are inside the iframes, and it doesn't seem to be possible to get them later, for example as a property of the iframe. Maybe a getter as InlineFrame.getPage() would help here. Unable to find InlineFrames when inside ListViews - Key: WICKET-887 URL: https://issues.apache.org/jira/browse/WICKET-887 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita Assignee: Igor Vaynberg Fix For: 1.3.0-beta4 Attachments: iframes.tgz There is a simple example attached. Even if the list is reusing items (and even with a RefreshingView with reuseifmodelequal strategy) the problem persists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-874) Reloading servlet doing way too much reloading
[ https://issues.apache.org/jira/browse/WICKET-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1259 ] Carlos Pita commented on WICKET-874: Thanks a bunch JB, now it seems to go with flying colors! Reloading servlet doing way too much reloading -- Key: WICKET-874 URL: https://issues.apache.org/jira/browse/WICKET-874 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita Assignee: Jean-Baptiste Quenot Fix For: 1.3.0-beta4 As our project gets bigger in terms of number of classes the reloading servlet is not only becoming slower (it seems as it's reloading a lot of classes after each tiny change) but often incurring into sort of neverending reloading loops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-874) Reloading servlet doing way too much reloading
Reloading servlet doing way too much reloading -- Key: WICKET-874 URL: https://issues.apache.org/jira/browse/WICKET-874 Project: Wicket Issue Type: Bug Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita As our project gets bigger in terms of number of classes the reloading servlet is not only becoming slower (it seems as it's reloading a lot of classes after each tiny change) but often incurring into sort of neverending reloading loops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-874) Reloading servlet doing way too much reloading
[ https://issues.apache.org/jira/browse/WICKET-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-874: --- Component/s: wicket Reloading servlet doing way too much reloading -- Key: WICKET-874 URL: https://issues.apache.org/jira/browse/WICKET-874 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita As our project gets bigger in terms of number of classes the reloading servlet is not only becoming slower (it seems as it's reloading a lot of classes after each tiny change) but often incurring into sort of neverending reloading loops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-850) Bad message resolution when sibling components require the same key
Bad message resolution when sibling components require the same key --- Key: WICKET-850 URL: https://issues.apache.org/jira/browse/WICKET-850 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita Attachments: resources.tgz Attached there is an example of two panels, each one with its own properties file that assigns a different message to the same key, that anyway are showing the very same message when added to a page as siblings at the top level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-850) Bad message resolution when sibling components require the same key
[ https://issues.apache.org/jira/browse/WICKET-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-850: --- Attachment: resources.tgz Bad message resolution when sibling components require the same key --- Key: WICKET-850 URL: https://issues.apache.org/jira/browse/WICKET-850 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita Attachments: resources.tgz Attached there is an example of two panels, each one with its own properties file that assigns a different message to the same key, that anyway are showing the very same message when added to a page as siblings at the top level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-841) More problems with ajax and transparent containers
[ https://issues.apache.org/jira/browse/WICKET-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-841: --- Description: Attached is my attempt to get a list that is ajax refreshed just at the tail. It's implemented as a sort of linked list. There are two versions. 'list' implements each node as a Panel, having contents (a number) and a next container which is made visible and ajax refreshed when one new element is added to the list. 'list2' does the same but using a Fragment instead of a Panel. You guessed, panels works just fine, but for the fragments version I get the usual transparent containers exception when trying to append an element: WicketMessage: Unable to find the markup for the component. That may be due to transparent containers or components implementing IComponentResolver: [MarkupContainer [Component id = nextContainer, page = web.list2.ListPage, path = 0:first:nextContainer.WebMarkupContainer, isVisible = true, isVersioned = true]] Root cause: org.apache.wicket.WicketRuntimeException: Unable to find the markup for the component. That may be due to transparent containers or components implementing IComponentResolver: [MarkupContainer [Component id = nextContainer, page = web.list2.ListPage, path = 0:first:nextContainer.WebMarkupContainer, isVisible = true, isVersioned = true]] at org.apache.wicket.MarkupFragmentFinder.find(MarkupFragmentFinder.java:111) at org.apache.wicket.Component.locateMarkupStream(Component.java:3274) at org.apache.wicket.Component.renderComponent(Component.java:2087) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:772) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:672) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:522) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1038) was: Attached is my attempt to get a list that is ajax refreshed just at the tail. It's implemented as a sort of linked list. There are two versions. 'list' implements each node as a Panel, having contents (a number) and a next container which is made visible and ajax refreshed when one new element is added to the list. 'list2' does the same but using a Fragment instead of a Panel. You guessed, panels works just fine, for the fragments version I get the usual WicketMessage: Unable to find the markup for the component. That may be due to transparent containers or components implementing IComponentResolver: [MarkupContainer [Component id = nextContainer, page = web.list2.ListPage, path = 0:first:nextContainer.WebMarkupContainer, isVisible = true, isVersioned = true]] Root cause: org.apache.wicket.WicketRuntimeException: Unable to find the markup for the component. That may be due to transparent containers or components implementing IComponentResolver: [MarkupContainer [Component id = nextContainer, page = web.list2.ListPage, path = 0:first:nextContainer.WebMarkupContainer, isVisible = true, isVersioned = true]] at org.apache.wicket.MarkupFragmentFinder.find(MarkupFragmentFinder.java:111) at org.apache.wicket.Component.locateMarkupStream(Component.java:3274) at org.apache.wicket.Component.renderComponent(Component.java:2087) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:772) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:672) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:522) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1038) More problems with ajax and transparent containers -- Key: WICKET-841 URL: https://issues.apache.org/jira/browse/WICKET-841 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita Attached is my attempt to get a list that is ajax refreshed just at the tail. It's implemented as a sort of linked list. There are two versions. 'list' implements each node as a Panel, having contents (a number) and a next container which is made visible and ajax refreshed when one new element is added to the list. 'list2' does the same but using a Fragment instead of a Panel. You guessed, panels works just fine, but for the fragments version I get the usual transparent containers exception when trying to append an element: WicketMessage: Unable to find the markup for the component. That may be due to transparent containers or components implementing IComponentResolver: [MarkupContainer
[jira] Created: (WICKET-838) AjaxFormChoiceComponentUpdatingBehavior not working
AjaxFormChoiceComponentUpdatingBehavior not working --- Key: WICKET-838 URL: https://issues.apache.org/jira/browse/WICKET-838 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2 Reporter: Carlos Pita Fix For: 1.3.0-beta3 Attachments: ChoiceBehaviorPage.html, ChoiceBehaviorPage.java I think this is because of its own component field that is hiding that of AbstractAjaxBehavior. Try to run the attached example and you will get: WicketMessage: Exception in rendering component: [MarkupContainer [Component id = _header_, page = com.livra.web.user.RegistrationPage, path = 12:_header_.HtmlHeaderContainer, isVisible = true, isVersioned = true]] Root cause: java.lang.NullPointerException at org.apache.wicket.ajax.form.AjaxFormChoiceComponentUpdatingBehavior.renderHead(AjaxFormChoiceComponentUpdatingBehavior.java:71) at org.apache.wicket.Component.renderHead(Component.java:2266) at org.apache.wicket.markup.html.internal.HtmlHeaderContainer$1.component(HtmlHeaderContainer.java:209) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:843) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:858) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:883) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-838) AjaxFormChoiceComponentUpdatingBehavior not working
[ https://issues.apache.org/jira/browse/WICKET-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-838: --- Attachment: ChoiceBehaviorPage.java AjaxFormChoiceComponentUpdatingBehavior not working --- Key: WICKET-838 URL: https://issues.apache.org/jira/browse/WICKET-838 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2 Reporter: Carlos Pita Fix For: 1.3.0-beta3 Attachments: ChoiceBehaviorPage.html, ChoiceBehaviorPage.java I think this is because of its own component field that is hiding that of AbstractAjaxBehavior. Try to run the attached example and you will get: WicketMessage: Exception in rendering component: [MarkupContainer [Component id = _header_, page = com.livra.web.user.RegistrationPage, path = 12:_header_.HtmlHeaderContainer, isVisible = true, isVersioned = true]] Root cause: java.lang.NullPointerException at org.apache.wicket.ajax.form.AjaxFormChoiceComponentUpdatingBehavior.renderHead(AjaxFormChoiceComponentUpdatingBehavior.java:71) at org.apache.wicket.Component.renderHead(Component.java:2266) at org.apache.wicket.markup.html.internal.HtmlHeaderContainer$1.component(HtmlHeaderContainer.java:209) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:843) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:858) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:883) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-838) AjaxFormChoiceComponentUpdatingBehavior not working
[ https://issues.apache.org/jira/browse/WICKET-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-838: --- Attachment: ChoiceBehaviorPage.html AjaxFormChoiceComponentUpdatingBehavior not working --- Key: WICKET-838 URL: https://issues.apache.org/jira/browse/WICKET-838 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2 Reporter: Carlos Pita Fix For: 1.3.0-beta3 Attachments: ChoiceBehaviorPage.html, ChoiceBehaviorPage.java I think this is because of its own component field that is hiding that of AbstractAjaxBehavior. Try to run the attached example and you will get: WicketMessage: Exception in rendering component: [MarkupContainer [Component id = _header_, page = com.livra.web.user.RegistrationPage, path = 12:_header_.HtmlHeaderContainer, isVisible = true, isVersioned = true]] Root cause: java.lang.NullPointerException at org.apache.wicket.ajax.form.AjaxFormChoiceComponentUpdatingBehavior.renderHead(AjaxFormChoiceComponentUpdatingBehavior.java:71) at org.apache.wicket.Component.renderHead(Component.java:2266) at org.apache.wicket.markup.html.internal.HtmlHeaderContainer$1.component(HtmlHeaderContainer.java:209) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:843) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:858) at org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:883) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-836) feedback panels not being updated when inside repeaters
feedback panels not being updated when inside repeaters --- Key: WICKET-836 URL: https://issues.apache.org/jira/browse/WICKET-836 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita see the attached example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-836) feedback panels not being updated when inside repeaters
[ https://issues.apache.org/jira/browse/WICKET-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Pita updated WICKET-836: --- Attachment: FeedbackPage.html feedback panels not being updated when inside repeaters --- Key: WICKET-836 URL: https://issues.apache.org/jira/browse/WICKET-836 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita Attachments: FeedbackPage.html, FeedbackPage.java see the attached example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-834) Cannot make border body contents visible once they were hidden
Cannot make border body contents visible once they were hidden -- Key: WICKET-834 URL: https://issues.apache.org/jira/browse/WICKET-834 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta2, 1.3.0-beta3 Reporter: Carlos Pita Attachments: border.tgz The attached border shows/hides its content via an ajax event. Once the content has been hidden I get the following exception if re-showing it: WicketMessage: Exception in rendering component: [MarkupContainer [Component id = _body, page = com.livra.web.components.TestHideableBorderPage, path = 5:hideable:_body.Border$BorderBodyContainer, isVisible = true, isVersioned = true]] Root cause: java.lang.NullPointerException at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1366) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1315) at org.apache.wicket.markup.html.border.Border$BorderBodyContainer.onComponentTagBody(Border.java:347) at org.apache.wicket.Component.renderComponent(Component.java:2181) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1325) at org.apache.wicket.Component.render(Component.java:2005) at org.apache.wicket.Component.renderComponent(Component.java:2118) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:772) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:672) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:522) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1038) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
