[jira] Commented: (WICKET-1297) PasswordTextField.onComponentTag helpful if not final
[ https://issues.apache.org/jira/browse/WICKET-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560996#action_12560996 ] Sam Hough commented on WICKET-1297: --- Weakens my case, based on consistency, but ListChoice.onComponentTag is marked final which I'd also prefer not to be. > PasswordTextField.onComponentTag helpful if not final > - > > Key: WICKET-1297 > URL: https://issues.apache.org/jira/browse/WICKET-1297 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-final >Reporter: Sam Hough > > PasswordTextField.onComponentTag is final, unlike the other form components > I've seen, which removes a good hook for adding different behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1297) PasswordTextField.onComponentTag helpful if not final
PasswordTextField.onComponentTag helpful if not final - Key: WICKET-1297 URL: https://issues.apache.org/jira/browse/WICKET-1297 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-final Reporter: Sam Hough PasswordTextField.onComponentTag is final, unlike the other form components I've seen, which removes a good hook for adding different behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1044) Clarification of when children are added to Component tree for TabbedPanel
Clarification of when children are added to Component tree for TabbedPanel -- Key: WICKET-1044 URL: https://issues.apache.org/jira/browse/WICKET-1044 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3 Reporter: Sam Hough TabbedPanel only adds the components in a tab to the primary component tree in onBeforeRender. This caught me out so maybe a note in the javadoc would help other users? I was expecting MarkupContainer.visitChildren to visit at least the active tab's components (not sure I had thought past that). Does any other component hold a private tree of components rather than attached to the primary tree? Maybe using setVisible would be less surprising to developers or would that have nasty performance implications? Thanks Sam -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-845) Label constructor
[ https://issues.apache.org/jira/browse/WICKET-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532056 ] Sam Hough commented on WICKET-845: -- Seems handy for optimisation. Quite often the caller will be using a StringBuilder and might make sense not to create a new String object until/if needed. Maybe just add a constructor that take CharSequence even if, for now, it immediately converts it to a String? > Label constructor > - > > Key: WICKET-845 > URL: https://issues.apache.org/jira/browse/WICKET-845 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta2 >Reporter: Sean Sullivan > Fix For: 1.3.0-beta4 > > > Currently, the Label class provides this constructor: > public Label(final String id, String label) > Can this be changed to: > public Label(final String id, CharSequence label) > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1028) WebRequestCycle.getProcessor javadoc doesn't make sense
WebRequestCycle.getProcessor javadoc doesn't make sense --- Key: WICKET-1028 URL: https://issues.apache.org/jira/browse/WICKET-1028 Project: Wicket Issue Type: Bug Components: wicket Reporter: Sam Hough Priority: Minor WebRequestCycle.getProcessor javadoc suggests overriding WebApplication.getRequestCycleProcessor() but this method is marked final... Also doesn't seem obvious what the recommended approach is for adding custom behaviour for the request cycle processor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1012) make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final
make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final
-
Key: WICKET-1012
URL: https://issues.apache.org/jira/browse/WICKET-1012
Project: Wicket
Issue Type: Wish
Components: wicket
Affects Versions: 1.3.0-beta3
Reporter: Sam Hough
I'd like to hook into them to track dirty components... The best alternative
I've come up with so far is to iterate through all the components and keep a
copy of their old state :( Nice in that it will be smart about
setVisible(false); setVisible(true) but not sure that is worth it.
Seems like it may also be useful to other developers for many other reasons
including avoiding unwanted states ("don't add X here", "this must never be
invisible"...).
I'm not sure I fully understand the pros/cons of making things final as I've
never produced code meant to be use by many developers with their various bad
habits. If it is dangerous to alter the behaviour of these methods maybe add a
warning comment e.g. "ALTER BEHAVIOUR AT OWN RISK - MAY BE CHANGED TO FINAL"
If Wicket code doesn't have a need to hook into these events then adding new
hooks seems overkill.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-994) Ajax requests may happen before DOM is ready
[ https://issues.apache.org/jira/browse/WICKET-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Hough updated WICKET-994: - Attachment: test.zip Description of how to use the file in initial posting. > Ajax requests may happen before DOM is ready > > > Key: WICKET-994 > URL: https://issues.apache.org/jira/browse/WICKET-994 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-beta3 > Environment: FF 2, IE 6 >Reporter: Sam Hough > Attachments: test.zip > > > If an Ajax request submits a form that was "recently" updated via Wicket Ajax > (using innerHTML) the DOM may not yet be complete so the request is invalid. > Please find attached a Wicket application (unzip into src directory and point > web.xml at TestWicketApplication). The quickest way to demonstrate the > problem is to get focus on the submit button and hold down the return key. > This code updates the whole form, in order to keep the test small, in our > production code only a few fields are updated but the problem is the same. > Please let me know if I should change the test to be more useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-994) Ajax requests may happen before DOM is ready
Ajax requests may happen before DOM is ready Key: WICKET-994 URL: https://issues.apache.org/jira/browse/WICKET-994 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3 Environment: FF 2, IE 6 Reporter: Sam Hough If an Ajax request submits a form that was "recently" updated via Wicket Ajax (using innerHTML) the DOM may not yet be complete so the request is invalid. Please find attached a Wicket application (unzip into src directory and point web.xml at TestWicketApplication). The quickest way to demonstrate the problem is to get focus on the submit button and hold down the return key. This code updates the whole form, in order to keep the test small, in our production code only a few fields are updated but the problem is the same. Please let me know if I should change the test to be more useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-962) Ajax updates do not work on Components with wicket id that is not \d+ when within AbstractRepeater/RepeatingView
Ajax updates do not work on Components with wicket id that is not \d+ when within AbstractRepeater/RepeatingView Key: WICKET-962 URL: https://issues.apache.org/jira/browse/WICKET-962 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3 Reporter: Sam Hough Priority: Trivial Since RepeatingView requires that its child components have numeric only ids it would be helpful if RepeatingView (or rather AbstractRepeater?) warned in the logs that Ajax requests will fail if a child id is not \d+. >From nabble discussion: http://www.nabble.com/RepeatingView-id-tf4427681.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-758) HTML validation cleanliness
[ https://issues.apache.org/jira/browse/WICKET-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526527 ] Sam Hough commented on WICKET-758: -- In 1.3-beta3 should it be returning "id"+String.valueOf(childIdCounter) now? The comment suggests it is but the code doesn't. Not sure if it is related but to keep my html monkey happy I changed ours to do "id" + String.valueOf... and ajax updates of that component broke. Claiming on the server side that it couldn't find the matching markup in the parent element. The only thing that had changed was the Component id. To make it stranger it seems to work (for a single component in the repeater) if I hard code it to any number or the same id as used for the element to be repeated. Make sense to anybody before I suffer the pain of debugging? Could it really care if the id is [0-9]+ or not? Cheers Sam > HTML validation cleanliness > --- > > Key: WICKET-758 > URL: https://issues.apache.org/jira/browse/WICKET-758 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.3.0-beta1, > 1.3.0-beta2 > Environment: osx jvm etc etc >Reporter: Victor Igumnov >Assignee: Frank Bille Jensen >Priority: Trivial > Fix For: 1.3.0-beta3 > > Attachments: WICKET-758.patch > > > AbstractRepeater generates IDs starting with integers, html ids can't start > with a number. > Modication > public String newChildId(); change -> return > "id"+String.valueOf(childIdCounter); > WicketAjaxIndicatorAppender append an alt tag to the indicator, line 74. > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-940) AjaxFallbackLink.onClick be helpful if not final
[ https://issues.apache.org/jira/browse/WICKET-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526109 ] Sam Hough commented on WICKET-940: -- Again in the spirit of further documenting one, minority, point of view: AjaxTabbedPanel seems like a symptom of raising Ajax issues to such a high level. The TabbedPanel should be busy worrying about being a tabbed panel not how to behave for Ajax. Presumably the non-fallback AjaxLink and AjaxButton are deprecated but it still means you have the Ajax and non-Ajax flavours of components. If buttons and links came from a factory and had the same signature you would only need one TabbedPanel and then any extensions via inheritance wouldn't need duplicating. AjaxTabbedPanel also invents its own hook onAjaxUpdate which also seems ugly. > AjaxFallbackLink.onClick be helpful if not final > > > Key: WICKET-940 > URL: https://issues.apache.org/jira/browse/WICKET-940 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Sam Hough >Assignee: Igor Vaynberg >Priority: Minor > > I'd like to override AjaxFallbackLink.onClick and have application code live > there rather than in the Ajax specific method. Obviously I could have > onMyClick but this seems rather ugly and wouldn't look/feel the same as just > using a Link object. > AjaxFallbackButton.onSubmit is not final so it also seems inconsistent. > Thanks > Sam -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-940) AjaxFallbackLink.onClick be helpful if not final
[ https://issues.apache.org/jira/browse/WICKET-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525892 ] Sam Hough commented on WICKET-940: -- I'm not really trying to change your mind just add a note about how at least one developer wanted to use Wicket. Our application code uses OurButton which extends AjaxFallBackButton which removes the need to call super and hides AjaxRequestTarget. As I've said before I'm new to Wicket world but AjaxRequestTarget does seem pretty low level to me. I'm really pleased to move away from thinking in just strings (as with JSP etc) and move higher up the abstraction food chain to components. Wicket does this really nicely. It may just be the drugs but I don't see the need to manage component updates by hand. Anyway, might give me just enough of an excuse to have handler objects rather than re-implementing onClick etc. I've still not come up with a nice way to tell ListChoice etc that I want the server to be notified of events. Presumably be more familiar to people coming from Swing or GWT etc... Cheers Igor ;) > AjaxFallbackLink.onClick be helpful if not final > > > Key: WICKET-940 > URL: https://issues.apache.org/jira/browse/WICKET-940 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Sam Hough >Assignee: Igor Vaynberg >Priority: Minor > > I'd like to override AjaxFallbackLink.onClick and have application code live > there rather than in the Ajax specific method. Obviously I could have > onMyClick but this seems rather ugly and wouldn't look/feel the same as just > using a Link object. > AjaxFallbackButton.onSubmit is not final so it also seems inconsistent. > Thanks > Sam -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-940) AjaxFallbackLink.onClick be helpful if not final
[
https://issues.apache.org/jira/browse/WICKET-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525853
]
Sam Hough commented on WICKET-940:
--
I liked
onSubmit() {
// my nice application code
}
and
onClick() {
// my nice application code
}
without low level implementation detail getting in the way
> AjaxFallbackLink.onClick be helpful if not final
>
>
> Key: WICKET-940
> URL: https://issues.apache.org/jira/browse/WICKET-940
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.3.0-beta3
>Reporter: Sam Hough
>Assignee: Igor Vaynberg
>Priority: Minor
>
> I'd like to override AjaxFallbackLink.onClick and have application code live
> there rather than in the Ajax specific method. Obviously I could have
> onMyClick but this seems rather ugly and wouldn't look/feel the same as just
> using a Link object.
> AjaxFallbackButton.onSubmit is not final so it also seems inconsistent.
> Thanks
> Sam
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-940) AjaxFallbackLink.onClick be helpful if not final
AjaxFallbackLink.onClick be helpful if not final Key: WICKET-940 URL: https://issues.apache.org/jira/browse/WICKET-940 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3 Reporter: Sam Hough Priority: Minor I'd like to override AjaxFallbackLink.onClick and have application code live there rather than in the Ajax specific method. Obviously I could have onMyClick but this seems rather ugly and wouldn't look/feel the same as just using a Link object. AjaxFallbackButton.onSubmit is not final so it also seems inconsistent. Thanks Sam -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-921) AbstractRepeater.add(int index, Component c) method
[ https://issues.apache.org/jira/browse/WICKET-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525114 ] Sam Hough commented on WICKET-921: -- OK. I'll stick with RepeatingView and removing items then adding them back in the order I like. I did use ListView for this before but struggled to get the re-use strategy right. In the end it made a seemingly simple task complicated. I don't want the view refreshed so think I'll avoid RefreshingView which also seems to make life more complicated than needs be. Is there a more appropriate component if I just want to fiddle with order of a set of components in an ad-hoc way? Like normal Widget set Panels etc? It would also be nice if the component was valid as an AjaxTarget component. Thanks Sam > AbstractRepeater.add(int index, Component c) method > --- > > Key: WICKET-921 > URL: https://issues.apache.org/jira/browse/WICKET-921 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Sam Hough >Assignee: Igor Vaynberg >Priority: Minor > > The ability to insert a Component into an AbstractRepeater would save having > to rebuild the "list" from scratch. Behaviour could/should be like > List.add(int index, E element). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-921) AbstractRepeater.add(int index, Component c) method
[ https://issues.apache.org/jira/browse/WICKET-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525016 ] Sam Hough commented on WICKET-921: -- Sorry, should have read around more. However, I'm actually using RepeatingView which does claim to look after the order for me. Make sense to have a add(int i, Component e) method here? > AbstractRepeater.add(int index, Component c) method > --- > > Key: WICKET-921 > URL: https://issues.apache.org/jira/browse/WICKET-921 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Sam Hough >Assignee: Igor Vaynberg >Priority: Minor > > The ability to insert a Component into an AbstractRepeater would save having > to rebuild the "list" from scratch. Behaviour could/should be like > List.add(int index, E element). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-921) AbstractRepeater.add(int index, Component c) method
AbstractRepeater.add(int index, Component c) method --- Key: WICKET-921 URL: https://issues.apache.org/jira/browse/WICKET-921 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.0-beta3 Reporter: Sam Hough Priority: Minor The ability to insert a Component into an AbstractRepeater would save having to rebuild the "list" from scratch. Behaviour could/should be like List.add(int index, E element). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
