[jira] [Updated] (WICKET-6666) Rewrite ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-: -- Component/s: ModalDialog > Rewrite ModalWindow > --- > > Key: WICKET- > URL: https://issues.apache.org/jira/browse/WICKET- > Project: Wicket > Issue Type: New Feature > Components: ModalDialog >Affects Versions: 9 >Reporter: Igor Vaynberg >Priority: Major > Labels: Modal, ModalWindow, modal, modalwindow > > This is a proposed rewrite of ModalWindow called ModalDialog we have been > using for a while with success. > > It doesnt have all the features of ModalWindow, but it is more modern in its > client side implementation and is ADA compliant. > > It still needs some polishing in terms of javadoc and examples -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WICKET-6666) Rewrite ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-: -- Affects Version/s: 9 > Rewrite ModalWindow > --- > > Key: WICKET- > URL: https://issues.apache.org/jira/browse/WICKET- > Project: Wicket > Issue Type: New Feature >Affects Versions: 9 >Reporter: Igor Vaynberg >Priority: Major > Labels: Modal, ModalWindow, modal, modalwindow > > This is a proposed rewrite of ModalWindow called ModalDialog we have been > using for a while with success. > > It doesnt have all the features of ModalWindow, but it is more modern in its > client side implementation and is ADA compliant. > > It still needs some polishing in terms of javadoc and examples -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WICKET-6666) Rewrite ModalWindow
Igor Vaynberg created WICKET-: - Summary: Rewrite ModalWindow Key: WICKET- URL: https://issues.apache.org/jira/browse/WICKET- Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg This is a proposed rewrite of ModalWindow called ModalDialog we have been using for a while with success. It doesnt have all the features of ModalWindow, but it is more modern in its client side implementation and is ADA compliant. It still needs some polishing in terms of javadoc and examples -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WICKET-6626) Introduce application-wide Component#onComponentTag listeners
[ https://issues.apache.org/jira/browse/WICKET-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-6626: -- Description: Such a listener will be useful for implementing application-wide styling as well as outputting debug information. see IOnComponentTagListener and Application#getOnComponentTagListeners() to get started. was:Such a listener will be useful for implementing application-wide styling as well as outputting debug information. > Introduce application-wide Component#onComponentTag listeners > - > > Key: WICKET-6626 > URL: https://issues.apache.org/jira/browse/WICKET-6626 > Project: Wicket > Issue Type: New Feature > Components: wicket >Reporter: Igor Vaynberg >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 8.3.0, 9.0.0, 7.12.0 > > > Such a listener will be useful for implementing application-wide styling as > well as outputting debug information. > > see IOnComponentTagListener and Application#getOnComponentTagListeners() to > get started. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (WICKET-6626) Introduce application-wide Component#onComponentTag listeners
[ https://issues.apache.org/jira/browse/WICKET-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-6626. --- Resolution: Fixed > Introduce application-wide Component#onComponentTag listeners > - > > Key: WICKET-6626 > URL: https://issues.apache.org/jira/browse/WICKET-6626 > Project: Wicket > Issue Type: New Feature > Components: wicket >Reporter: Igor Vaynberg >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 8.3.0, 9.0.0, 7.12.0 > > > Such a listener will be useful for implementing application-wide styling as > well as outputting debug information. > > see IOnComponentTagListener and Application#getOnComponentTagListeners() to > get started. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WICKET-6626) Introduce application-wide Component#onComponentTag listeners
Igor Vaynberg created WICKET-6626: - Summary: Introduce application-wide Component#onComponentTag listeners Key: WICKET-6626 URL: https://issues.apache.org/jira/browse/WICKET-6626 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Such a listener will be useful for implementing application-wide styling as well as outputting debug information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WICKET-6626) Introduce application-wide Component#onComponentTag listeners
[ https://issues.apache.org/jira/browse/WICKET-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-6626: -- Fix Version/s: 7.12.0 9.0.0 8.3.0 > Introduce application-wide Component#onComponentTag listeners > - > > Key: WICKET-6626 > URL: https://issues.apache.org/jira/browse/WICKET-6626 > Project: Wicket > Issue Type: New Feature > Components: wicket >Reporter: Igor Vaynberg >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 8.3.0, 9.0.0, 7.12.0 > > > Such a listener will be useful for implementing application-wide styling as > well as outputting debug information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (WICKET-6623) Consecutive Temporary Behaviors are not properly removed
[ https://issues.apache.org/jira/browse/WICKET-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-6623. --- Resolution: Fixed Fix Version/s: 9.0.0 8.3.0 7.11.0 > Consecutive Temporary Behaviors are not properly removed > > > Key: WICKET-6623 > URL: https://issues.apache.org/jira/browse/WICKET-6623 > Project: Wicket > Issue Type: Bug >Reporter: Igor Vaynberg >Assignee: Igor Vaynberg >Priority: Major > Fix For: 7.11.0, 8.3.0, 9.0.0 > > > If two temporary behaviors happen to be one after the other in component's > data the second one will not be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WICKET-6623) Consecutive Temporary Behaviors are not properly removed
Igor Vaynberg created WICKET-6623: - Summary: Consecutive Temporary Behaviors are not properly removed Key: WICKET-6623 URL: https://issues.apache.org/jira/browse/WICKET-6623 Project: Wicket Issue Type: Bug Reporter: Igor Vaynberg Assignee: Igor Vaynberg If two temporary behaviors happen to be one after the other in component's data the second one will not be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WICKET-6604) Ajax repaint is not correctly handled when component being repainted has an enclosure associated with it and is not a child of the enclosure
[
https://issues.apache.org/jira/browse/WICKET-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668883#comment-16668883
]
Igor Vaynberg commented on WICKET-6604:
---
forgot, its there now.
> Ajax repaint is not correctly handled when component being repainted has an
> enclosure associated with it and is not a child of the enclosure
>
>
> Key: WICKET-6604
> URL: https://issues.apache.org/jira/browse/WICKET-6604
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 7.10.0, 8.1.0
>Reporter: Igor Vaynberg
>Assignee: Igor Vaynberg
>Priority: Minor
> Labels: ajax
> Fix For: 7.11.0, 8.2.0
>
>
> When a component is repainted with ajax we first check if that component is a
> controlling component of the enclosure and if it is we repaint the enclosure
> instead of the component. However, we make the assumption that the
> controlling component of the enclosure is always contained within the
> enclosure, which may not always be true with inline enclosures.
> For example:
> {code:java}
> Name
> {code}
> In this case the inline enclosure will only encompass the label. So if we
> repaint the textfield by adding it to the ajax request handler we will get a
> strange result where any header contributions associated with the name
> component will get rendered, but the markup for the name component will not -
> because we make the assumption that since it is controlling an enclosure it
> is also inside it so there is no point in repainting it directly.
>
> One may argue that controlling components have to be inside the enclosure and
> we should throw an error if they are not, but I prefer this more flexible
> approach which allows the controller to be outside.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (WICKET-6604) Ajax repaint is not correctly handled when component being repainted has an enclosure associated with it and is not a child of the enclosure
[
https://issues.apache.org/jira/browse/WICKET-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-6604.
---
Resolution: Fixed
> Ajax repaint is not correctly handled when component being repainted has an
> enclosure associated with it and is not a child of the enclosure
>
>
> Key: WICKET-6604
> URL: https://issues.apache.org/jira/browse/WICKET-6604
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 7.10.0, 8.1.0
>Reporter: Igor Vaynberg
>Assignee: Igor Vaynberg
>Priority: Minor
> Labels: ajax
> Fix For: 7.11.0, 8.2.0
>
>
> When a component is repainted with ajax we first check if that component is a
> controlling component of the enclosure and if it is we repaint the enclosure
> instead of the component. However, we make the assumption that the
> controlling component of the enclosure is always contained within the
> enclosure, which may not always be true with inline enclosures.
> For example:
> {code:java}
> Name
> {code}
> In this case the inline enclosure will only encompass the label. So if we
> repaint the textfield by adding it to the ajax request handler we will get a
> strange result where any header contributions associated with the name
> component will get rendered, but the markup for the name component will not -
> because we make the assumption that since it is controlling an enclosure it
> is also inside it so there is no point in repainting it directly.
>
> One may argue that controlling components have to be inside the enclosure and
> we should throw an error if they are not, but I prefer this more flexible
> approach which allows the controller to be outside.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (WICKET-6604) Ajax repaint is not correctly handled when component being repainted has an enclosure associated with it and is not a child of the enclosure
[
https://issues.apache.org/jira/browse/WICKET-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-6604.
---
Resolution: Fixed
> Ajax repaint is not correctly handled when component being repainted has an
> enclosure associated with it and is not a child of the enclosure
>
>
> Key: WICKET-6604
> URL: https://issues.apache.org/jira/browse/WICKET-6604
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 7.10.0, 8.1.0
>Reporter: Igor Vaynberg
>Assignee: Igor Vaynberg
>Priority: Minor
> Labels: ajax
> Fix For: 7.11.0, 8.2.0
>
>
> When a component is repainted with ajax we first check if that component is a
> controlling component of the enclosure and if it is we repaint the enclosure
> instead of the component. However, we make the assumption that the
> controlling component of the enclosure is always contained within the
> enclosure, which may not always be true with inline enclosures.
> For example:
> {code:java}
> Name
> {code}
> In this case the inline enclosure will only encompass the label. So if we
> repaint the textfield by adding it to the ajax request handler we will get a
> strange result where any header contributions associated with the name
> component will get rendered, but the markup for the name component will not -
> because we make the assumption that since it is controlling an enclosure it
> is also inside it so there is no point in repainting it directly.
>
> One may argue that controlling components have to be inside the enclosure and
> we should throw an error if they are not, but I prefer this more flexible
> approach which allows the controller to be outside.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (WICKET-6604) Ajax repaint is not correctly handled when component being repainted has an enclosure associated with it and is not a child of the enclosure
Igor Vaynberg created WICKET-6604:
-
Summary: Ajax repaint is not correctly handled when component
being repainted has an enclosure associated with it and is not a child of the
enclosure
Key: WICKET-6604
URL: https://issues.apache.org/jira/browse/WICKET-6604
Project: Wicket
Issue Type: Bug
Affects Versions: 8.1.0, 7.10.0
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
Fix For: 7.11.0, 8.2.0
When a component is repainted with ajax we first check if that component is a
controlling component of the enclosure and if it is we repaint the enclosure
instead of the component. However, we make the assumption that the controlling
component of the enclosure is always contained within the enclosure, which may
not always be true with inline enclosures.
For example:
{code:java}
Name
{code}
In this case the inline enclosure will only encompass the label. So if we
repaint the textfield by adding it to the ajax request handler we will get a
strange result where any header contributions associated with the name
component will get rendered, but the markup for the name component will not -
because we make the assumption that since it is controlling an enclosure it is
also inside it so there is no point in repainting it directly.
One may argue that controlling components have to be inside the enclosure and
we should throw an error if they are not, but I prefer this more flexible
approach which allows the controller to be outside.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WICKET-5566) Catch-All FencedFeedbackPanel has lost message in case of message-level filter in nested FencedFeedbackPanel
[ https://issues.apache.org/jira/browse/WICKET-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976945#comment-13976945 ] Igor Vaynberg commented on WICKET-5566: --- indeed, this is as designed. messages do not make it past their fences, thats the whole idea. like [~mgrigorov] mentioned, you can create your own variant. the entire class is only about 30 lines of real code... Catch-All FencedFeedbackPanel has lost message in case of message-level filter in nested FencedFeedbackPanel -- Key: WICKET-5566 URL: https://issues.apache.org/jira/browse/WICKET-5566 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.14.0 Environment: Windows 2008 Server, Java 7u45 x64, Glassfish 3 Reporter: Alexander Morozov Assignee: Igor Vaynberg Attachments: myproject.zip We have almost successfully use FencedFeedbackPanel feedback, until we enable ErrorLevelFeedbackMessageFilter in nested FencedFeedbackPanels. Here is page structure: FencedFeedbackPanel (catch-all, fence=null) Panel1 (with form) FencedFeedbackPanel (fence=Panel1) + ErrorLevelFeedbackMessageFilter(accept ERROR level or higher) Panel2 (with form) FencedFeedbackPanel (fence=Panel2) + ErrorLevelFeedbackMessageFilter(accept ERROR level or higher) The issue: catch-all FencedFeedbackPanel doesn't show success messages, added by submit links in Panel1 or Panel2, hence messages had lost. Are there any solutions for the issue? See also http://apache-wicket.1842946.n4.nabble.com/quot-Catch-all-quot-FencedFeedbackPanel-and-message-level-filter-in-nested-FencedFeedbackPanel-td4665515.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (WICKET-3335) Component Queuing (extract hierarchy information from markup)
[ https://issues.apache.org/jira/browse/WICKET-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-3335. --- Resolution: Fixed Fix Version/s: 7.0.0 Component Queuing (extract hierarchy information from markup) - Key: WICKET-3335 URL: https://issues.apache.org/jira/browse/WICKET-3335 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Giannis Koutsoubos Assignee: Igor Vaynberg Fix For: 7.0.0 Attachments: 0001-component-queuing.patch, wicket-3335.patch Doubly defined hierarhices are redundant. Server-side hierarchy can be automatically deduced from markup hierarchy. Use queue method in MarkupContainer to add components and extract hierarchy information from markup. Discussed here: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705.html Implementation of queue method on branch 1.4.x : https://github.com/koutsoub/wicket/tree/component-queuing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (WICKET-3335) Component Queueing (extract hierarchy information from markup)
[ https://issues.apache.org/jira/browse/WICKET-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-3335: -- Summary: Component Queueing (extract hierarchy information from markup) (was: Component Queuing (extract hierarchy information from markup)) Component Queueing (extract hierarchy information from markup) -- Key: WICKET-3335 URL: https://issues.apache.org/jira/browse/WICKET-3335 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Giannis Koutsoubos Assignee: Igor Vaynberg Fix For: 7.0.0 Attachments: 0001-component-queuing.patch, wicket-3335.patch Doubly defined hierarhices are redundant. Server-side hierarchy can be automatically deduced from markup hierarchy. Use queue method in MarkupContainer to add components and extract hierarchy information from markup. Discussed here: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705.html Implementation of queue method on branch 1.4.x : https://github.com/koutsoub/wicket/tree/component-queuing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (WICKET-3335) Component Queueing (extract hierarchy information from markup)
[ https://issues.apache.org/jira/browse/WICKET-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13915347#comment-13915347 ] Igor Vaynberg commented on WICKET-3335: --- user description of the implementation: https://www.42lines.net/2014/02/28/component-queueing-in-wicket-7/ Component Queueing (extract hierarchy information from markup) -- Key: WICKET-3335 URL: https://issues.apache.org/jira/browse/WICKET-3335 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Giannis Koutsoubos Assignee: Igor Vaynberg Fix For: 7.0.0 Attachments: 0001-component-queuing.patch, wicket-3335.patch Doubly defined hierarhices are redundant. Server-side hierarchy can be automatically deduced from markup hierarchy. Use queue method in MarkupContainer to add components and extract hierarchy information from markup. Discussed here: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705.html Implementation of queue method on branch 1.4.x : https://github.com/koutsoub/wicket/tree/component-queuing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (WICKET-3335) Component Queuing (extract hierarchy information from markup)
[ https://issues.apache.org/jira/browse/WICKET-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896310#comment-13896310 ] Igor Vaynberg commented on WICKET-3335: --- new implementation in sandbox/component-queueing-2 Component Queuing (extract hierarchy information from markup) - Key: WICKET-3335 URL: https://issues.apache.org/jira/browse/WICKET-3335 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Giannis Koutsoubos Assignee: Igor Vaynberg Attachments: 0001-component-queuing.patch, wicket-3335.patch Doubly defined hierarhices are redundant. Server-side hierarchy can be automatically deduced from markup hierarchy. Use queue method in MarkupContainer to add components and extract hierarchy information from markup. Discussed here: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705.html Implementation of queue method on branch 1.4.x : https://github.com/koutsoub/wicket/tree/component-queuing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (WICKET-3335) Component Queuing (extract hierarchy information from markup)
[ https://issues.apache.org/jira/browse/WICKET-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896324#comment-13896324 ] Igor Vaynberg commented on WICKET-3335: --- http://markmail.org/message/jzotleixyjxhgn5m Component Queuing (extract hierarchy information from markup) - Key: WICKET-3335 URL: https://issues.apache.org/jira/browse/WICKET-3335 Project: Wicket Issue Type: New Feature Components: wicket Reporter: Giannis Koutsoubos Assignee: Igor Vaynberg Attachments: 0001-component-queuing.patch, wicket-3335.patch Doubly defined hierarhices are redundant. Server-side hierarchy can be automatically deduced from markup hierarchy. Use queue method in MarkupContainer to add components and extract hierarchy information from markup. Discussed here: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705.html Implementation of queue method on branch 1.4.x : https://github.com/koutsoub/wicket/tree/component-queuing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (WICKET-4062) Introduce wicket:link attribute in addition to wicket:link tag
[
https://issues.apache.org/jira/browse/WICKET-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-4062.
---
Resolution: Won't Fix
Introduce wicket:link attribute in addition to wicket:link tag
--
Key: WICKET-4062
URL: https://issues.apache.org/jira/browse/WICKET-4062
Project: Wicket
Issue Type: New Feature
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
Sometimes there are situations where having a more fine-grained control over
auto-linking is desired. for example (WICKET-3930)
{code}
wicket:link
a href=MyPage.htmlimg src=foo.jpg//a
/wicket:link
{code}
in this case wicket:link will rewrite both the href and src where only href
needs to be rewritten. if we had an attribute we can rewrite the above as
follows
{code}
a wicket:link href=MyPage.htmlimg src=foo.jpg//a
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (WICKET-3491) Introduce IComponentConfigurationListener
[ https://issues.apache.org/jira/browse/WICKET-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873530#comment-13873530 ] Igor Vaynberg commented on WICKET-3491: --- no, i did not have any strong opinions against this. should probably be IComponentOnConfigureListener though Introduce IComponentConfigurationListener - Key: WICKET-3491 URL: https://issues.apache.org/jira/browse/WICKET-3491 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.4.16, 1.5-RC2 Reporter: Sven Ludwig Labels: features, wicket Has it been considered to also add IComponentConfigurationListener in the wake of WICKET-2955 onConfigure? Such a listener would allow for a minimally-invasive, save, global hiding of Components of any determinable category. If the listener is introduced, a decision needs to be made whether or not to support pre- and post-semantics in the Application, as they are supported with the IComponentOnBeforeRenderListener. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (WICKET-5462) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton
[ https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5462: -- Summary: Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton (was: Automatic form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton --- Key: WICKET-5462 URL: https://issues.apache.org/jira/browse/WICKET-5462 Project: Wicket Issue Type: Bug Reporter: Igor Vaynberg Assignee: Igor Vaynberg -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (WICKET-5462) Automatic form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton
Igor Vaynberg created WICKET-5462: - Summary: Automatic form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton Key: WICKET-5462 URL: https://issues.apache.org/jira/browse/WICKET-5462 Project: Wicket Issue Type: Bug Reporter: Igor Vaynberg Assignee: Igor Vaynberg -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (WICKET-5462) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton
[ https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5462. --- Resolution: Fixed Fix Version/s: 7.0.0 6.13.0 Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton --- Key: WICKET-5462 URL: https://issues.apache.org/jira/browse/WICKET-5462 Project: Wicket Issue Type: Bug Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (WICKET-5462) Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton
[ https://issues.apache.org/jira/browse/WICKET-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5462: -- Fix Version/s: (was: 6.13.0) 6.14.0 Ajax form-component-label repainting fails when setResponsePage() is used to navigate away from the page that has previously failed form validaiton --- Key: WICKET-5462 URL: https://issues.apache.org/jira/browse/WICKET-5462 Project: Wicket Issue Type: Bug Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.14.0, 7.0.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (WICKET-663) enhance ichoicerenderer with id-choice object lookup
[ https://issues.apache.org/jira/browse/WICKET-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853007#comment-13853007 ] Igor Vaynberg commented on WICKET-663: -- looks good. the only other thing i would consider is nuking the interface, there is no real point to having it... enhance ichoicerenderer with id-choice object lookup - Key: WICKET-663 URL: https://issues.apache.org/jira/browse/WICKET-663 Project: Wicket Issue Type: Improvement Affects Versions: 1.3.0-final Reporter: Igor Vaynberg Assignee: Igor Vaynberg add object idtochoice(string id) to ichoicerenderer and add class choicerenderer implements ichoicerenderer that encapsulate the default linear search then we can remove method added in WICKET-348 to support a custom lookup -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (WICKET-663) enhance ichoicerenderer with id-choice object lookup
[ https://issues.apache.org/jira/browse/WICKET-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13851877#comment-13851877 ] Igor Vaynberg commented on WICKET-663: -- something to look into in wicket 7 enhance ichoicerenderer with id-choice object lookup - Key: WICKET-663 URL: https://issues.apache.org/jira/browse/WICKET-663 Project: Wicket Issue Type: Improvement Affects Versions: 1.3.0-final Reporter: Igor Vaynberg Assignee: Igor Vaynberg add object idtochoice(string id) to ichoicerenderer and add class choicerenderer implements ichoicerenderer that encapsulate the default linear search then we can remove method added in WICKET-348 to support a custom lookup -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (WICKET-663) enhance ichoicerenderer with id-choice object lookup
[
https://issues.apache.org/jira/browse/WICKET-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13852122#comment-13852122
]
Igor Vaynberg commented on WICKET-663:
--
the way this works currently is:
lets say i pick a choice rendered as 17. when we need to resolve this back
from the client string to the object we load up all the choices, go through
them one by one, render the id using the renderer, and look for the match.
this is ok for most cases, but when you have multiple filters on the page each
with 200ish choices this may get slow because not only are you doing a linear
search across all options, you are also loading all options from the database
or other potentially slow storages.
the idea behind this ticket is to make that reverse lookup (17-object)
configurable. for large dropdowns a good optimization can be to simply cast
17 to 17 and load the object with that id from the database.
there are two places for this kind of lookup: a method on the component and a
method in the renderer.
imho the better place is the renderer because that is the more likely place for
specializations to occur and since renderer is the thing that transcodes an
object into a string representation it makes it logical that it handles the
inverse. for example we have an EntityChoiceRenderer that knows how to pull the
database id out of entities; it makes it a logical place to override the
lookup. so we would have an EntityChoiceRenderer that knows how to deal with
entities in a more complete way: encode them into html and decode them
efficiently.
this would change the renderer from an interface into an abstract class, thus
wicket 7.0, so it can provide the default linear lookup. maybe {code}T
getObject(String value, IModelListT choices){code}. im not sure if the
component instance would be useful in the method signature, my feeling that
most likely not really and if its needed the user can pass it in manually.
enhance ichoicerenderer with id-choice object lookup
-
Key: WICKET-663
URL: https://issues.apache.org/jira/browse/WICKET-663
Project: Wicket
Issue Type: Improvement
Affects Versions: 1.3.0-final
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
add object idtochoice(string id) to ichoicerenderer and add class
choicerenderer implements ichoicerenderer that encapsulate the default linear
search
then we can remove method added in WICKET-348 to support a custom lookup
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page
[ https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844409#comment-13844409 ] Igor Vaynberg commented on WICKET-5224: --- looks like this issue is back :/ ModalWindow is not visible in Safari when opened from a link at the bottom of a large page -- Key: WICKET-5224 URL: https://issues.apache.org/jira/browse/WICKET-5224 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.8.0 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3) Reporter: Jered Myers Assignee: Igor Vaynberg Fix For: 6.10.0, 7.0.0 Attachments: safariscroll.zip Original Estimate: 1h Remaining Estimate: 1h I am not able to see a ModalWindow in Safari and I expect to see it centered on my view port. Steps: 1. Start with a large web page with a link to open the ModalWindow at the bottom of the page. You need a large page where you have to scroll down to find the link. 2. Click the link 3. Observe that the mask for the ModalWindow displays, but the ModalWindow does not. Scrolling back up, re-sizing, and maximizing will still not display the ModalWindow. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Reopened] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page
[ https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reopened WICKET-5224: --- ModalWindow is not visible in Safari when opened from a link at the bottom of a large page -- Key: WICKET-5224 URL: https://issues.apache.org/jira/browse/WICKET-5224 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.8.0 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3) Reporter: Jered Myers Assignee: Igor Vaynberg Fix For: 6.10.0, 7.0.0 Attachments: safariscroll.zip Original Estimate: 1h Remaining Estimate: 1h I am not able to see a ModalWindow in Safari and I expect to see it centered on my view port. Steps: 1. Start with a large web page with a link to open the ModalWindow at the bottom of the page. You need a large page where you have to scroll down to find the link. 2. Click the link 3. Observe that the mask for the ModalWindow displays, but the ModalWindow does not. Scrolling back up, re-sizing, and maximizing will still not display the ModalWindow. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page
[ https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5224: -- Fix Version/s: (was: 6.10.0) 6.13.0 ModalWindow is not visible in Safari when opened from a link at the bottom of a large page -- Key: WICKET-5224 URL: https://issues.apache.org/jira/browse/WICKET-5224 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.8.0 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3) Reporter: Jered Myers Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 Attachments: safariscroll.zip Original Estimate: 1h Remaining Estimate: 1h I am not able to see a ModalWindow in Safari and I expect to see it centered on my view port. Steps: 1. Start with a large web page with a link to open the ModalWindow at the bottom of the page. You need a large page where you have to scroll down to find the link. 2. Click the link 3. Observe that the mask for the ModalWindow displays, but the ModalWindow does not. Scrolling back up, re-sizing, and maximizing will still not display the ModalWindow. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page
[ https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844420#comment-13844420 ] Igor Vaynberg commented on WICKET-5224: --- reverted the revert, seems to have fixed it. ModalWindow is not visible in Safari when opened from a link at the bottom of a large page -- Key: WICKET-5224 URL: https://issues.apache.org/jira/browse/WICKET-5224 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.8.0 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3) Reporter: Jered Myers Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 Attachments: safariscroll.zip Original Estimate: 1h Remaining Estimate: 1h I am not able to see a ModalWindow in Safari and I expect to see it centered on my view port. Steps: 1. Start with a large web page with a link to open the ModalWindow at the bottom of the page. You need a large page where you have to scroll down to find the link. 2. Click the link 3. Observe that the mask for the ModalWindow displays, but the ModalWindow does not. Scrolling back up, re-sizing, and maximizing will still not display the ModalWindow. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page
[ https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5224. --- Resolution: Fixed ModalWindow is not visible in Safari when opened from a link at the bottom of a large page -- Key: WICKET-5224 URL: https://issues.apache.org/jira/browse/WICKET-5224 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.8.0 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3) Reporter: Jered Myers Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 Attachments: safariscroll.zip Original Estimate: 1h Remaining Estimate: 1h I am not able to see a ModalWindow in Safari and I expect to see it centered on my view port. Steps: 1. Start with a large web page with a link to open the ModalWindow at the bottom of the page. You need a large page where you have to scroll down to find the link. 2. Click the link 3. Observe that the mask for the ModalWindow displays, but the ModalWindow does not. Scrolling back up, re-sizing, and maximizing will still not display the ModalWindow. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5411. --- Resolution: Fixed Improve AutoLabels by updating their CSS classes automatically during Ajax requests --- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13 (to enable override WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (WICKET-5417) this.replaceWith is broken when called from onInitialize
[
https://issues.apache.org/jira/browse/WICKET-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823752#comment-13823752
]
Igor Vaynberg commented on WICKET-5417:
---
whats the usecase for component replacing itself during oninitialize()? it
doesnt seem valid to me...
this.replaceWith is broken when called from onInitialize
Key: WICKET-5417
URL: https://issues.apache.org/jira/browse/WICKET-5417
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 6.12.0
Reporter: Ryan Dearing
Assignee: Martin Grigorov
Attachments: WICKET-5417.patch, replacewithbug.tgz
When calling this.replaceWith within the onInitialize method, wicket throws
an exception:
Last cause: org.apache.wicket.Component has not been properly initialized.
Something in the hierarchy of com.mycompany.PanelA has not called
super.onInitialize() in the override of onInitialize() method
This happens because detach is called on the panel being replaced which
clears Component.request flags (sets to 0) which causes the exception on line
864 of Component.java:
if (!getRequestFlag(RFLAG_INITIALIZE_SUPER_CALL_VERIFIED)) {
// throws here
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Reopened] (WICKET-5418) PropertyValidator ignoring groups with the @NotNull annotation only
[ https://issues.apache.org/jira/browse/WICKET-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reopened WICKET-5418: --- PropertyValidator ignoring groups with the @NotNull annotation only --- Key: WICKET-5418 URL: https://issues.apache.org/jira/browse/WICKET-5418 Project: Wicket Issue Type: Bug Components: wicket-bean-validation Affects Versions: 6.12.0 Environment: MacOSX, Glassfish Reporter: Jesus Mireles Assignee: Igor Vaynberg Labels: validation Attachments: BeanValidation.zip When using groups in your JSR303 compliant classes, Wicket does not honor the groups for the @NotNull annotation. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (WICKET-5418) PropertyValidator ignoring groups with the @NotNull annotation only
[ https://issues.apache.org/jira/browse/WICKET-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5418. --- Resolution: Fixed Fix Version/s: 7.0.0 6.13.0 PropertyValidator ignoring groups with the @NotNull annotation only --- Key: WICKET-5418 URL: https://issues.apache.org/jira/browse/WICKET-5418 Project: Wicket Issue Type: Bug Components: wicket-bean-validation Affects Versions: 6.12.0 Environment: MacOSX, Glassfish Reporter: Jesus Mireles Assignee: Igor Vaynberg Labels: validation Fix For: 6.13.0, 7.0.0 Attachments: BeanValidation.zip When using groups in your JSR303 compliant classes, Wicket does not honor the groups for the @NotNull annotation. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820226#comment-13820226 ] Igor Vaynberg commented on WICKET-5411: --- i wasnt going to close it until i tested it in our app to make sure it works for complex usecases... Improve AutoLabels by updating their CSS classes automatically during Ajax requests --- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13 (to enable override WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5411. --- Resolution: Fixed Improve AutoLabels by updating their CSS classes automatically during Ajax requests --- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13 (to enable override WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (WICKET-5410) Remove setting interfaces
Igor Vaynberg created WICKET-5410: - Summary: Remove setting interfaces Key: WICKET-5410 URL: https://issues.apache.org/jira/browse/WICKET-5410 Project: Wicket Issue Type: Improvement Reporter: Igor Vaynberg Fix For: 7.0.0 We still have separate settings interfaces. mostly this is a legacy design decision when we have a single settings object implement all these interfaces. the problem now that we are in semver is that we cannot add new settings in between major releases because doing so requires adding a method to an interface. since we do not have a single class implementing multiple interfaces scenario anymore we can get rid of the settings interfaces safely. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (WICKET-5411) Improve AutoLabels to update their CSS dynamically
Igor Vaynberg created WICKET-5411: - Summary: Improve AutoLabels to update their CSS dynamically Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 7.0.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (WICKET-5411) Improve AutoLabels to update their CSS dynamically
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5411: -- Fix Version/s: 6.13.0 Improve AutoLabels to update their CSS dynamically -- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (WICKET-5411) Improve AutoLabels to update their CSS dynamically
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5411: -- Description: The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. Improve AutoLabels to update their CSS dynamically -- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5411: -- Summary: Improve AutoLabels by updating their CSS classes automatically during Ajax requests (was: Improve AutoLabels to update their CSS dynamically) Improve AutoLabels by updating their CSS classes automatically during Ajax requests --- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13, always enabled in 7.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (WICKET-5411) Improve AutoLabels to update their CSS dynamically
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5411: -- Description: The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13, always enabled in 7.0 was: The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. Improve AutoLabels to update their CSS dynamically -- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13, always enabled in 7.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (WICKET-5411) Improve AutoLabels by updating their CSS classes automatically during Ajax requests
[ https://issues.apache.org/jira/browse/WICKET-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5411: -- Description: The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13 (to enable override WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0 was: The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13, always enabled in 7.0 Improve AutoLabels by updating their CSS classes automatically during Ajax requests --- Key: WICKET-5411 URL: https://issues.apache.org/jira/browse/WICKET-5411 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.13.0, 7.0.0 The problem with auto labels is that once they are rendered the only way to update their `error`/`required` css classes during ajax requests is to update some parent since auto components cannot be targeted directly. however, when dealing with forms we may not necessarily want to repaint components because we may lose state. This issue solves the problem by tracking state changes in form components that have auto labels and updating their css classes on all ajax requests. disabled by default in 6.13 (to enable override WebApplication#getUpdateAutoLabelsOnAjaxRequests() ), always enabled in 7.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (WICKET-5297) Animate ajax DOM manipulation smoothly
[
https://issues.apache.org/jira/browse/WICKET-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798774#comment-13798774
]
Igor Vaynberg commented on WICKET-5297:
---
what we need to do is bake this into core, the idea is that we can specify a
javascript function that handles component replacement when we add it to the
target. this function has a callback that when called performs the replacement.
so the default impl of this function is to just call the callback immediately -
which is a noop. the animation then can look like this:
function animateComponent(tag, replaceInDom) {
var t=$(#+tag);
t.fadeOut({complete: function() { replaceInDom(); t.fadeIn(); }});
}
then we can run all prepended-javascript
run all replacements asynchronously
wait for them all to finish
run all header contributions
run all appended-javascript
the downside is that its possible the flicker of markup that needs to be
enhanced will be longer because it wont happen until the last animation. to
solve this we can track which header contribution comes with which component,
and run it after the component animated.
in fact, we can have variants of append and prepend javascript that are also
tied to component which can become part of its async pipeline...
Animate ajax DOM manipulation smoothly
--
Key: WICKET-5297
URL: https://issues.apache.org/jira/browse/WICKET-5297
Project: Wicket
Issue Type: Improvement
Reporter: Antti Lankila
Assignee: Martin Grigorov
Priority: Minor
Labels: ajax
Attachments: wicket6-replace-with-effect.tgz,
wicket6-replace-with-effect.tgz, wicket6-replace-with-effect.tgz
Wicket should have an easy hands-off way to animate most changes which occur
when ajax requests get new HTML data to visualize in the markup. For
instance, the content within the element (if any) could fade or shrink away,
and new content would replace it, taking its place.
The animations should be as minimal as possible, but noticeable enough that
the user can see them occurring. I'd suggest at least two types of
animations: fade-ins and resizes.
- In fade animation, the old panel would have its opacity decrease until it
becomes invisible, and the new content would then take its place. In case the
old panel was just a placeholder, only the fade-in of the new content occurs.
This type of animation would be suitable for alert box like elements which
occur in the middle of the screen or otherwise are detached from the page
flow.
- In resize animation, JavaScript code should measure the dimensions of the
old panel (about to go away) and the new panel (about to replace it). During
animation, the old panel would be kept in its place, but its dimensions would
be adjusted from the old values to the new values through manipulating its
width and height using linear interpolation, and then an instantenous switch
would replace the old content with the new content when the new dimensions
have been reached. If the old panel was just a placeholder, the animation
would resize the content of the new panel instead. This type of animation
would be most suitable for elements in the page flow.
User should be able to control the duration and type of the animation, and
whether animation is applied by default via settings. In addition to that,
the animation parameters should be controllable per ajax request.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page
[ https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13721527#comment-13721527 ] Igor Vaynberg commented on WICKET-5224: --- confirmed, safari mustve changed its behavior between than and now ModalWindow is not visible in Safari when opened from a link at the bottom of a large page -- Key: WICKET-5224 URL: https://issues.apache.org/jira/browse/WICKET-5224 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.8.0 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3) Reporter: Jered Myers Assignee: Igor Vaynberg Attachments: safariscroll.zip Original Estimate: 1h Remaining Estimate: 1h I am not able to see a ModalWindow in Safari and I expect to see it centered on my view port. Steps: 1. Start with a large web page with a link to open the ModalWindow at the bottom of the page. You need a large page where you have to scroll down to find the link. 2. Click the link 3. Observe that the mask for the ModalWindow displays, but the ModalWindow does not. Scrolling back up, re-sizing, and maximizing will still not display the ModalWindow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5224) ModalWindow is not visible in Safari when opened from a link at the bottom of a large page
[ https://issues.apache.org/jira/browse/WICKET-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5224. --- Resolution: Fixed Fix Version/s: 6.10.0 7.0.0 ModalWindow is not visible in Safari when opened from a link at the bottom of a large page -- Key: WICKET-5224 URL: https://issues.apache.org/jira/browse/WICKET-5224 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.8.0 Environment: Safari 5.1.7 (7534.57.2) Windows, Safari (iOS 6.1.3) Reporter: Jered Myers Assignee: Igor Vaynberg Fix For: 7.0.0, 6.10.0 Attachments: safariscroll.zip Original Estimate: 1h Remaining Estimate: 1h I am not able to see a ModalWindow in Safari and I expect to see it centered on my view port. Steps: 1. Start with a large web page with a link to open the ModalWindow at the bottom of the page. You need a large page where you have to scroll down to find the link. 2. Click the link 3. Observe that the mask for the ModalWindow displays, but the ModalWindow does not. Scrolling back up, re-sizing, and maximizing will still not display the ModalWindow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697857#comment-13697857 ] Igor Vaynberg commented on WICKET-5261: --- a workaround is to create a @conversational serializable holder for your non-serializable beans and inject them into it. then these beans will be available for as long as you keep the conversation alive. notice that this is a bit of a hack - passivating scope like conversational requires all beans inside be serializable. but, if you do not replicate your conversation across the cluster you are ok. if that doesnt work for you, you can store them in some other custom in-memory store. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5262) Lifecycle of CDI object bound to wicket Page
[ https://issues.apache.org/jira/browse/WICKET-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5262. --- Resolution: Invalid Lifecycle of CDI object bound to wicket Page Key: WICKET-5262 URL: https://issues.apache.org/jira/browse/WICKET-5262 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg The wicket-cdi module injects object only on IBehaviorInstantiationListener.onInstantiation and IComponentInstantiationListener.onInstantiation. After this injection pass wicket-cdi does not manage the injected objects anymore. It relies on the normal wicket state management. So the lifecycle of any injected object is bound to the page (even if this page is serialized and the stored instance is no longer a cdi object). I think only the cdi implementation should manage these object. As a consequence wicket-cdi should inject object before every request is processed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5262) Lifecycle of CDI object bound to wicket Page
[ https://issues.apache.org/jira/browse/WICKET-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697858#comment-13697858 ] Igor Vaynberg commented on WICKET-5262: --- the wicket-cdi module does not inject anything, the injection is handled by the cdi container itself. dependent-scoped beans are not proxied. Lifecycle of CDI object bound to wicket Page Key: WICKET-5262 URL: https://issues.apache.org/jira/browse/WICKET-5262 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg The wicket-cdi module injects object only on IBehaviorInstantiationListener.onInstantiation and IComponentInstantiationListener.onInstantiation. After this injection pass wicket-cdi does not manage the injected objects anymore. It relies on the normal wicket state management. So the lifecycle of any injected object is bound to the page (even if this page is serialized and the stored instance is no longer a cdi object). I think only the cdi implementation should manage these object. As a consequence wicket-cdi should inject object before every request is processed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5261. --- Resolution: Invalid After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697851#comment-13697851 ] Igor Vaynberg commented on WICKET-5261: --- i dont think there is a good place in javadoc for something like this. devs have to know how serialization works and that if they make the field transient it will be null on deserialization. this is hardly cdi-specific. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697893#comment-13697893 ] Igor Vaynberg commented on WICKET-5261: --- i resolved this because i consider this issue invalid. Any CDI container handle these passivations. So wicket-cdi should handle this too. wicket-cdi is not a container, it is an integration with one. so, if the container handles it it should already work for you. Any CDI container handle these passivations. incorrect. like ive mentioned before, passivating scopes require that all beans inside them be serializable. @Depedent is not a passivating scope. you are declaring the injection point as *transient*, so you have to deal with serialization. @Dependent beans are generally used in use cases where instance matters, after all, if it didnt the bean could live in a higher scope - this is why they are injected without a proxy. what you are doing by re-injecting on de-serialization is creating a new instance of the @Dependent object - not preserving the state of the previous instance - which to me and most devs would be a very surprising behavior because @Dependent lifecycle should be tied to the page. the solution you implemented works more like @RequestScoped in the sense that at every request you get a new instance. you are welcome to describe your use case on the @dev in more detail, this is not the right place. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5262) Lifecycle of CDI object bound to wicket Page
[ https://issues.apache.org/jira/browse/WICKET-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697899#comment-13697899 ] Igor Vaynberg commented on WICKET-5262: --- but wicket-cdi calls the BeanManager and not the container. beanmanager is the interface to the container. So wicket-cdi must handle the lifecycle of its Components and Behaviors. Not the container. we do. we make sure all such artifacts are injected. once injected, however, the scoping is handled by the container via the use of proxies. this is why cdi containers inject proxies in the first place. if you are marking your fields as serializable, it should be your job to manage them. Lifecycle of CDI object bound to wicket Page Key: WICKET-5262 URL: https://issues.apache.org/jira/browse/WICKET-5262 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg The wicket-cdi module injects object only on IBehaviorInstantiationListener.onInstantiation and IComponentInstantiationListener.onInstantiation. After this injection pass wicket-cdi does not manage the injected objects anymore. It relies on the normal wicket state management. So the lifecycle of any injected object is bound to the page (even if this page is serialized and the stored instance is no longer a cdi object). I think only the cdi implementation should manage these object. As a consequence wicket-cdi should inject object before every request is processed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (WICKET-5262) Lifecycle of CDI object bound to wicket Page
[ https://issues.apache.org/jira/browse/WICKET-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697899#comment-13697899 ] Igor Vaynberg edited comment on WICKET-5262 at 7/2/13 3:49 PM: --- but wicket-cdi calls the BeanManager and not the container. beanmanager is the interface to the container. So wicket-cdi must handle the lifecycle of its Components and Behaviors. Not the container. we do. we make sure all such artifacts are injected. once injected, however, the scoping is handled by the container via the use of proxies. this is why cdi containers inject proxies in the first place. if you are marking your fields as transient, it should be your job to manage them. was (Author: ivaynberg): but wicket-cdi calls the BeanManager and not the container. beanmanager is the interface to the container. So wicket-cdi must handle the lifecycle of its Components and Behaviors. Not the container. we do. we make sure all such artifacts are injected. once injected, however, the scoping is handled by the container via the use of proxies. this is why cdi containers inject proxies in the first place. if you are marking your fields as serializable, it should be your job to manage them. Lifecycle of CDI object bound to wicket Page Key: WICKET-5262 URL: https://issues.apache.org/jira/browse/WICKET-5262 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg The wicket-cdi module injects object only on IBehaviorInstantiationListener.onInstantiation and IComponentInstantiationListener.onInstantiation. After this injection pass wicket-cdi does not manage the injected objects anymore. It relies on the normal wicket state management. So the lifecycle of any injected object is bound to the page (even if this page is serialized and the stored instance is no longer a cdi object). I think only the cdi implementation should manage these object. As a consequence wicket-cdi should inject object before every request is processed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4951) Wicket-cdi and OpenWebBeans 1.1.x incompatibility
[ https://issues.apache.org/jira/browse/WICKET-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13690376#comment-13690376 ] Igor Vaynberg commented on WICKET-4951: --- [~jsarman] i dont think that is exactly correct. cdi-1.1 automatically starts a conversation around each servlet request, so wicket doesnt need to do that. however, the propagation wont work automatically. for example you first hit a page, its rendered in conversation A. when you click a link on that page it will execute in a conversation, but that conversation may not be A. wicket's propagation makes sure that a page has a consistent long running conversation if one is requested. Wicket-cdi and OpenWebBeans 1.1.x incompatibility - Key: WICKET-4951 URL: https://issues.apache.org/jira/browse/WICKET-4951 Project: Wicket Issue Type: Wish Components: wicket-cdi Affects Versions: 6.3.0, 6.4.0 Environment: OpenWebBeans 1.1.x (TomEE 1.5.1) Reporter: Dominik Drzewiecki Assignee: Igor Vaynberg Priority: Minor It is not particularly Wicket-CDI fault to not support the latest OpenWebBeans, but rather seam-conversation-owb-3.0.0.Final, thus this issue is reported as a wish. Seam-conversation-owb-3.0.0 depends on ancient OpenWebBeans version, although I've seen some activity in its git repositories (https://github.com/seam/conversation/commit/a5f2e3f42829f8405e6bee6caab43fd034e5be81) and 3.2.0 Snapshots deployed to jboss maven repo (https://repository.jboss.org/nexus/content/groups/public/org/jboss/seam/conversation/seam-conversation-owb/3.2.0-SNAPSHOT/) seem to depend on OWB 1.1.3. It seems that ConversationManager.getInstance() is no longer there which results in the following stacktrace when run on tomee 1.5.1 or tomcat + OWB 1.1.7: SEVERE: Servlet.service() for servlet [default] in context with path [/wcjs-web] threw exception [Filter execution threw an exception] with root cause java.lang.NoSuchMethodError: org.apache.webbeans.conversation.ConversationManager.getInstance()Lorg/apache/webbeans/conversation/ConversationManager; at org.jboss.seam.conversation.plugins.openwebbeans.OpenWebBeansSeamConversationManager.doActivate(OpenWebBeansSeamConversationManager.java:41) at org.jboss.seam.conversation.plugins.openwebbeans.OpenWebBeansHttpSeamConversationContext.doActivate(OpenWebBeansHttpSeamConversationContext.java:44) at org.jboss.seam.conversation.api.AbstractSeamConversationContext.activate(AbstractSeamConversationContext.java:54) at org.apache.wicket.cdi.CdiContainer.activateConversationalContext(CdiContainer.java:94) at org.apache.wicket.cdi.ConversationPropagator.activateConversationIfNeeded(ConversationPropagator.java:147) at org.apache.wicket.cdi.ConversationPropagator.onRequestHandlerResolved(ConversationPropagator.java:123) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:253) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:211) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:282) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:244) at
[jira] [Resolved] (WICKET-4952) Wicket-CDI and o.a.w.Session.replaceSession() do not play nice.
[ https://issues.apache.org/jira/browse/WICKET-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-4952. --- Resolution: Won't Fix this can be implemented by creating a custom scope anchored to wicket's Session instance. pull requests/patches welcome. Wicket-CDI and o.a.w.Session.replaceSession() do not play nice. --- Key: WICKET-4952 URL: https://issues.apache.org/jira/browse/WICKET-4952 Project: Wicket Issue Type: Improvement Components: wicket-cdi Affects Versions: 6.3.0, 6.4.0 Reporter: Dominik Drzewiecki Assignee: Igor Vaynberg As CDI session-scoped beans are bound to the session, invoking o.a.w.Session.replaceSession() results in destoroying HttpSession and all bound beans. Maybe we could provide some hack to workaround this so that the beans wo't get flushed and be rebound to the newly created HttPSession? It is an evident servlet APIs shortcoming; it definitely lacks some more standard replaceSession() in its API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5178) StopPropagation functionality on link is broken
[
https://issues.apache.org/jira/browse/WICKET-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13652000#comment-13652000
]
Igor Vaynberg commented on WICKET-5178:
---
on a side note please rename StopPropagation to Propagation {BUBBLE, STOP,
STOP_IMMEDIATELY}. reading StopPropagation.NO makes my head assplode :)
StopPropagation functionality on link is broken
---
Key: WICKET-5178
URL: https://issues.apache.org/jira/browse/WICKET-5178
Project: Wicket
Issue Type: Bug
Affects Versions: 6.7.0
Reporter: Marieke Vandamme
Assignee: Martin Grigorov
Fix For: 6.8.0
Attachments: myproject.zip
In the quickstart I'll add the following is illustrated:
- simple table with AjaxLink on tr
- on that tr there's another AjaxLink with should not propagate the onclick
to the tr
- So when clicking the here link, on the server logging only the following
should appear:
* onclick LNK
but also the logging from the tr link is printed:
* onclick LNK
* onclick TR
In wicket 6.6 this works.
Thanks in advance ! Kind regards, Marieke
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-4951) Wicket-cdi and OpenWebBeans 1.1.x incompatibility
[ https://issues.apache.org/jira/browse/WICKET-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reassigned WICKET-4951: - Assignee: Igor Vaynberg Wicket-cdi and OpenWebBeans 1.1.x incompatibility - Key: WICKET-4951 URL: https://issues.apache.org/jira/browse/WICKET-4951 Project: Wicket Issue Type: Wish Components: wicket-cdi Affects Versions: 6.3.0, 6.4.0 Environment: OpenWebBeans 1.1.x (TomEE 1.5.1) Reporter: Dominik Drzewiecki Assignee: Igor Vaynberg Priority: Minor It is not particularly Wicket-CDI fault to not support the latest OpenWebBeans, but rather seam-conversation-owb-3.0.0.Final, thus this issue is reported as a wish. Seam-conversation-owb-3.0.0 depends on ancient OpenWebBeans version, although I've seen some activity in its git repositories (https://github.com/seam/conversation/commit/a5f2e3f42829f8405e6bee6caab43fd034e5be81) and 3.2.0 Snapshots deployed to jboss maven repo (https://repository.jboss.org/nexus/content/groups/public/org/jboss/seam/conversation/seam-conversation-owb/3.2.0-SNAPSHOT/) seem to depend on OWB 1.1.3. It seems that ConversationManager.getInstance() is no longer there which results in the following stacktrace when run on tomee 1.5.1 or tomcat + OWB 1.1.7: SEVERE: Servlet.service() for servlet [default] in context with path [/wcjs-web] threw exception [Filter execution threw an exception] with root cause java.lang.NoSuchMethodError: org.apache.webbeans.conversation.ConversationManager.getInstance()Lorg/apache/webbeans/conversation/ConversationManager; at org.jboss.seam.conversation.plugins.openwebbeans.OpenWebBeansSeamConversationManager.doActivate(OpenWebBeansSeamConversationManager.java:41) at org.jboss.seam.conversation.plugins.openwebbeans.OpenWebBeansHttpSeamConversationContext.doActivate(OpenWebBeansHttpSeamConversationContext.java:44) at org.jboss.seam.conversation.api.AbstractSeamConversationContext.activate(AbstractSeamConversationContext.java:54) at org.apache.wicket.cdi.CdiContainer.activateConversationalContext(CdiContainer.java:94) at org.apache.wicket.cdi.ConversationPropagator.activateConversationIfNeeded(ConversationPropagator.java:147) at org.apache.wicket.cdi.ConversationPropagator.onRequestHandlerResolved(ConversationPropagator.java:123) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:253) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:211) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:282) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:244) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:267) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at
[jira] [Commented] (WICKET-4951) Wicket-cdi and OpenWebBeans 1.1.x incompatibility
[ https://issues.apache.org/jira/browse/WICKET-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13651046#comment-13651046 ] Igor Vaynberg commented on WICKET-4951: --- cdi 1.1 provides a standardized api for managing the conversational context. we will have a new wicket-cdi-1.1 module which will utilize this standard api. Wicket-cdi and OpenWebBeans 1.1.x incompatibility - Key: WICKET-4951 URL: https://issues.apache.org/jira/browse/WICKET-4951 Project: Wicket Issue Type: Wish Components: wicket-cdi Affects Versions: 6.3.0, 6.4.0 Environment: OpenWebBeans 1.1.x (TomEE 1.5.1) Reporter: Dominik Drzewiecki Assignee: Igor Vaynberg Priority: Minor It is not particularly Wicket-CDI fault to not support the latest OpenWebBeans, but rather seam-conversation-owb-3.0.0.Final, thus this issue is reported as a wish. Seam-conversation-owb-3.0.0 depends on ancient OpenWebBeans version, although I've seen some activity in its git repositories (https://github.com/seam/conversation/commit/a5f2e3f42829f8405e6bee6caab43fd034e5be81) and 3.2.0 Snapshots deployed to jboss maven repo (https://repository.jboss.org/nexus/content/groups/public/org/jboss/seam/conversation/seam-conversation-owb/3.2.0-SNAPSHOT/) seem to depend on OWB 1.1.3. It seems that ConversationManager.getInstance() is no longer there which results in the following stacktrace when run on tomee 1.5.1 or tomcat + OWB 1.1.7: SEVERE: Servlet.service() for servlet [default] in context with path [/wcjs-web] threw exception [Filter execution threw an exception] with root cause java.lang.NoSuchMethodError: org.apache.webbeans.conversation.ConversationManager.getInstance()Lorg/apache/webbeans/conversation/ConversationManager; at org.jboss.seam.conversation.plugins.openwebbeans.OpenWebBeansSeamConversationManager.doActivate(OpenWebBeansSeamConversationManager.java:41) at org.jboss.seam.conversation.plugins.openwebbeans.OpenWebBeansHttpSeamConversationContext.doActivate(OpenWebBeansHttpSeamConversationContext.java:44) at org.jboss.seam.conversation.api.AbstractSeamConversationContext.activate(AbstractSeamConversationContext.java:54) at org.apache.wicket.cdi.CdiContainer.activateConversationalContext(CdiContainer.java:94) at org.apache.wicket.cdi.ConversationPropagator.activateConversationIfNeeded(ConversationPropagator.java:147) at org.apache.wicket.cdi.ConversationPropagator.onRequestHandlerResolved(ConversationPropagator.java:123) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:155) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$5.notify(RequestCycleListenerCollection.java:151) at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onRequestHandlerResolved(RequestCycleListenerCollection.java:150) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:253) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:211) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:282) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:244) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:267) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at
[jira] [Resolved] (WICKET-5144) CDI demo throws an exception when running examples with 'mvn jetty:run'
[ https://issues.apache.org/jira/browse/WICKET-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5144. --- Resolution: Won't Fix this is just weld trying to hook into jetty to allow injection inside servlet artifacts such as servlets and filters, but we are using a jetty version it doesnt support. non fatal. CDI demo throws an exception when running examples with 'mvn jetty:run' --- Key: WICKET-5144 URL: https://issues.apache.org/jira/browse/WICKET-5144 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.7.0 Reporter: Martin Grigorov Assignee: Igor Vaynberg Priority: Minor Testing Wicket 6.7.0 I've noticed the following exception when starting the examples with 'mvn jetty:run': java.lang.IllegalArgumentException: Cannot load class for org.jboss.weld.environment.jetty.WeldDecorator at org.jboss.weld.environment.servlet.util.Reflections.classForName(Reflections.java:58) at org.jboss.weld.environment.jetty.JettyPost72Container.initialize(JettyPost72Container.java:66) at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:162) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:733) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:233) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1222) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:676) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:455) at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:256) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:224) at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:167) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:224) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:90) at org.eclipse.jetty.server.Server.doStart(Server.java:260) at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:511) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:364) at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:516) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at
[jira] [Created] (WICKET-5138) Wicket does not correctly handle http OPTIONS requests
Igor Vaynberg created WICKET-5138: - Summary: Wicket does not correctly handle http OPTIONS requests Key: WICKET-5138 URL: https://issues.apache.org/jira/browse/WICKET-5138 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 currently these requests cause regular processing (page rendering), when in fact they should have a special response. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-5138) Wicket does not correctly handle http OPTIONS requests
[ https://issues.apache.org/jira/browse/WICKET-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-5138: -- Description: currently these requests cause regular processing (page rendering), when in fact they should have a special response. rendering the page in OPTIONS causes renderCount to be incremented and this messes with the subsequent request to the same url via a GET or POST was:currently these requests cause regular processing (page rendering), when in fact they should have a special response. Wicket does not correctly handle http OPTIONS requests -- Key: WICKET-5138 URL: https://issues.apache.org/jira/browse/WICKET-5138 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 currently these requests cause regular processing (page rendering), when in fact they should have a special response. rendering the page in OPTIONS causes renderCount to be incremented and this messes with the subsequent request to the same url via a GET or POST -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5138) Wicket does not correctly handle http OPTIONS requests
[ https://issues.apache.org/jira/browse/WICKET-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5138. --- Resolution: Fixed Wicket does not correctly handle http OPTIONS requests -- Key: WICKET-5138 URL: https://issues.apache.org/jira/browse/WICKET-5138 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 currently these requests cause regular processing (page rendering), when in fact they should have a special response. rendering the page in OPTIONS causes renderCount to be incremented and this messes with the subsequent request to the same url via a GET or POST -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5127) Dont use sun-internal packages to allow easy jdk7 compilation
[ https://issues.apache.org/jira/browse/WICKET-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5127. --- Resolution: Fixed Fix Version/s: 6.7.0 Assignee: Igor Vaynberg Dont use sun-internal packages to allow easy jdk7 compilation - Key: WICKET-5127 URL: https://issues.apache.org/jira/browse/WICKET-5127 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 6.7.0 Reporter: Martin Dilger Assignee: Igor Vaynberg Priority: Minor Fix For: 6.7.0 Attachments: 0001-Dont-use-sun-internal-packages-as-this-breaks-compil.patch Hi Devs, I´m not able to compile the wicket-sources on my notebook, no matter what I try. I try to compile with JDK7, that always worked but now some Problems seem to arise. In the new JsonSequenceStringer-Class we make use of the sun internal: com.sun.istack.internal.Nullable; I dont think its a very good idea to use sun internal classes here, even if jdk6 is the target of the current source base, we should allow jdk7 to compile it. Thats not possible at the moment. The attached patch just removes this usage. We wont lose much here. Or am I missing something important? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-5126) SecurePackageResourceGuard is blocking access to web fonts
Igor Vaynberg created WICKET-5126: - Summary: SecurePackageResourceGuard is blocking access to web fonts Key: WICKET-5126 URL: https://issues.apache.org/jira/browse/WICKET-5126 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5126) SecurePackageResourceGuard is blocking access to web fonts
[ https://issues.apache.org/jira/browse/WICKET-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5126. --- Resolution: Fixed SecurePackageResourceGuard is blocking access to web fonts -- Key: WICKET-5126 URL: https://issues.apache.org/jira/browse/WICKET-5126 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-5124) Improve ResourceReference#getDependencies() API
Igor Vaynberg created WICKET-5124:
-
Summary: Improve ResourceReference#getDependencies() API
Key: WICKET-5124
URL: https://issues.apache.org/jira/browse/WICKET-5124
Project: Wicket
Issue Type: Improvement
Affects Versions: 6.6.0
Reporter: Igor Vaynberg
Assignee: Igor Vaynberg
Fix For: 7.0
currently the signature is
public Iterable? extends HeaderItem getDependencies()
which is awkward to use.
suppose i want a javascript reference that should include a css reference as a
dependency, i cannot simply add it to iterable like this:
new ResourceReference(Some.class, some.js) {
Iterable getDependencies() {
Iterable supers=super.getDependencies();
// supers.add(CSS); === cannot do this, instead
List list=new ArrayList();
for (reference:supers) {
list.add(reference);
}
// now i can finally add mine
list.add(CSS);
return list;
}
}
instead change Iterable to a List that is backed by a mutable one. this should
make extending much easier. if List is too open create Appendable { append();
} backed by a list and use that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-5117) Wicket ignores allowDefault:false attribute in multipart ajax requests
Igor Vaynberg created WICKET-5117: - Summary: Wicket ignores allowDefault:false attribute in multipart ajax requests Key: WICKET-5117 URL: https://issues.apache.org/jira/browse/WICKET-5117 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5117) Wicket ignores allowDefault:false attribute in multipart ajax requests
[ https://issues.apache.org/jira/browse/WICKET-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5117. --- Resolution: Fixed Wicket ignores allowDefault:false attribute in multipart ajax requests -- Key: WICKET-5117 URL: https://issues.apache.org/jira/browse/WICKET-5117 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5098) PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars
[ https://issues.apache.org/jira/browse/WICKET-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13612706#comment-13612706 ] Igor Vaynberg commented on WICKET-5098: --- what does such a path look like? i dont have windows so im fixing this somewhat in the dark... PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars --- Key: WICKET-5098 URL: https://issues.apache.org/jira/browse/WICKET-5098 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Environment: Windows 7 Reporter: Jenny Brown Assignee: Igor Vaynberg Fix For: 6.7.0 Attachments: packageResourceGuardPatch.txt PackageResourceGuard.acceptAbsolutePath() uses '/' instead of File.separator when manipulating absolute file paths. This causes problems on MS-Windows when trying to parse C:\com\mycompany\ resulting in exceptions when trying to load javascript etc files that are not in a jar. The problem shows up for resources accessed via FileResourceStream, but not UrlResourceStream. org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: Access denied to (static) package resource com/mycompany/components/behavior/TinyMceBehavior.js. See IPackageResourceGuard at org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:460) at org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:395) at org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:223) at org.apache.wicket.request.resource.caching.version.RequestCycleCachedResourceVersion.getVersion(RequestCycleCachedResourceVersion.java:81) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5098) PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars
[ https://issues.apache.org/jira/browse/WICKET-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5098. --- Resolution: Fixed PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars --- Key: WICKET-5098 URL: https://issues.apache.org/jira/browse/WICKET-5098 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Environment: Windows 7 Reporter: Jenny Brown Assignee: Igor Vaynberg Fix For: 6.7.0 Attachments: packageResourceGuardPatch.txt PackageResourceGuard.acceptAbsolutePath() uses '/' instead of File.separator when manipulating absolute file paths. This causes problems on MS-Windows when trying to parse C:\com\mycompany\ resulting in exceptions when trying to load javascript etc files that are not in a jar. The problem shows up for resources accessed via FileResourceStream, but not UrlResourceStream. org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: Access denied to (static) package resource com/mycompany/components/behavior/TinyMceBehavior.js. See IPackageResourceGuard at org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:460) at org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:395) at org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:223) at org.apache.wicket.request.resource.caching.version.RequestCycleCachedResourceVersion.getVersion(RequestCycleCachedResourceVersion.java:81) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5098) PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars
[ https://issues.apache.org/jira/browse/WICKET-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13612726#comment-13612726 ] Igor Vaynberg commented on WICKET-5098: --- thats not a usual path on windows since it uses a linux style file separator instead of windows :) i believe i got it fixed, test it and reopen if its still broken. PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars --- Key: WICKET-5098 URL: https://issues.apache.org/jira/browse/WICKET-5098 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Environment: Windows 7 Reporter: Jenny Brown Assignee: Igor Vaynberg Fix For: 6.7.0 Attachments: packageResourceGuardPatch.txt PackageResourceGuard.acceptAbsolutePath() uses '/' instead of File.separator when manipulating absolute file paths. This causes problems on MS-Windows when trying to parse C:\com\mycompany\ resulting in exceptions when trying to load javascript etc files that are not in a jar. The problem shows up for resources accessed via FileResourceStream, but not UrlResourceStream. org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: Access denied to (static) package resource com/mycompany/components/behavior/TinyMceBehavior.js. See IPackageResourceGuard at org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:460) at org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:395) at org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:223) at org.apache.wicket.request.resource.caching.version.RequestCycleCachedResourceVersion.getVersion(RequestCycleCachedResourceVersion.java:81) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5108) AbstractPropertyModel does not detach possible model nested inside property path (maybe latest version also?)
[
https://issues.apache.org/jira/browse/WICKET-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609088#comment-13609088
]
Igor Vaynberg commented on WICKET-5108:
---
a couple of comments on the description:
which is not IDetachable because it holds on to multiple models
the above doesnt make sense, if something is a container for models then it
needs to be detachable. for example AbstractPropertyModel is detachable because
it holds on to a model. IColumn and IDataProvider are detachable because they
may hold model references in their implementations. this is how wicket was
designed
and would not make sense to detach all at same time.
actually it does. model detaching happens during the detach phase - during
which all models are detached. so all models are detached at the same time.
as far as criticism of the patch - other then what Sven has already pointed out
and with which i agree completely as stated above - i do not like the fact that
AbstractPropertyModel now has two new fields - that is two new memory slots and
since AbstractPropertyModel is one of the most used types this will cause a
nasty size increase in pages. so the question is: is this feature worth the
memory and session size hit? in my opinion no.
It contains nested models, a single entrypoint ,detach does not know what to
do adequately, we need to detach leaf models not root node.
detach coded by the developer is the only thing that knows how to do something
properly. here is a simple example:
{code}
class BeanWithModels {
IModel user;
IModel enrollments
getName() { return user.getObject().getFirstName()+
+user.getObject().getLastName()+ (+enrollments.getObject().size()+); }
}
new PropertyModel(beanWithModels, name)
{code}
in the case above, which is common at least in our application, with your patch
the internal models are still not detached because they are never directly
referenced by the property expression.
so your patch only works sometimes for only certain situations. lets reconsider
the memory/session size hit again with that in mind.
maintenance hell: user must remember to update all detach references when
something changes
write a utility method that uses reflection to walk fields and detach them. you
can then implement something like this to make things easier
{code}
abstract class ModelContainer implements IDetachable {
detach() { ModelUtils.detachFields(this); }
}
{code}
AbstractPropertyModel does not detach possible model nested inside property
path (maybe latest version also?)
-
Key: WICKET-5108
URL: https://issues.apache.org/jira/browse/WICKET-5108
Project: Wicket
Issue Type: Bug
Affects Versions: 1.4.21
Reporter: Martin Makundi
Attachments: patch-optimized.txt
Original Estimate: 2h
Remaining Estimate: 2h
AbstractPropertyModel does not detach possible model nested inside property
path if target object is not IDetachable itself.
For example:
new PropertyModel(pojoMultipleModelBean, detachableParticularProperty)
Now AbstractPropertyModel will investigate target pojoModelBean which is not
IDetachable because it holds on to multiple models and would not make sense
to detach all at same time.
Fix proposal is that AbstractPropertyModel detach investigates in addition
the whole path to the property model whether there are detachable models, and
detaches them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5100) Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks
[ https://issues.apache.org/jira/browse/WICKET-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609697#comment-13609697 ] Igor Vaynberg commented on WICKET-5100: --- shouldnt your noncontextualmanager mock or special test impl inject DetachEventEmitter? if it doesnt handle these cases then nothing in wicket will work... Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks Key: WICKET-5100 URL: https://issues.apache.org/jira/browse/WICKET-5100 Project: Wicket Issue Type: Wish Components: wicket-cdi Reporter: Daniel Zwicker Assignee: Igor Vaynberg We are using mockito for out unit tests. Mockito has introduced @InjectMocks for injections mocks in CDI-Beans. I have tried to setup the wicket-cdi to use the 'mockito-injection' but ended up with copy the classes to rewrite just some lines. (just replace the INonContextualManager and omit the BeanManager). Perhaps the cdi-module can be refactored to use some kind of factory to replace the INonContextualManager. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5108) AbstractPropertyModel does not detach possible model nested inside property path (maybe latest version also?)
[ https://issues.apache.org/jira/browse/WICKET-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609831#comment-13609831 ] Igor Vaynberg commented on WICKET-5108: --- but there is no way you can convince me that more (hard)code is better than less. where did i say that? i gave you a solution (using reflection) that lets you write code that will work for all use cases. Keep it simple. your code is very far from simple because it will work only for certain use cases and leave users baffled as to why it doesnt work in such common cases as i have provided in my original response. simple is only good if it works consistently and predictably. The only way I could agree with is to make a separate xxPropertyModel extends PropertyModel that will act this way and that would possibly allow some parametrization in addition to default behavior. great idea. you can keep this model in your code base and make it work exactly how you need it to. however, until there is a general solution that works predictably i do not think we will add it to core, feel free to open a new issue if you implement something general; i am going to close this for now. AbstractPropertyModel does not detach possible model nested inside property path (maybe latest version also?) - Key: WICKET-5108 URL: https://issues.apache.org/jira/browse/WICKET-5108 Project: Wicket Issue Type: Bug Affects Versions: 1.4.21 Reporter: Martin Makundi Attachments: patch-optimized.txt Original Estimate: 2h Remaining Estimate: 2h AbstractPropertyModel does not detach possible model nested inside property path if target object is not IDetachable itself. For example: new PropertyModel(pojoMultipleModelBean, detachableParticularProperty) Now AbstractPropertyModel will investigate target pojoModelBean which is not IDetachable because it holds on to multiple models and would not make sense to detach all at same time. Fix proposal is that AbstractPropertyModel detach investigates in addition the whole path to the property model whether there are detachable models, and detaches them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (WICKET-5108) AbstractPropertyModel does not detach possible model nested inside property path (maybe latest version also?)
[ https://issues.apache.org/jira/browse/WICKET-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg closed WICKET-5108. - Resolution: Won't Fix Assignee: Igor Vaynberg AbstractPropertyModel does not detach possible model nested inside property path (maybe latest version also?) - Key: WICKET-5108 URL: https://issues.apache.org/jira/browse/WICKET-5108 Project: Wicket Issue Type: Bug Affects Versions: 1.4.21 Reporter: Martin Makundi Assignee: Igor Vaynberg Attachments: patch-optimized.txt Original Estimate: 2h Remaining Estimate: 2h AbstractPropertyModel does not detach possible model nested inside property path if target object is not IDetachable itself. For example: new PropertyModel(pojoMultipleModelBean, detachableParticularProperty) Now AbstractPropertyModel will investigate target pojoModelBean which is not IDetachable because it holds on to multiple models and would not make sense to detach all at same time. Fix proposal is that AbstractPropertyModel detach investigates in addition the whole path to the property model whether there are detachable models, and detaches them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5108) AbstractPropertyModel does not detach possible model nested inside property path (maybe latest version also?)
[ https://issues.apache.org/jira/browse/WICKET-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13609869#comment-13609869 ] Igor Vaynberg commented on WICKET-5108: --- i did not ask you to add more code every time you add a property model. currently your TakpSessionprovider.get() returns some object that has references to models, correct? such objects would simply have to extend my proposed ModelContainer class. the ModelContainer will implement IDetachable and correctly delegate to inner models. what you are proposing adds a significant amount of overhead and does not work for all cases, thus it does not belong in core. you are more then welcome to start a vote on the dev list, but i am pretty sure people there will back me up because you are not using the framework in the way it was intended to be used. you are trying to fit a square peg in a round hole just because all you have in your app are square pegs. once you have a solution that also works automatically for the common use case i specified in my reply i will be more then happy to listen. AbstractPropertyModel does not detach possible model nested inside property path (maybe latest version also?) - Key: WICKET-5108 URL: https://issues.apache.org/jira/browse/WICKET-5108 Project: Wicket Issue Type: Bug Affects Versions: 1.4.21 Reporter: Martin Makundi Assignee: Igor Vaynberg Attachments: patch-optimized.txt Original Estimate: 2h Remaining Estimate: 2h AbstractPropertyModel does not detach possible model nested inside property path if target object is not IDetachable itself. For example: new PropertyModel(pojoMultipleModelBean, detachableParticularProperty) Now AbstractPropertyModel will investigate target pojoModelBean which is not IDetachable because it holds on to multiple models and would not make sense to detach all at same time. Fix proposal is that AbstractPropertyModel detach investigates in addition the whole path to the property model whether there are detachable models, and detaches them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-5102) wicket-bean-validation: Bean validation PropertyValidator only works with direct field access
[ https://issues.apache.org/jira/browse/WICKET-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reassigned WICKET-5102: - Assignee: Igor Vaynberg wicket-bean-validation: Bean validation PropertyValidator only works with direct field access - Key: WICKET-5102 URL: https://issues.apache.org/jira/browse/WICKET-5102 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Reporter: Pekka Lund Assignee: Igor Vaynberg There's a substring indexing bug in the wicket-bean-validation module in org.apache.wicket.bean.validation.DefaultPropertyResolver that causes it to only work with direct field access and fail when field is missing and getter method should be used. The problem is on this line: String name = getter.getName().substring(3, 1).toLowerCase() + getter.getName().substring(4); Which should be: String name = getter.getName().substring(3, 4).toLowerCase() + getter.getName().substring(4); (or simply a single character access) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5102) wicket-bean-validation: Bean validation PropertyValidator only works with direct field access
[ https://issues.apache.org/jira/browse/WICKET-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5102. --- Resolution: Fixed Fix Version/s: 6.7.0 wicket-bean-validation: Bean validation PropertyValidator only works with direct field access - Key: WICKET-5102 URL: https://issues.apache.org/jira/browse/WICKET-5102 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Reporter: Pekka Lund Assignee: Igor Vaynberg Fix For: 6.7.0 There's a substring indexing bug in the wicket-bean-validation module in org.apache.wicket.bean.validation.DefaultPropertyResolver that causes it to only work with direct field access and fail when field is missing and getter method should be used. The problem is on this line: String name = getter.getName().substring(3, 1).toLowerCase() + getter.getName().substring(4); Which should be: String name = getter.getName().substring(3, 4).toLowerCase() + getter.getName().substring(4); (or simply a single character access) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (WICKET-5100) Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks
[ https://issues.apache.org/jira/browse/WICKET-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg closed WICKET-5100. - Resolution: Invalid Assignee: Igor Vaynberg see CdiConfiguraiton.setNonContextualManager() Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks Key: WICKET-5100 URL: https://issues.apache.org/jira/browse/WICKET-5100 Project: Wicket Issue Type: Wish Components: wicket-cdi Reporter: Daniel Zwicker Assignee: Igor Vaynberg We are using mockito for out unit tests. Mockito has introduced @InjectMocks for injections mocks in CDI-Beans. I have tried to setup the wicket-cdi to use the 'mockito-injection' but ended up with copy the classes to rewrite just some lines. (just replace the INonContextualManager and omit the BeanManager). Perhaps the cdi-module can be refactored to use some kind of factory to replace the INonContextualManager. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (WICKET-5098) PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars
[ https://issues.apache.org/jira/browse/WICKET-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reassigned WICKET-5098: - Assignee: Igor Vaynberg PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars --- Key: WICKET-5098 URL: https://issues.apache.org/jira/browse/WICKET-5098 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Environment: Windows 7 Reporter: Jenny Brown Assignee: Igor Vaynberg Attachments: packageResourceGuardPatch.txt PackageResourceGuard.acceptAbsolutePath() uses '/' instead of File.separator when manipulating absolute file paths. This causes problems on MS-Windows when trying to parse C:\com\mycompany\ resulting in exceptions when trying to load javascript etc files that are not in a jar. The problem shows up for resources accessed via FileResourceStream, but not UrlResourceStream. org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: Access denied to (static) package resource com/mycompany/components/behavior/TinyMceBehavior.js. See IPackageResourceGuard at org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:460) at org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:395) at org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:223) at org.apache.wicket.request.resource.caching.version.RequestCycleCachedResourceVersion.getVersion(RequestCycleCachedResourceVersion.java:81) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5098) PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars
[ https://issues.apache.org/jira/browse/WICKET-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5098. --- Resolution: Fixed Fix Version/s: 6.7.0 PackageResourceBlockedException under Windows for *.js files in web app's own packages, not in jars --- Key: WICKET-5098 URL: https://issues.apache.org/jira/browse/WICKET-5098 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Environment: Windows 7 Reporter: Jenny Brown Assignee: Igor Vaynberg Fix For: 6.7.0 Attachments: packageResourceGuardPatch.txt PackageResourceGuard.acceptAbsolutePath() uses '/' instead of File.separator when manipulating absolute file paths. This causes problems on MS-Windows when trying to parse C:\com\mycompany\ resulting in exceptions when trying to load javascript etc files that are not in a jar. The problem shows up for resources accessed via FileResourceStream, but not UrlResourceStream. org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: Access denied to (static) package resource com/mycompany/components/behavior/TinyMceBehavior.js. See IPackageResourceGuard at org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:460) at org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:395) at org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:223) at org.apache.wicket.request.resource.caching.version.RequestCycleCachedResourceVersion.getVersion(RequestCycleCachedResourceVersion.java:81) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5087) Make it easier to request (ajax)behaviors by name from JavaScript
[
https://issues.apache.org/jira/browse/WICKET-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13599087#comment-13599087
]
Igor Vaynberg commented on WICKET-5087:
---
@martin the functionality is available, but the big difference is that you are
allowing the user to break encapsulation where as existing functionality does
not. the current functionality encapsulates the generation of the callback url
- ensuring that it is unique.
let me clarify - the convenience you are adding is a simple way to reference
wicket components from javascript without having to dynamically write out a
part of that js - namely the callback url. correct?
lets take the concrete usecase of making a stateless select2 component. using
your code the component author would add the behavior, override getShortUrl()
and set it to something like select2-data, then use that to create a
callback. what about the component user though? they add the component,
override the method to feed it data, all is good. what happens when they add
another one though? now both components are fixed to the same url and one of
them will get incorrect data. so the component author now has to make the short
url available as a constructor arg - and it is on the component user to make
sure these tokens are unique. but, at this point, since the short url has to be
configurable, writing out javascript needs to be done in a dynamic way to plug
in the url - so we are back to square one - the only difference is who controls
the url - the user in the java code or the framework. at this point i think the
convenience is lost since i cannot have static javascript, i have to write it
out using a texttemplate...
Make it easier to request (ajax)behaviors by name from JavaScript
-
Key: WICKET-5087
URL: https://issues.apache.org/jira/browse/WICKET-5087
Project: Wicket
Issue Type: New Feature
Components: wicket
Affects Versions: 6.6.0
Reporter: Martin Grigorov
Assignee: Martin Grigorov
Attachments: WICKET-5087.patch, wicket-ajax-shorturl.tgz
Many JavaScript libraries require server endpoint for making requests for
loading/saving data.
To integrate such JS library with Wicket the application developer should
make the IRequestListener's url available as an endpoint. That is it need to
store somewhere the url produced by #urlFor() or
AjaxBehavior#getCallbackUrl().
This new feature will make this much simpler for the application developer.
A new method will be added to Wicket.Ajax namespace to facilitate this:
Wicket.Ajax.short({
'su': 'countries',
'dep': [function() {return [{'name': 'extra', 'value': 'param'}]}],
'coh': [function() {console.log('Completed!')}]
});
This new method will again receive an object with all possible attributes
plus a new one - 'su', stands for 'short/stable/simple' url.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5087) Make it easier to request (ajax)behaviors by name from JavaScript
[
https://issues.apache.org/jira/browse/WICKET-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598023#comment-13598023
]
Igor Vaynberg commented on WICKET-5087:
---
this seriously breaks encapsulation, which imho is a huge problem for a
framework like wicket.
Make it easier to request (ajax)behaviors by name from JavaScript
-
Key: WICKET-5087
URL: https://issues.apache.org/jira/browse/WICKET-5087
Project: Wicket
Issue Type: New Feature
Components: wicket
Affects Versions: 6.6.0
Reporter: Martin Grigorov
Assignee: Martin Grigorov
Attachments: WICKET-5087.patch, wicket-ajax-shorturl.tgz
Many JavaScript libraries require server endpoint for making requests for
loading/saving data.
To integrate such JS library with Wicket the application developer should
make the IRequestListener's url available as an endpoint. That is it need to
store somewhere the url produced by #urlFor() or
AjaxBehavior#getCallbackUrl().
This new feature will make this much simpler for the application developer.
A new method will be added to Wicket.Ajax namespace to facilitate this:
Wicket.Ajax.short({
'su': 'countries',
'dep': [function() {return [{'name': 'extra', 'value': 'param'}]}],
'coh': [function() {console.log('Completed!')}]
});
This new method will again receive an object with all possible attributes
plus a new one - 'su', stands for 'short/stable/simple' url.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-5075) When modal window is closed page scrolls to top
Igor Vaynberg created WICKET-5075: - Summary: When modal window is closed page scrolls to top Key: WICKET-5075 URL: https://issues.apache.org/jira/browse/WICKET-5075 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 the current function passed to onCloseButton() does not abort the current event, which navigates to # since that is whats in the href of the link, which in turn scrolls the page to the top. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-5075) When modal window is closed page scrolls to top
[ https://issues.apache.org/jira/browse/WICKET-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-5075. --- Resolution: Fixed When modal window is closed page scrolls to top --- Key: WICKET-5075 URL: https://issues.apache.org/jira/browse/WICKET-5075 Project: Wicket Issue Type: Bug Affects Versions: 6.6.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.7.0 the current function passed to onCloseButton() does not abort the current event, which navigates to # since that is whats in the href of the link, which in turn scrolls the page to the top. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-4948) Modal window does not center correctly when window is scrolled in safari
Igor Vaynberg created WICKET-4948: - Summary: Modal window does not center correctly when window is scrolled in safari Key: WICKET-4948 URL: https://issues.apache.org/jira/browse/WICKET-4948 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 6.4.0, 1.5.9 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 1.5.10, 6.5.0 in safari window.scrollTop is not taken into account when opening the window so when the window is scrolled the modal opens above the viewport and requires scrolling up to access -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4948) Modal window does not center correctly when window is scrolled in safari
[ https://issues.apache.org/jira/browse/WICKET-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-4948. --- Resolution: Fixed Modal window does not center correctly when window is scrolled in safari Key: WICKET-4948 URL: https://issues.apache.org/jira/browse/WICKET-4948 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.5.9, 6.4.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 1.5.10, 6.5.0 in safari window.scrollTop is not taken into account when opening the window so when the window is scrolled the modal opens above the viewport and requires scrolling up to access -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4888) Introduce a hierarchical feedback panel (FencedFeedbackPanel)
[ https://issues.apache.org/jira/browse/WICKET-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-4888: -- Summary: Introduce a hierarchical feedback panel (FencedFeedbackPanel) (was: Introduce a hierarchical feedback panel) Introduce a hierarchical feedback panel (FencedFeedbackPanel) - Key: WICKET-4888 URL: https://issues.apache.org/jira/browse/WICKET-4888 Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4888) Introduce a hierarchical feedback panel (FencedFeedbackPanel)
[ https://issues.apache.org/jira/browse/WICKET-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-4888: -- Description: often it is useful to have feedback panels that only display messages coming from a certain container. there are two problems with using a simple ContainerFeedbackFilter: * it does not support nesting. if two panels using the filter are nested and an inner component reports a message it will be shown in both inner and outer feedback panels - duplicating the message * there is no easy way to have a top level panel that only shows messages that will not be shown in any other panel Introduce a hierarchical feedback panel (FencedFeedbackPanel) - Key: WICKET-4888 URL: https://issues.apache.org/jira/browse/WICKET-4888 Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg often it is useful to have feedback panels that only display messages coming from a certain container. there are two problems with using a simple ContainerFeedbackFilter: * it does not support nesting. if two panels using the filter are nested and an inner component reports a message it will be shown in both inner and outer feedback panels - duplicating the message * there is no easy way to have a top level panel that only shows messages that will not be shown in any other panel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4888) Introduce a hierarchical feedback panel (FencedFeedbackPanel)
[ https://issues.apache.org/jira/browse/WICKET-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503623#comment-13503623 ] Igor Vaynberg commented on WICKET-4888: --- introduced FencedFeedbackPanel that solves this usecase. Introduce a hierarchical feedback panel (FencedFeedbackPanel) - Key: WICKET-4888 URL: https://issues.apache.org/jira/browse/WICKET-4888 Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg often it is useful to have feedback panels that only display messages coming from a certain container. there are two problems with using a simple ContainerFeedbackFilter: * it does not support nesting. if two panels using the filter are nested and an inner component reports a message it will be shown in both inner and outer feedback panels - duplicating the message * there is no easy way to have a top level panel that only shows messages that will not be shown in any other panel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4888) Introduce a hierarchical feedback panel (FencedFeedbackPanel)
[ https://issues.apache.org/jira/browse/WICKET-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-4888. --- Resolution: Fixed Fix Version/s: 6.4.0 Assignee: Igor Vaynberg Introduce a hierarchical feedback panel (FencedFeedbackPanel) - Key: WICKET-4888 URL: https://issues.apache.org/jira/browse/WICKET-4888 Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.4.0 often it is useful to have feedback panels that only display messages coming from a certain container. there are two problems with using a simple ContainerFeedbackFilter: * it does not support nesting. if two panels using the filter are nested and an inner component reports a message it will be shown in both inner and outer feedback panels - duplicating the message * there is no easy way to have a top level panel that only shows messages that will not be shown in any other panel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4883) Out of the box bean-validation (JSR 303) integration
[ https://issues.apache.org/jira/browse/WICKET-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-4883: -- Summary: Out of the box bean-validation (JSR 303) integration (was: Provide bean-validation framework integration) Out of the box bean-validation (JSR 303) integration Key: WICKET-4883 URL: https://issues.apache.org/jira/browse/WICKET-4883 Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.4.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-4883) Provide bean-validation framework integration
Igor Vaynberg created WICKET-4883: - Summary: Provide bean-validation framework integration Key: WICKET-4883 URL: https://issues.apache.org/jira/browse/WICKET-4883 Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.4.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4883) Out of the box bean-validation (JSR 303) integration
[ https://issues.apache.org/jira/browse/WICKET-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-4883. --- Resolution: Fixed currently in the experimental modules Out of the box bean-validation (JSR 303) integration Key: WICKET-4883 URL: https://issues.apache.org/jira/browse/WICKET-4883 Project: Wicket Issue Type: New Feature Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.4.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-4757) FormComponents remain invalid forever if there is no feedback panel
Igor Vaynberg created WICKET-4757: - Summary: FormComponents remain invalid forever if there is no feedback panel Key: WICKET-4757 URL: https://issues.apache.org/jira/browse/WICKET-4757 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.0.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.1.0 if there is no feedback panel the error messages are not removed in ondetach and form component re-validation is skipped so the form component, once marked as invalid, will remain invalid forever or at least until its error messages are rendered. the error messages should be dropped and the form component should be re-validated on every form submit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4757) FormComponents remain invalid forever if there is no feedback panel
[ https://issues.apache.org/jira/browse/WICKET-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-4757. --- Resolution: Fixed FormComponents remain invalid forever if there is no feedback panel --- Key: WICKET-4757 URL: https://issues.apache.org/jira/browse/WICKET-4757 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.0.0 Reporter: Igor Vaynberg Assignee: Igor Vaynberg Fix For: 6.1.0 if there is no feedback panel the error messages are not removed in ondetach and form component re-validation is skipped so the form component, once marked as invalid, will remain invalid forever or at least until its error messages are rendered. the error messages should be dropped and the form component should be re-validated on every form submit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
