[jira] Commented: (WICKET-1504) AutoCompleteTextField - javascript error type mismatch in line 227 in IE
[ https://issues.apache.org/jira/browse/WICKET-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646536#action_12646536 ] Will Hoover commented on WICKET-1504: - It was also brought up in the forum that there is a typo in AutoCompleteTextField.java Line 257 should be like this: tag.put(autocomplete, off); instead of this tag.put(autocomplete, false); AutoCompleteTextField - javascript error type mismatch in line 227 in IE -- Key: WICKET-1504 URL: https://issues.apache.org/jira/browse/WICKET-1504 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.3 Environment: IE 6.0 Reporter: Niels Bo Fix For: 1.4-RC2 I just swithed from 1.3.2 to 1.3.3 and that resultet in a javascript error type mismatch in line 227, wich is this line in wicket-autocomplete.js: menu.style.zIndex=index==auto?index:Number(index)+1; Only in IE (6.0) - firefox works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1736) Allow Access to AutoCompleteTextField AutoCompleteBehavior
[
https://issues.apache.org/jira/browse/WICKET-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Hoover updated WICKET-1736:
Description:
Currently there is no easy way to access the AutoCompleteBehavior of the
AutoCompleteTextField. This is useful when dynamically enabling/disabling the
behavior (among other reasons).
The current code is:
{code}
public AutoCompleteTextField(String id, IModel model, Class type,
IAutoCompleteRenderer renderer, AutoCompleteSettings settings)
{
super(id, model, type);
// this disables Firefox autocomplete
add(new SimpleAttributeModifier(autocomplete, off));
add(new AutoCompleteBehavior(renderer, settings)
{
private static final long serialVersionUID = 1L;
protected Iterator getChoices(String input)
{
return
AutoCompleteTextField.this.getChoices(input);
}
});
}
{code}
One solution to this is to extract the creation of the AutoCompleteBehavior to
a method:
{code}
public AutoCompleteTextField(final String id, final IModel model, final
Class? type, final IAutoCompleteRenderer renderer, final AutoCompleteSettings
settings) {
super(id, model, type);
// this disables Firefox autocomplete
add(new SimpleAttributeModifier(autocomplete, off));
final AutoCompleteBehavior autoCompleteBehavior =
createAutoCompleteBehavior(renderer, settings);
if (autoCompleteBehavior == null) {
throw new NullPointerException(Auto complete behavior
cannot be null);
}
add(autoCompleteBehavior);
}
protected AutoCompleteChoiceBehavior createAutoCompleteBehavior(final
IAutoCompleteRenderer renderer, final AutoCompleteSettings settings) {
return new AutoCompleteChoiceBehavior(renderer, settings);
}
public class AutoCompleteChoiceBehavior extends AutoCompleteBehavior {
public AutoCompleteChoiceBehavior(final IAutoCompleteRenderer
renderer, final AutoCompleteSettings settings) {
super(renderer, settings);
}
protected final Iterator? getChoices(final String input) {
return
AbstractAutoCompleteTextField.this.getChoices(input);
}
}
{code}
Also, when the auto-complete behavior is disabled [overriding the
isEnable(component)] it currently does not clear the client events from the
text field. A work around for this is to clear it out onCompoentTag (not the
best option, but it works):
{code}
protected void onComponentTag(final ComponentTag tag) {
if (!getAutoCompleteBehavior().isEnabled(this)) {
// FIXME : Need to clear the events when the
auto-complete behavior is disabled
tag.put(onfocus,
this.onblur=null;this.onchange=null;this.onkeydown=null;this.onkeypress=null;this.onkeyup=null;);
}
super.onComponentTag(tag);
}
{code}
was:
Currently there is no easy way to access the AutoCompleteBehavior of the
AutoCompleteTextField. This is useful when dynamically enabling/disabling the
behavior (among other reasons).
The current code is:
{code}
public AutoCompleteTextField(String id, IModel model, Class type,
IAutoCompleteRenderer renderer, AutoCompleteSettings settings)
{
super(id, model, type);
// this disables Firefox autocomplete
add(new SimpleAttributeModifier(autocomplete, off));
add(new AutoCompleteBehavior(renderer, settings)
{
private static final long serialVersionUID = 1L;
protected Iterator getChoices(String input)
{
return
AutoCompleteTextField.this.getChoices(input);
}
});
}
{code}
One solution to this is to extract the creation of the AutoCompleteBehavior to
a method:
{code}
public AutoCompleteTextField(final String id, final IModel model, final
Class? type, final IAutoCompleteRenderer renderer, final AutoCompleteSettings
settings) {
super(id, model, type);
// this disables Firefox autocomplete
add(new SimpleAttributeModifier(autocomplete, off));
final AutoCompleteBehavior autoCompleteBehavior =
getAutoCompleteBehavior(renderer, settings);
if (autoCompleteBehavior == null) {
throw new NullPointerException(Auto complete behavior
cannot be null);
[jira] Issue Comment Edited: (WICKET-1717) AutoCompleteTextField using AjaxFormComponentUpdatingBehavior(onchange) executes twice when selection is made using arrow/enter keys
[
https://issues.apache.org/jira/browse/WICKET-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608517#action_12608517
]
whoover.nemours edited comment on WICKET-1717 at 6/26/08 10:39 AM:
---
Looks like the linked issue is the opposite to
https://issues.apache.org/jira/browse/WICKET-1280 (mouse click causes execution
twice).
was (Author: whoover.nemours):
Looks like the linked issue is the opposite to this one (mouse click causes
execution twice).
AutoCompleteTextField using AjaxFormComponentUpdatingBehavior(onchange)
executes twice when selection is made using arrow/enter keys
--
Key: WICKET-1717
URL: https://issues.apache.org/jira/browse/WICKET-1717
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.3.4
Environment: Windows: Fiefox 2.x/3.0, Opera 9.5 (Works properly in IE
6/7 and Safari 3.1.1)
Reporter: Will Hoover
AutoCompleteTextField using AjaxFormComponentUpdatingBehavior(onchange)
executes twice when selection is made using arrow/enter keys.
{code}
input wicket:id=name id=test-me type=text size=140 /
{code}
{code}
final ListString choices = new ArrayListString();
choices.add(one);
choices.add(two);
choices.add(three);
final AutoCompleteTextField actf = new AutoCompleteTextField(test-me, new
Model()) {
protected IteratorString getChoices(final String searchTextInput) {
return choices.iterator();
}
};
actf.add(new AjaxFormComponentUpdatingBehavior(onchange) {
protected void onUpdate(final AjaxRequestTarget target) {
// FIXME : executes twice
LOG.debug(Called);
}
});
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1700) Make functionality of ContextImage a behavior so that other types of components can utilize its functionality
Make functionality of ContextImage a behavior so that other types of components can utilize its functionality - Key: WICKET-1700 URL: https://issues.apache.org/jira/browse/WICKET-1700 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-M2 Environment: N/A Reporter: Will Hoover Priority: Trivial It would be better if ContextImage was a behavior rather than an actual component. For instance, if you have an html input of type=image (or a link for that matter) you can still utilize the behavior whereas a component you cannot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1654) Update validators to accept IModel parameter for easy override of error messages
Update validators to accept IModel parameter for easy override of error messages Key: WICKET-1654 URL: https://issues.apache.org/jira/browse/WICKET-1654 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-M1 Environment: N/A Reporter: Will Hoover Priority: Minor Update validators to accept IModel parameter for easy override of error messages. Instead of looking up the resource key in Application.properties and adding to the components properties file, allow a model to be passed into the validators that will override the default validation error message. For example: StringResourceModel srm = new StringResourceModel(my.custom.stringvalidator.message, null); add(new TextField(fname).setLabel(new Model(first name)).add(StringValidator.minimum(5, srm)); 1) This will also allow someone to pass in parameters that they want displayed along with the validation error message (difficult to accomplish when just overriding the resource key- where to pass?) 2) More intuitive because it uses the same concept that is applied to components... i.e. new TextField(id, new Model(...)) VS StringValidator.minimum(5, new Model(...)) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1644) Add IChoiceRenderer to RadioGroup CheckGroup
Add IChoiceRenderer to RadioGroup CheckGroup
Key: WICKET-1644
URL: https://issues.apache.org/jira/browse/WICKET-1644
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.3
Environment: N/A
Reporter: Will Hoover
Priority: Minor
Other components (i.e. DropDownChoice, CheckBoxMultipleChoice, etc.) that deal
with choices have the ability to use an IChoiceRenderer in order to implement
getDisplayValue(...) and getIdValue(...)
It is sometimes a requirement to supply the ID value when making a selection
using RadioGroup/CheckGroup. For example:
class MyObject {
private Long id;
private MyObjectOption myObjectOption;
public MyObject(final Long id){
setId(id);
...
}
...
}
class MyObjectOption {
private Long id;
private String name;
public MyObjectOption(final Long id){
setId(id);
...
}
...
}
// in the WebPage
final MyObject myObject = new MyObject(1L);
...
myObject.setMyObjectOption(new MyObjectOption(200L));
final ListMyObjectOption myObjectOptionList = new
ArrayListMyObjectOption();
myObjectOptionList.add(new MyObjectOption(100L));
myObjectOptionList.add(new MyObjectOption(200L));
myObjectOptionList.add(new MyObjectOption(300L));
final Form myForm = new Form(form-myobject, new
CompoundPropertyModel(myObject));
...
final RadioGroup group = new RadioGroup(myObjectOption);
group.add(new ListView(div-myobject-options-view, myObjectList) {
protected final void populateItem(final ListItem item) {
final MyObjectOption myObjectOption = (MyObjectOption)
item.getModelObject();
item.add(new Label(label-myobject-option-name,
myObjectOption.getName()));
item.add(new Radio(input-radio-myobject-option, new
Model(myObjectOption)));
}
});
myForm.add(group);
add(myForm);
form wicket:id=form-myobject
div wicket:id=myObjectOption
div wicket:id=div-myobject-options-view
label wicket:id=label-myobject-option-name
[MyObjectOption Name]
/label
input wicket:id=input-radio-myobject-option
type=radio /
/div
/div
/form
In the example above myObjectOption would never be selected because it
is not the same instance of the MyObjectOption that is in
myObjectOptionList (index 1) even though they share the same ID. If an
IChoiceRenderer was provided to the RadioGroup the following could
accomplish the task of making the selection work:
final IChoiceRenderer myObjectOptionRenderer = new ChoiceRenderer() {
...
public final String getIdValue(final Object object, final int
index) {
final Object id = ((MyObjectOption) object).getId();
return (id != null) ? id.toString() :
super.getIdValue(object, index);
}
...
};
An easy solution to the above example is to ensure that equals and hashcode are
overridden, but if MyObject and MyObjectOption are not within the developers
namespace then this will not be possible. Also, for consistency sake, if other
components that deal with choices have the capability to use an IChoiceRenderer
then RadioGroup/CheckGroup should also have that option.
Full forum thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg18283.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-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581973#action_12581973
]
Will Hoover commented on WICKET-1449:
-
Default behavior that causes a malfunction in the whole application seems like
a good candidate for an absolute blocker :o)
'./' appended to URL causes HTTP 404 in Internet Explorer (using root context)
--
Key: WICKET-1449
URL: https://issues.apache.org/jira/browse/WICKET-1449
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Environment: Wicket 1.3.2
JBoss 4.0/Jetty 6.1.7
JDK 1.6.0_03
Reporter: Will Hoover
Assignee: Alastair Maw
Fix For: 1.3.3
Original Estimate: 72h
Remaining Estimate: 72h
SYNOPSIS:
1) Web application is using the root context (/)
1) form.add(new Button(mybutton));
2) Button is clicked on any WebPage that is NOT MOUNTED
ISSUE:
WebRequestCodingStrategy.encode appends './' to the URL. The page is
redirected to http://www.mysite.com/./; It works fine in Firefox and Opera,
but in IE an HTTP 404 ('.' page is not found) is rendered.
Mounting the home page to something like '/home' solved the problem ('./' is
not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581975#action_12581975
]
Will Hoover commented on WICKET-1449:
-
Also... Isn't an absolute blocker supposed to use Blocker priority not
Critical? ;o)
'./' appended to URL causes HTTP 404 in Internet Explorer (using root context)
--
Key: WICKET-1449
URL: https://issues.apache.org/jira/browse/WICKET-1449
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Environment: Wicket 1.3.2
JBoss 4.0/Jetty 6.1.7
JDK 1.6.0_03
Reporter: Will Hoover
Assignee: Alastair Maw
Fix For: 1.3.3
Original Estimate: 72h
Remaining Estimate: 72h
SYNOPSIS:
1) Web application is using the root context (/)
1) form.add(new Button(mybutton));
2) Button is clicked on any WebPage that is NOT MOUNTED
ISSUE:
WebRequestCodingStrategy.encode appends './' to the URL. The page is
redirected to http://www.mysite.com/./; It works fine in Firefox and Opera,
but in IE an HTTP 404 ('.' page is not found) is rendered.
Mounting the home page to something like '/home' solved the problem ('./' is
not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581978#action_12581978
]
Will Hoover commented on WICKET-1449:
-
Well, judging by the number of people that have posted the question on the
forum (I counted 3 including myself) I would hardly say that it is JUST me.
Besides, we all know that not everyone that experiences the problem will report
the issue ;o)
Any application that has an out-of the-box functionality that completely breaks
the application in a commonly used browser seems like a critical issue to me,
but from this point on I will only use priority of Major and below... Sorry for
placing this issue in Critical priority status :o)
'./' appended to URL causes HTTP 404 in Internet Explorer (using root context)
--
Key: WICKET-1449
URL: https://issues.apache.org/jira/browse/WICKET-1449
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Environment: Wicket 1.3.2
JBoss 4.0/Jetty 6.1.7
JDK 1.6.0_03
Reporter: Will Hoover
Assignee: Alastair Maw
Fix For: 1.3.3
Original Estimate: 72h
Remaining Estimate: 72h
SYNOPSIS:
1) Web application is using the root context (/)
1) form.add(new Button(mybutton));
2) Button is clicked on any WebPage that is NOT MOUNTED
ISSUE:
WebRequestCodingStrategy.encode appends './' to the URL. The page is
redirected to http://www.mysite.com/./; It works fine in Firefox and Opera,
but in IE an HTTP 404 ('.' page is not found) is rendered.
Mounting the home page to something like '/home' solved the problem ('./' is
not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1055) Add ability to have Radio and RadioGroup not related via component hierarchy
[
https://issues.apache.org/jira/browse/WICKET-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580777#action_12580777
]
Will Hoover commented on WICKET-1055:
-
Another use case for this was brought up on the user forum:
table
tr wicket:id=selectionRows
tdspan wicket:id=username[Username]/span/td
tdinput wicket:id=choice1 type=radio //td
tdinput wicket:id=choice2 type=radio//td
/tr
/table
final DataView dataView = new DataView(selectionRows, dataProvider) {
protected void populateItem(final Item item) {
UserChoice uc = (UserChoice) item.getModelObject();
item.add(new Label(username, uc.getUsername()));
// the following radios make up a single group so the total number of
radio groups = the total number of rows in the table, but a radio group cannot
be wrapped around two tds
item.add(new Radio(choice1, new Model()));
item.add(new Radio(choice2, new Model()));
}
}
Add ability to have Radio and RadioGroup not related via component hierarchy
Key: WICKET-1055
URL: https://issues.apache.org/jira/browse/WICKET-1055
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.0-beta3
Reporter: Tim O'Brien
Fix For: 1.4-M1
Attachments: patch-detached-radio.txt
I was working on an application that needed to be able to support a Radio
button that wasn't nested within a RadioGroup. Here's an illustration of
the component hierarchy I needed to support:
span wicket:id=radioGroup1/span
input type=radio wicket:id=option1A/
input type=radio wicket:id=option1B/
The existing RadioGroup/Radio code relies on the component hierarchy, so the
only way to render a radio group would be:
span wicket:id=radioGroup1
input type=radio wicket:id=option1A/
input type=radio wicket:id=option1B/
/span
The following patch to Radio and RadioGroup adds the ability to provide an
explicit relationship between Radio and RadioGroup - bypassing the component
hierarchy.
Why did I need this? The application I'm working on creates a form based on
meta-data about a specific object. There were a few situation where I
needed to render two radio options in different parts of a form, and then
only way to support this was to violate the hierarchy requirement of
Radio/RadioGroup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-911) refactor feedback to allow users to easily add custom levels
[
https://issues.apache.org/jira/browse/WICKET-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577837#action_12577837
]
Will Hoover commented on WICKET-911:
I disagree... Wicket currently makes it convenient to generically define the
message levels for underlying components that use them. For example, in a
FeedbackPanel I can check the message level stored in the FeedbackMessage and
determine how I need to format the message for display:
protected final String getFeedbackResourcePrefix() {
java.util.IteratorFeedbackMessage it =
Session.get().getFeedbackMessages().iterator();
FeedbackMessage fbm;
int level = -1;
while (it.hasNext()) {
fbm = it.next();
if (fbm.isFatal() || fbm.isError()) {
return label.error;
} else if (fbm.isWarning()) {
level = FeedbackMessage.WARNING;
} else if (level FeedbackMessage.WARNING fbm.isInfo()) {
level = FeedbackMessage.INFO;
}
}
switch (level) {
case FeedbackMessage.WARNING:
return label.warning;
case FeedbackMessage.INFO:
return label.info;
default:
return label.success;
}
}
However, I do see an advantage to removing the bloat... Why not remove all of
the error(message), info(message), etc. and replace them with one method
message(message, level) or component.addFeedbackMessage(message, level)?
Then any message level is accommodated for and the message levels themselves
can be removed from the FeedbackMessage class. The level will become just a
placeholder.
refactor feedback to allow users to easily add custom levels
Key: WICKET-911
URL: https://issues.apache.org/jira/browse/WICKET-911
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.0-final
Reporter: Igor Vaynberg
Fix For: 1.4-M1
we have preset levels of fatal/error/warn/info, but users keep asking for
more, such as sucess, see WICKET-907. we should probably refactor feedback to
have
component.addfeedback(feedbackmessage) instead of having ten methods for
prebuild levels. as far as i can see wicket doesnt need to know if the
message is error or success so there is no point in having a more complicated
system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1085) Input Text Mask
[ https://issues.apache.org/jira/browse/WICKET-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561325#action_12561325 ] Will Hoover commented on WICKET-1085: - no offense taken :o) Looks like a nice tool- Although, it is a little bloated. Is it possible to shrink it (as you proposed)? Also, the expected behavior of the backspace/delete keys are not what most user's would expect- I suppose that is customizable? Most of the bells and whistle features are pretty easy to add to the attached mask if desired (background color, cursor, etc.) Input Text Mask --- Key: WICKET-1085 URL: https://issues.apache.org/jira/browse/WICKET-1085 Project: Wicket Issue Type: New Feature Components: wicket-extensions Affects Versions: 1.3.0-rc1 Reporter: Will Hoover Assignee: Frank Bille Jensen Priority: Trivial Fix For: 1.4-M2 Attachments: inputTextMask.js Allow developers to designate a keystroke input pattern for the input text component. The pattern would be used on the client to control valid keystrokes for the current cursor position within the input text field in relation to the specified pattern. For example, a pattern could be designated as (999)- causing only number values in each position where a 9 appears and using the (, ), and - as masking characters. When the cursor position reached one of these mask characters the cursor position would advance to the next 9 position. The resulting mask would appear as (___)___- within the input text value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1203) Support JavaScript contributions that will insert includes at the bottom of markup instead of header
[ https://issues.apache.org/jira/browse/WICKET-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556920#action_12556920 ] Will Hoover commented on WICKET-1203: - The only script that would be effected by this change would be inline script. The proposed solution is to implement a more intelligent insertion of the script farther down the dom tree. That doesn't mean that the script has to be at the bottom of the page in every case. One way, but definitely not the only way to address this is to detect any inline script that is added to the page and wrap in an onload listener. If the above solution is not preferred, at least provide a simple means to override where the core wicket script and contributors are rendered so that anyone that wants to increase performance can do so (knowingly asserting the consequences if any inline script is added that uses it before it loads) :) Support JavaScript contributions that will insert includes at the bottom of markup instead of header Key: WICKET-1203 URL: https://issues.apache.org/jira/browse/WICKET-1203 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.0-rc1 Reporter: Will Hoover Assignee: Matej Knopp Priority: Minor Fix For: 1.4.0-M1 Create/Update forJavaScript that is external from the HeaderContributor that does a more intelligent insertion of the script farther down the dom tree to increase performance. Reference: http://developer.yahoo.com/performance/rules.html#js_bottom -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1203) Support JavaScript contributions that will insert includes at the bottom of markup instead of header
Support JavaScript contributions that will insert includes at the bottom of markup instead of header Key: WICKET-1203 URL: https://issues.apache.org/jira/browse/WICKET-1203 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.0-rc1 Reporter: Will Hoover Priority: Minor Create/Update forJavaScript that is external from the HeaderContributor that does a more intelligent insertion of the script farther down the dom tree to increase performance. Reference: http://developer.yahoo.com/performance/rules.html#js_bottom -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1085) Input Text Mask
[ https://issues.apache.org/jira/browse/WICKET-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536203 ] Will Hoover commented on WICKET-1085: - Seeing that the only issue that exists is in relation to prefilled invalid values... IMHO, I think that it can/should be done generically on the TextField component. All that would be needed is to verify that a valid regexp validator exists that supports the mask (remove reserved characters: 9, L, l, A, and any characters that exist between the reserved regexp character X). Basically, this is how a type definition is declared on the TextField to begin with (minus the mask check)- is it not? Otherwise, a MaskTextField is fine, but I think it's just as easy to do it generically :o) Input Text Mask --- Key: WICKET-1085 URL: https://issues.apache.org/jira/browse/WICKET-1085 Project: Wicket Issue Type: New Feature Components: wicket-extensions Reporter: Will Hoover Assignee: Frank Bille Jensen Priority: Trivial Attachments: inputTextMask.js Allow developers to designate a keystroke input pattern for the input text component. The pattern would be used on the client to control valid keystrokes for the current cursor position within the input text field in relation to the specified pattern. For example, a pattern could be designated as (999)- causing only number values in each position where a 9 appears and using the (, ), and - as masking characters. When the cursor position reached one of these mask characters the cursor position would advance to the next 9 position. The resulting mask would appear as (___)___- within the input text value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1085) Input Text Mask
[ https://issues.apache.org/jira/browse/WICKET-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536192 ] Will Hoover commented on WICKET-1085: - 1) As Billie stated- that was the intention to have (999)999 evaluate as a string. Most masks should be evaluated a string seeing that most of the time a mask would contain special characters that define the mask (i.e. (, ), and - in the example). For special cases where a string needs to be converted (such as the case with a date) it would be just as easy to use a converter that converts a date based upon a regexp check on the server. If I am missing something let me know :o) 2) To clarify, this is only an issue when a invalid prefilled value is provided. In which case, IMHO, is an issue with the data provided. If the user does not have a valid value to begin with then it's an issue with their data. However, the script does handle valid prefilled values. The script assumes that the initial value (if any) originated from a valid source (i.e. DB or other source). If this is really an issue that needs to be addressed... A) I could add a page load listener that would validate the value and handle conversion accordingly, but what would we do if an invalid value is found? notify the user and leave it as is (really doesn't resolve the issue)? clear the value (may confusing to developers to see their data missing)? B) We could do the validation on the server side before rendering the page- seeing that we already have the mask pattern at that point. Not to mention, we need to do the conversion (and possibly validation) going back to the server anyways, but this will duplicate our efforts in that the code used to evaluate/convert the value would exist on the server as well as the client. Input Text Mask --- Key: WICKET-1085 URL: https://issues.apache.org/jira/browse/WICKET-1085 Project: Wicket Issue Type: New Feature Components: wicket-extensions Reporter: Will Hoover Assignee: Frank Bille Jensen Priority: Trivial Attachments: inputTextMask.js Allow developers to designate a keystroke input pattern for the input text component. The pattern would be used on the client to control valid keystrokes for the current cursor position within the input text field in relation to the specified pattern. For example, a pattern could be designated as (999)- causing only number values in each position where a 9 appears and using the (, ), and - as masking characters. When the cursor position reached one of these mask characters the cursor position would advance to the next 9 position. The resulting mask would appear as (___)___- within the input text value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1085) Input Text Mask
[ https://issues.apache.org/jira/browse/WICKET-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Hoover updated WICKET-1085: Attachment: inputTextMask.js Attached is the JS script I wrote to handle the mask on the client. There are no libraries needed to use it (it's self contained). All code is original except the trivial snippet at the bottom that is public domain that adds an escape feature to JavaScript's RegExp. Example usage (param1= input component, param2=mask, param3=clear the input text value when invalid): input type=text onfocus=javascript: InputTextMask.processMaskFocus(this, '(999)999-', true); / /** * InputTextMask component script used for mask/regexp operations. * Mask Individual Character Usage: * 9 - designates only numeric values * L - designates only uppercase letter values * l - designates only lowercase letter values * A - designates only alphanumeric values * X - denotes that a custom client script regular expression is specified/li * All other characters are assumed to be special characters used to mask * the input component * Example 1: * (999)999- only numeric values can be entered where the the character * position value is 9. Parenthesis and dash are non-editable/mask characters. * Example 2: * 99L-ll-X[^A-C]X only numeric values for the first two characters, * uppercase values for the third character, lowercase letters for the * fifth/sixth characters, and the last character X[^A-C]X together counts * as the eighth character regular expression that would allow all characters * but A, B, and C. Dashes outside the regular expression are * non-editable/mask characters. */ Input Text Mask --- Key: WICKET-1085 URL: https://issues.apache.org/jira/browse/WICKET-1085 Project: Wicket Issue Type: New Feature Components: wicket-extensions Reporter: Will Hoover Priority: Trivial Attachments: inputTextMask.js Allow developers to designate a keystroke input pattern for the input text component. The pattern would be used on the client to control valid keystrokes for the current cursor position within the input text field in relation to the specified pattern. For example, a pattern could be designated as (999)- causing only number values in each position where a 9 appears and using the (, ), and - as masking characters. When the cursor position reached one of these mask characters the cursor position would advance to the next 9 position. The resulting mask would appear as (___)___- within the input text value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
