Re: threading issues - continued
Thanks Eelco, https://issues.apache.org/jira/browse/WICKET-994 Have you had a chance to reproduce it? We tested with a few browsers but all in the same server env, although hard to see what difference that would make. Eelco Hillenius wrote: On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip It's probably a good idea to open a JIRA issue for this and attach the zip to that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting focus to a TextField
If you need to change focus from the server side:
textField.add(new AjaxFormComponentUpdatingBehavior(onblur) {
@Override
protected void onUpdate(AjaxRequestTarget target) {
target.addComponent(MyPanel.this);
String scriptStart =
document.getElementById(';
String scriptEnd = ').focus();
if (textField.hasErrorMessage()) {
target.appendJavascript(scriptStart +
textField.getMarkupId() + scriptEnd);
} else if (aCondition) {
target.appendJavascript(scriptStart
+
firstPanel.getFirstFocusableComponent().getMarkupId() + scriptEnd);
} else {
target.appendJavascript(scriptStart
+
secondPanel.getFirstFocusableComponent().getMarkupId() + scriptEnd);
}
}
});
/Raluca
On 9/21/07, Gwyn Evans [EMAIL PROTECTED] wrote:
On Thursday, September 20, 2007, 11:43:45 PM, Doug [EMAIL PROTECTED] wrote:
I know this is probably one of the most trivial things to do...but I am
stumped. No example that I found on the Wicket example site has shown this.
I know that AjaxRequestTarget#focusComponent plays a part in this but not
sure how. Could someone post a quick code snippet or place on the Wiki on
how do to this in 1.3?
Well, the basic code you need is just a
script language=JavaScript
document.myform.myinput.focus();
/script
in the markup (if you use body onLoad... you may find it being
executed before that page if fully loaded) but I've not tried using
Wicket to tweak it.
/Gwyn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting focus to a TextField
Doug Leeper wrote:
I know this is probably one of the most trivial things to do...but I am
stumped. No example that I found on the Wicket example site has shown
this. I know that AjaxRequestTarget#focusComponent plays a part in this
but not sure how. Could someone post a quick code snippet or place on the
Wiki on how do to this in 1.3?
Thanks
For example, your TextField is f1, then:
AjaxLink link = new AjaxLink(link) {
public void onClick(AjaxRequestTarget target) {
target.addComponent(...);
target.focusComponent(f1);
}
};
--
View this message in context:
http://www.nabble.com/Setting-focus-to-a-TextField-tf4490766.html#a12814170
Sent from the Wicket - User mailing list archive at Nabble.com.
Re: threading issues - continued
Hi, I'm unable to reproduce this with latest trunk. I believe this has been already fixed by delaying the actual form serialization until the previous request finishes. Can you please test this with latest trunk? Unfurtunately, there are no current snapshots available so you'd have to build it from SVN. -Matej On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote: Thanks Eelco, https://issues.apache.org/jira/browse/WICKET-994 Have you had a chance to reproduce it? We tested with a few browsers but all in the same server env, although hard to see what difference that would make. Eelco Hillenius wrote: On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip It's probably a good idea to open a JIRA issue for this and attach the zip to that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to add RadioGroup column to DataTable?
igor.vaynberg wrote: heh, there is something wrong doesnt really give me any context to help you :) i would guess you need to put the radiogroup around the entire datatable. At least make sure there is a form component enclosing the RadioGroup. -- View this message in context: http://www.nabble.com/How-to-add-RadioGroup-column-to-DataTable--tf4485992.html#a12814262 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Btw., did you clean browser cache after updating wicket? There's
chance that you have old javascript code still in browser cache.
Also part of the fix is in wicket-ajax.js, line 950:
submitForm: function(form, submitButton) {
var body = function() {
var s = Wicket.Form.serialize(form);
if (submitButton != null) {
s += Wicket.Form.encode(submitButton) + =1;
}
return s;
}
return this.request.post(body);
},
So body is not just serialized from content, but it's a method that
returns serialized form content. This method gets evaluated right
before submitting the form, which means the previous ajax request must
have been finished.
-Matej
On 9/21/07, Matej Knopp [EMAIL PROTECTED] wrote:
So you tried it with latest trunk and it still doesn't work for you? I
used FF2/IE7 on Vista.
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
Still doesn't work for me. Can you give me a pointer to which change should
fix things?
What browser/OS did you use? Did you let the form get nice and big so it
takes a while to render?
Thanks for looking into it. Hope I'm not raising another red herring.
Matej Knopp-2 wrote:
Hi, I'm unable to reproduce this with latest trunk. I believe this has
been already fixed by delaying the actual form serialization until the
previous request finishes. Can you please test this with latest trunk?
Unfurtunately, there are no current snapshots available so you'd have
to build it from SVN.
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
Thanks Eelco,
https://issues.apache.org/jira/browse/WICKET-994
Have you had a chance to reproduce it? We tested with a few browsers but
all
in the same server env, although hard to see what difference that would
make.
Eelco Hillenius wrote:
On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote:
Matej,
Sorry for the delay. If you unzip the attached file into the root of
src
dir
and point web.xml at TestWicketApplication it should work with
1.3-beta3.
We
have tested on FF2 and IE6 and breaks. Quickest way it to get focus on
the
button and hold down return.
Please let me know if this is not in an easy format for you.
Is slightly different from our real code as I update the whole form as
I
can't target RepeatingView but wanted to keep the code as slim as
possible.
http://www.nabble.com/file/p12794149/test.zip test.zip
It's probably a good idea to open a JIRA issue for this and attach the
zip to that.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/threading-issues---continued-tf4400569.html#a12814523
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
Doh. Owe you a pint. My build from trunk didn't work because I had wrong version of logger... So I was running older code that was hanging about. Can't break it now :) Many thanks. If you are in London lots of nice warm English beer waiting for you! -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12814826 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LinkTree lazy loading possible?
I want to use LinkTree to represent a very very large hierarchy (the loading of the whole thing is expensive...). Is there an AJAX way of loading the children of a node just when clicking on the plus-icon for expanding? -- View this message in context: http://www.nabble.com/LinkTree-lazy-loading-possible--tf4493231.html#a12814684 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LinkTree lazy loading possible?
Heh, sorry, didn't read the entire question. This seems to be the right approach. -Matej On 9/21/07, swaroop belur [EMAIL PROTECTED] wrote: Initially when building the tree , just add a single child node to each first level of nodes u show You can mark this node as a indicator node or a busy node - this will allow the + sign to come up for the actual node. When u click on the + sign , representing the actual node , just remove the busy/ indicator node after all the actual children have been added ...(also just check if the indicator node is the only child - this way u will avoid another database hit for the second open click for the same node.) pixotec wrote: I want to use LinkTree to represent a very very large hierarchy (the loading of the whole thing is expensive...). Is there an AJAX way of loading the children of a node just when clicking on the plus-icon for expanding? -- View this message in context: http://www.nabble.com/LinkTree-lazy-loading-possible--tf4493231.html#a12814930 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LinkTree lazy loading possible?
Initially when building the tree , just add a single child node to each first level of nodes u show You can mark this node as a indicator node or a busy node - this will allow the + sign to come up for the actual node. When u click on the + sign , representing the actual node , just remove the busy/ indicator node after all the actual children have been added ...(also just check if the indicator node is the only child - this way u will avoid another database hit for the second open click for the same node.) pixotec wrote: I want to use LinkTree to represent a very very large hierarchy (the loading of the whole thing is expensive...). Is there an AJAX way of loading the children of a node just when clicking on the plus-icon for expanding? -- View this message in context: http://www.nabble.com/LinkTree-lazy-loading-possible--tf4493231.html#a12814930 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
So you tried it with latest trunk and it still doesn't work for you? I used FF2/IE7 on Vista. -Matej On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote: Still doesn't work for me. Can you give me a pointer to which change should fix things? What browser/OS did you use? Did you let the form get nice and big so it takes a while to render? Thanks for looking into it. Hope I'm not raising another red herring. Matej Knopp-2 wrote: Hi, I'm unable to reproduce this with latest trunk. I believe this has been already fixed by delaying the actual form serialization until the previous request finishes. Can you please test this with latest trunk? Unfurtunately, there are no current snapshots available so you'd have to build it from SVN. -Matej On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote: Thanks Eelco, https://issues.apache.org/jira/browse/WICKET-994 Have you had a chance to reproduce it? We tested with a few browsers but all in the same server env, although hard to see what difference that would make. Eelco Hillenius wrote: On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Matej, Sorry for the delay. If you unzip the attached file into the root of src dir and point web.xml at TestWicketApplication it should work with 1.3-beta3. We have tested on FF2 and IE6 and breaks. Quickest way it to get focus on the button and hold down return. Please let me know if this is not in an easy format for you. Is slightly different from our real code as I update the whole form as I can't target RepeatingView but wanted to keep the code as slim as possible. http://www.nabble.com/file/p12794149/test.zip test.zip It's probably a good idea to open a JIRA issue for this and attach the zip to that. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12812623 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/threading-issues---continued-tf4400569.html#a12814523 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LinkTree lazy loading possible?
Well, actually, I'm not sure how this would work, as you'd have to load the children asynchronously and then update the tree. That certainly isn't a trivial thing. I guess it would be better to replace the link with an indicatingajaxlink or something like that. -Matej On 9/21/07, swaroop belur [EMAIL PROTECTED] wrote: Initially when building the tree , just add a single child node to each first level of nodes u show You can mark this node as a indicator node or a busy node - this will allow the + sign to come up for the actual node. When u click on the + sign , representing the actual node , just remove the busy/ indicator node after all the actual children have been added ...(also just check if the indicator node is the only child - this way u will avoid another database hit for the second open click for the same node.) pixotec wrote: I want to use LinkTree to represent a very very large hierarchy (the loading of the whole thing is expensive...). Is there an AJAX way of loading the children of a node just when clicking on the plus-icon for expanding? -- View this message in context: http://www.nabble.com/LinkTree-lazy-loading-possible--tf4493231.html#a12814930 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RFE] getMarkupId()
This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12815038 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
Can you please submit a bug report. -Matej On 9/21/07, Alex Objelean [EMAIL PROTECTED] wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12815038 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LinkTree lazy loading possible?
I am doing the same thing. I have it working except for one problem. The loading works fine but so far I have not found a way to make the tree update its display when an item is added to the data. If nothing new is added to the dataset then every thing works fine. The main issue I found was that you only get the + symbol if the item has children. What I do it always load one more level than is actually displayed. So when click on the + I dont load the children I load the children's children. To do the loading I sub classed LinkTree and override thew onJunctionLinkClicked(AjaxRequestTarget target, TreeNode node) method. Still working on the display update when a new item is added to the part of the tree that is already displayed. Ian - Original Message From: pixotec [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Friday, 21 September, 2007 11:55:46 AM Subject: LinkTree lazy loading possible? I want to use LinkTree to represent a very very large hierarchy (the loading of the whole thing is expensive...). Is there an AJAX way of loading the children of a node just when clicking on the plus-icon for expanding? -- View this message in context: http://www.nabble.com/LinkTree-lazy-loading-possible--tf4493231.html#a12814684 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
Re: [RFE] getMarkupId()
JIRA issue created: https://issues.apache.org/jira/browse/WICKET-995 WICKET-995 Matej Knopp-2 wrote: Can you please submit a bug report. -Matej On 9/21/07, Alex Objelean [EMAIL PROTECTED] wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12815038 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12820409 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best practice
Thanks Martijn, I'll have a proper look when the project manager is away. Only just realised that WebMarkupContainer is meant for direct use, the name through me off for some reason. I've been doing all sort of things to make chunks of HTML conditional. Martijn Dashorst wrote: I learnt a lot of the datatable and its cousins. Try building your own toolbar and column implementation, then you'll see some very elegant code IMO. The wicket-examples are a good source, as is the phonebook application. Of course you could look at the wicket in action sources (http://wicketinaction.googlecode.com), but you may miss some context to appreciate the examples. The Wiki has links to a couple of open source products that use Wicket as their basis. One is jtrac (jtrac.info), I think Thies Edeling is also working on some open source time tracking management product. http://cwiki.apache.org/WICKET/#Index-OtherprojectsrelatedtoWicket Martijn On 9/20/07, Sam Hough [EMAIL PROTECTED] wrote: Where is the best place to look for examples of best practice component development? I'm falling into my own strange GWT style that probably isn't very wicket friendly. Which is probably why I'm struggling to enjoy having HTML and components. Anybody point at any part of wicket.jar or wicket-extensions.jar etc that they think I should study to get more into the Wicket way of doing things? -- View this message in context: http://www.nabble.com/best-practice-tf4487826.html#a12798065 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/best-practice-tf4487826.html#a12821373 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
When is the killer case for using id? Alex Objelean wrote: My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821479 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
In my application I extensively use the component generated id to perform some DOM updates on the client side, also for client-side validation. Also getting a DOM element by its ID is the fastest method comparing with finding it using it's css class. Sam Hough wrote: When is the killer case for using id? Alex Objelean wrote: My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821763 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821375 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
So you use it just because of the performance of the browser DOM? Not because it has to be unique? Are you using Ajax? ie forced to do setOutputMarkupId? We are and that is probably the biggest reason we are trying to avoid them. Alex Objelean wrote: In my application I extensively use the component generated id to perform some DOM updates on the client side, also for client-side validation. Also getting a DOM element by its ID is the fastest method comparing with finding it using it's css class. Sam Hough wrote: When is the killer case for using id? Alex Objelean wrote: My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821835 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
I dont' understand. You rely on the way how wicket generates IDs? Then your code is bound to break. If you really need a wicket component's id in javascript, you either override getMarkupId(), or pass the Id using javascript (e.g. label component assigning another component's id into javascript variable). -Matej On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote: So you use it just because of the performance of the browser DOM? Not because it has to be unique? Are you using Ajax? ie forced to do setOutputMarkupId? We are and that is probably the biggest reason we are trying to avoid them. Alex Objelean wrote: In my application I extensively use the component generated id to perform some DOM updates on the client side, also for client-side validation. Also getting a DOM element by its ID is the fastest method comparing with finding it using it's css class. Sam Hough wrote: When is the killer case for using id? Alex Objelean wrote: My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821835 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
Performance on the client side is very important when you are working with very large DOM (complex applications). The responsiveness of the application is very important in this cases. Yes, I'm using ajax. I don't find it as a big drawback to set the outputMarkupId to true when I need explicitly a component to have generated Id. Sam Hough wrote: So you use it just because of the performance of the browser DOM? Not because it has to be unique? Are you using Ajax? ie forced to do setOutputMarkupId? We are and that is probably the biggest reason we are trying to avoid them. Alex Objelean wrote: In my application I extensively use the component generated id to perform some DOM updates on the client side, also for client-side validation. Also getting a DOM element by its ID is the fastest method comparing with finding it using it's css class. Sam Hough wrote: When is the killer case for using id? Alex Objelean wrote: My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821875 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
What do you do about components in RepeatingView? (with numeric ids) So do you just make sure all your wicket ids are universally unique? So none that are just form, label, button etc? I quite like using button if only one within the container... What if you want to use the same component twice? Alex Objelean wrote: Performance on the client side is very important when you are working with very large DOM (complex applications). The responsiveness of the application is very important in this cases. Yes, I'm using ajax. I don't find it as a big drawback to set the outputMarkupId to true when I need explicitly a component to have generated Id. Sam Hough wrote: So you use it just because of the performance of the browser DOM? Not because it has to be unique? Are you using Ajax? ie forced to do setOutputMarkupId? We are and that is probably the biggest reason we are trying to avoid them. Alex Objelean wrote: In my application I extensively use the component generated id to perform some DOM updates on the client side, also for client-side validation. Also getting a DOM element by its ID is the fastest method comparing with finding it using it's css class. Sam Hough wrote: When is the killer case for using id? Alex Objelean wrote: My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12822009 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821245 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
Currently wicket guaranties unicity of the ID by appending a incremented number: markupId = getId() + page.getAutoIndex(); You will never have two wicket components with the same markupID. Sam Hough wrote: What do you do about components in RepeatingView? (with numeric ids) So do you just make sure all your wicket ids are universally unique? So none that are just form, label, button etc? I quite like using button if only one within the container... What if you want to use the same component twice? Alex Objelean wrote: Performance on the client side is very important when you are working with very large DOM (complex applications). The responsiveness of the application is very important in this cases. Yes, I'm using ajax. I don't find it as a big drawback to set the outputMarkupId to true when I need explicitly a component to have generated Id. Sam Hough wrote: So you use it just because of the performance of the browser DOM? Not because it has to be unique? Are you using Ajax? ie forced to do setOutputMarkupId? We are and that is probably the biggest reason we are trying to avoid them. Alex Objelean wrote: In my application I extensively use the component generated id to perform some DOM updates on the client side, also for client-side validation. Also getting a DOM element by its ID is the fastest method comparing with finding it using it's css class. Sam Hough wrote: When is the killer case for using id? Alex Objelean wrote: My personal opinion is that switching from id to class is not such a good idea, simply because the ID attributes guaranties (of course you can create two elements with same ID, but it is not the same as with class attribute) the unicity of the element, also you can find the element from js using document.getElementById... I hope that this radical change will not be made in the 1.3 release as it has a great impact on any application developed using the latest beta3 release. Also I think this issue should be discussed more between the core developers. Alex. Sam Hough wrote: We are going to stop using ids and move over to class as it make re-use easier and avoids a number of wicket problems with ids... The HTML monkey is not happy though. He reminds me of the Family Guy screaming monkey today. Alex Objelean wrote: This is about how wicket generates dynamically markupID. I have, for instance, the following markup component: input wicket:id=quantity.noOfUnits / The generated markupId for this component looks like the following: quantity.noOfUnits1232 . I suggest to escape any css valid specifiers from the generated markupId, by replacing them with something else (for instance '_' character). The problem appear when I am trying to identify the component by it's id using some js library (like jQuery) and as a consequence the result of this query: $(#quantity.noOfUnits1232) is invalid. Thank you! Alex. -- View this message in context: http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12822124 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EmailAddressValidator Issue
Ayodeji Aladejebi wrote: Isnt [EMAIL PROTECTED] not a valid email address, the Wicket EmailAddressValidator rejects it someone tell me that is not a valid email address That's not a valid e-mail address. ;-) Wicket is designed to cater for public web sites. On a public web site you most certainly don't want unqualified host names. If you need this for an intranet site or whatever, you can always implement your own validator - it's not exactly tricky. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
I was doing
SomeComponent(String id...) {
super(id);
setMarkupId(id);
setOutputMarkupId(true);
setOutputMarkupPlaceholderTag(true);
}
So we could know before runtime what the id would be. Obviously this sucks
because RepeatingView breaks it (so added regexp hack) and id passed to
component needs to be global unique rather than just unique within the
container.
Guess we really wanted the Wicket 2 getting the id from the HTML.
Matej Knopp-2 wrote:
I dont' understand. You rely on the way how wicket generates IDs? Then
your code is bound to break. If you really need a wicket component's
id in javascript, you either override getMarkupId(), or pass the Id
using javascript (e.g. label component assigning another component's
id into javascript variable).
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
So you use it just because of the performance of the browser DOM? Not
because
it has to be unique?
Are you using Ajax? ie forced to do setOutputMarkupId? We are and that is
probably the biggest reason we are trying to avoid them.
Alex Objelean wrote:
In my application I extensively use the component generated id to
perform
some DOM updates on the client side, also for client-side validation.
Also getting a DOM element by its ID is the fastest method comparing
with
finding it using it's css class.
Sam Hough wrote:
When is the killer case for using id?
Alex Objelean wrote:
My personal opinion is that switching from id to class is not such a
good idea, simply because the ID attributes guaranties (of course you
can create two elements with same ID, but it is not the same as with
class attribute) the unicity of the element, also you can find the
element from js using document.getElementById...
I hope that this radical change will not be made in the 1.3 release
as
it has a great impact on any application developed using the latest
beta3 release. Also I think this issue should be discussed more
between
the core developers.
Alex.
Sam Hough wrote:
We are going to stop using ids and move over to class as it make
re-use
easier and avoids a number of wicket problems with ids... The HTML
monkey is not happy though. He reminds me of the Family Guy
screaming
monkey today.
Alex Objelean wrote:
This is about how wicket generates dynamically markupID.
I have, for instance, the following markup component:
input wicket:id=quantity.noOfUnits /
The generated markupId for this component looks like the following:
quantity.noOfUnits1232 .
I suggest to escape any css valid specifiers from the generated
markupId, by replacing them with something else (for instance '_'
character).
The problem appear when I am trying to identify the component by
it's
id using some js library (like jQuery) and as a consequence the
result
of this query: $(#quantity.noOfUnits1232) is invalid.
Thank you!
Alex.
--
View this message in context:
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821835
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12822757
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
EmailAddressValidator Issue
Isnt [EMAIL PROTECTED] not a valid email address, the Wicket EmailAddressValidator rejects it someone tell me that is not a valid email address
Re: EmailAddressValidator Issue
I can't remember of the top of my head, but there is also the RfcCompliantEmailAddressValidator[1], which validates an email address according to the RFC. Frank [1]: http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/extensions/validation/validator/RfcCompliantEmailAddressValidator.html On 9/21/07, Ayodeji Aladejebi [EMAIL PROTECTED] wrote: Isnt [EMAIL PROTECTED] not a valid email address, the Wicket EmailAddressValidator rejects it someone tell me that is not a valid email address
Re: [RFE] getMarkupId()
Oooh. Interesting. I'll see if the html monkey likes it. Thanks.
Alex Objelean wrote:
Yes, I do rely on wicket generated ID. But it will never break because the
javascript code which use these ID is supplied with generated id. For
instance:
function doSomethingWithWicketComponent(config) {
var el = document.getElementById('#' + config.id);
//do something with el.
}
where config is JSON containing wicket markup id.
and call the function this way:
doSomethingWithWicketComponent({'id':/*here will be inserted dynamically
generated wicket markup ID*/});
This function is called when component is being rendered.
Generation of wicket markup ID helps very much in such situations, because
I do not want to hardcode ID in the markup, and also wicket guaranties the
unicity of the ID attribute.
Matej Knopp-2 wrote:
I dont' understand. You rely on the way how wicket generates IDs? Then
your code is bound to break. If you really need a wicket component's
id in javascript, you either override getMarkupId(), or pass the Id
using javascript (e.g. label component assigning another component's
id into javascript variable).
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
So you use it just because of the performance of the browser DOM? Not
because
it has to be unique?
Are you using Ajax? ie forced to do setOutputMarkupId? We are and that
is
probably the biggest reason we are trying to avoid them.
Alex Objelean wrote:
In my application I extensively use the component generated id to
perform
some DOM updates on the client side, also for client-side validation.
Also getting a DOM element by its ID is the fastest method comparing
with
finding it using it's css class.
Sam Hough wrote:
When is the killer case for using id?
Alex Objelean wrote:
My personal opinion is that switching from id to class is not such a
good idea, simply because the ID attributes guaranties (of course
you
can create two elements with same ID, but it is not the same as with
class attribute) the unicity of the element, also you can find the
element from js using document.getElementById...
I hope that this radical change will not be made in the 1.3 release
as
it has a great impact on any application developed using the latest
beta3 release. Also I think this issue should be discussed more
between
the core developers.
Alex.
Sam Hough wrote:
We are going to stop using ids and move over to class as it make
re-use
easier and avoids a number of wicket problems with ids... The HTML
monkey is not happy though. He reminds me of the Family Guy
screaming
monkey today.
Alex Objelean wrote:
This is about how wicket generates dynamically markupID.
I have, for instance, the following markup component:
input wicket:id=quantity.noOfUnits /
The generated markupId for this component looks like the
following:
quantity.noOfUnits1232 .
I suggest to escape any css valid specifiers from the generated
markupId, by replacing them with something else (for instance '_'
character).
The problem appear when I am trying to identify the component by
it's
id using some js library (like jQuery) and as a consequence the
result
of this query: $(#quantity.noOfUnits1232) is invalid.
Thank you!
Alex.
--
View this message in context:
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821835
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12822191
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep inserted data on AjaxTabbedPanel tab switching.
you have to override newlink on the tabbedpanel and return a submitlink instead also, really, for situations like this it doesnt make sense to use a server-side panel. use client side tabs like what jquery provides instead - it works much better with forms. -igor On 9/21/07, Fabio Fioretti [EMAIL PROTECTED] wrote: Hi all, I'm trying to build a data insertion page made up of a form containing an AjaxTabbedPanel with two panels. The submit button is global. I want to complete the fields in the two tabs and then submit them all in a single submit action. The problem is that, when I complete the first tab, switch to the second and then go back to the first, all inserted data are lost and all fields are blank again. All panels use compound property models over a single, page-global object. What am I doing wrong? What's the best way to keep inserted data when switching between tabs and then submit them all at once? Thanks for your time and suggestions, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
On 9/21/07, Matej Knopp [EMAIL PROTECTED] wrote: I dont' understand. You rely on the way how wicket generates IDs? Then your code is bound to break. If you really need a wicket component's id in javascript, you either override getMarkupId(), or pass the Id using javascript (e.g. label component assigning another component's id into javascript variable). You've got to be kidding me. You can just override getMarkupId() and avoid the mess of autogenerated wicket ids?? I never knew that!
JSP embedded in Wicket page, loaded in a popup window
I have successfully used Al Maw's technique for embedding legacy jsp content into a wicket page. When loading the page into the browser via address bar or another link, it seems to work great. However, if I attempt to load the page in a popup window the relative paths get broken. I can't seem to figure out why there would be a difference; when tracing through ServletWebRequest.getRelativePathPrefixToContextRoot() they seem to produce the same value, however in the popup's case, the images aren't displayed. I don't understand why using window.open to open a page vs using the address bar of the main browser should be having this effect. Would anyone care to take a shot at solving my issue or even hypothesizing what the problem is? Wicket 1.3.0-SNAPSHOT (revision 576365) IE 6 Tomcat 5.5.17 Thanks Chuck -- View this message in context: http://www.nabble.com/JSP-embedded-in-Wicket-page%2C-loaded-in-a-popup-window-tf4496759.html#a12823571 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
even with wicket2 getting the id from html...repeaters would break since the
id in the html is static, but for repeaters it needs to be unique...unless
you want all your items/rows to have the same id.
-igor
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
I was doing
SomeComponent(String id...) {
super(id);
setMarkupId(id);
setOutputMarkupId(true);
setOutputMarkupPlaceholderTag(true);
}
So we could know before runtime what the id would be. Obviously this sucks
because RepeatingView breaks it (so added regexp hack) and id passed to
component needs to be global unique rather than just unique within the
container.
Guess we really wanted the Wicket 2 getting the id from the HTML.
Matej Knopp-2 wrote:
I dont' understand. You rely on the way how wicket generates IDs? Then
your code is bound to break. If you really need a wicket component's
id in javascript, you either override getMarkupId(), or pass the Id
using javascript (e.g. label component assigning another component's
id into javascript variable).
-Matej
On 9/21/07, Sam Hough [EMAIL PROTECTED] wrote:
So you use it just because of the performance of the browser DOM? Not
because
it has to be unique?
Are you using Ajax? ie forced to do setOutputMarkupId? We are and that
is
probably the biggest reason we are trying to avoid them.
Alex Objelean wrote:
In my application I extensively use the component generated id to
perform
some DOM updates on the client side, also for client-side validation.
Also getting a DOM element by its ID is the fastest method comparing
with
finding it using it's css class.
Sam Hough wrote:
When is the killer case for using id?
Alex Objelean wrote:
My personal opinion is that switching from id to class is not such
a
good idea, simply because the ID attributes guaranties (of course
you
can create two elements with same ID, but it is not the same as
with
class attribute) the unicity of the element, also you can find the
element from js using document.getElementById...
I hope that this radical change will not be made in the 1.3 release
as
it has a great impact on any application developed using the latest
beta3 release. Also I think this issue should be discussed more
between
the core developers.
Alex.
Sam Hough wrote:
We are going to stop using ids and move over to class as it make
re-use
easier and avoids a number of wicket problems with ids... The HTML
monkey is not happy though. He reminds me of the Family Guy
screaming
monkey today.
Alex Objelean wrote:
This is about how wicket generates dynamically markupID.
I have, for instance, the following markup component:
input wicket:id=quantity.noOfUnits /
The generated markupId for this component looks like the
following:
quantity.noOfUnits1232 .
I suggest to escape any css valid specifiers from the generated
markupId, by replacing them with something else (for instance '_'
character).
The problem appear when I am trying to identify the component by
it's
id using some js library (like jQuery) and as a consequence the
result
of this query: $(#quantity.noOfUnits1232) is invalid.
Thank you!
Alex.
--
View this message in context:
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12821835
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12822757
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP embedded in Wicket page, loaded in a popup window
ChuckDeal wrote: I have successfully used Al Maw's technique for embedding legacy jsp content into a wicket page. When loading the page into the browser via address bar or another link, it seems to work great. However, if I attempt to load the page in a popup window the relative paths get broken. I can't seem to figure out why there would be a difference; when tracing through ServletWebRequest.getRelativePathPrefixToContextRoot() they seem to produce the same value, however in the popup's case, the images aren't displayed. I don't understand why using window.open to open a page vs using the address bar of the main browser should be having this effect. Would anyone care to take a shot at solving my issue or even hypothesizing what the problem is? Yep, you need to disable the automatic multiwindow support. In your Application.init(): getPageSettings().setAutomaticMultiWindowSupport(false); Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
you can, but then good luck making sure they are unique... -igor On 9/21/07, Ryan Sonnek [EMAIL PROTECTED] wrote: On 9/21/07, Matej Knopp [EMAIL PROTECTED] wrote: I dont' understand. You rely on the way how wicket generates IDs? Then your code is bound to break. If you really need a wicket component's id in javascript, you either override getMarkupId(), or pass the Id using javascript (e.g. label component assigning another component's id into javascript variable). You've got to be kidding me. You can just override getMarkupId() and avoid the mess of autogenerated wicket ids?? I never knew that!
Re: EmailAddressValidator Issue
its not even intranet, i was testing somewhere on my desktop offline (no internet) and I have apache JAMES for testing my mailing functions. for which Outlook and JavaMail were confortably routing the emails thru properly anyway its not an issue, i disabled the validator for the test thanks On 9/21/07, Al Maw [EMAIL PROTECTED] wrote: Ayodeji Aladejebi wrote: Isnt [EMAIL PROTECTED] not a valid email address, the Wicket EmailAddressValidator rejects it someone tell me that is not a valid email address That's not a valid e-mail address. ;-) Wicket is designed to cater for public web sites. On a public web site you most certainly don't want unqualified host names. If you need this for an intranet site or whatever, you can always implement your own validator - it's not exactly tricky. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
Yeah, if you do that then you have to make sure that it won't break when you e.g. put the component to page twice. -Matej On 9/21/07, Igor Vaynberg [EMAIL PROTECTED] wrote: you can, but then good luck making sure they are unique... -igor On 9/21/07, Ryan Sonnek [EMAIL PROTECTED] wrote: On 9/21/07, Matej Knopp [EMAIL PROTECTED] wrote: I dont' understand. You rely on the way how wicket generates IDs? Then your code is bound to break. If you really need a wicket component's id in javascript, you either override getMarkupId(), or pass the Id using javascript (e.g. label component assigning another component's id into javascript variable). You've got to be kidding me. You can just override getMarkupId() and avoid the mess of autogenerated wicket ids?? I never knew that! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible to validate file size prior to sending?
I have a form with a FileUploadField, where the maximum file size is fairly large (100-200MB). I set the maximum size using the form's: setMaxSize(Bytes.megabytes(200)); This works fine, as the form only gets processed when the file is under that size. However, if the file is over that size, the user is not notified until the upload completes, or at least gets beyond the limit. So if someone were to upload a 300 MB file, they won't find out that the file is too large until after they exceed 200 MB sent, which can be a long time. Can anything be done to validate the file size prior to exceeding the maximum file size? I think that if the file size is exceeded, the form never gets processed at all, so server side it seems like it would be out, but if I could add a client side validation in addition to the server side validation, that would be great. Has anyone else run into this? -- View this message in context: http://www.nabble.com/Possible-to-validate-file-size-prior-to-sending--tf4497198.html#a12825206 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
scaffolding in wicket
Many frameworks have this feature because it truly speed up development of a page especially the one which is commonly found in administration pages. Can we have this feature in wicket too?
StringResourceModel.toString()
hi, there seems to be a change in the current trunk to StringResourceModel.toString() - which before returned the localized String. now it returns some 'useful' information like StringResourceModel[key:CONTENTTYPE:date.published.description,default:null,params:] hmm. why was that changed? regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven advice appreciated
Use the dependencies report. It gives you exactly which dependency comes from where. I think it also generates which dependencies are dupes. mvn site should create such a report iirc. Maybe you also need to specify the report, but I'm a bit rusty on that part. Another goldmine is: mvn help:effective-pom I also suggest using the dependencyManagement part to specify the versions of each dependency, and just use the dependency bit to specify groupId and artifactId. Martijn On 9/21/07, mchack [EMAIL PROTECTED] wrote: I have a fairly large project working that users Spring/Hibernate with Wicket Spring annotations but was built using eclipse ide with manual specified dependencies. We want to move to Maven but I am having a hell of a time at it. The generate war contains many duplicate jars (different versions) and am not sure how to figure out where they are coming from. I assume that I have to specify proper exclusions. Does anyone have hints, advice, etc. that would point me in the right direction. I can see the future benefits of Maven but need to get over the inital hump. -Mike -- View this message in context: http://www.nabble.com/Maven-advice-appreciated-tf4497248.html#a12825376 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANN: beturtle.com launched
Looks great and congrats! Martijn On 9/21/07, Joe Toth [EMAIL PROTECTED] wrote: Hi Everyone, We just launched http://beTurtle.com/ - A 'green' social networking site. If your interested in healthy living, sustainable practices, have 'green' questions or just want to make some new friends, stop on by. Let us know what you think, we would really appreciate it. It runs on Spring2, Hibernate3, Wicket 1.3 plus many other open source projects. Without Wicket and the other frameworks I wouldn't have been able to develop the entire site so quickly. Thank you so much everyone for the great framework and answering any questions I had. Joe Toth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scaffolding in wicket
there is a crud panel in the wicketstuff repository made by igor. you can checkout the source here: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-crud/ Gerolf On 9/21/07, Otan [EMAIL PROTECTED] wrote: Many frameworks have this feature because it truly speed up development of a page especially the one which is commonly found in administration pages. Can we have this feature in wicket too?
Re: Embedding wicket in jsp error
I tried implementing the solution from your blog, and after a long struggle I finally got it working. . .or so I thought. Now my wicket links are throwing page expired errors. Maybe it has to do with the fact that the way I had to set it up, the pages with embedded JSP are running under the old servlet context rather than under the wicket context (the url's seem to bear that out, however it's still getting back to wicket when I click on them). However, some of the wicket links on my main wicket page (with no embedded JSP) were throwing page expired errors too, but not always. I haven't figured out yet when they will and when they won't. I may have to revert to the ugly, slow loading IFRAMEs solution, because nothing else seems to work for me. This comes out in the logs anytime I get the page expired error: DEBUG 2007-09-21 13:54:57,359 http.FilePageStore (getPage:504) - Error loading page 90,0 for the sessionid 0a080b5722b83ac0afe2682449908b03d150131b49d7 from disk java.lang.RuntimeException: Could not deserialize object using `org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory` object factory at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:410) at org.apache.wicket.protocol.http.FilePageStore.readPage(FilePageStore.java:541) at org.apache.wicket.protocol.http.FilePageStore.getPage(FilePageStore.java:484) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:192) at org.apache.wicket.Session.getPage(Session.java:725) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:427) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:126) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:713) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370) at com.evermind.server.http.ServletRequestDispatcher.unprivileged_forward(ServletRequestDispatcher.java:259) at com.evermind.server.http.ServletRequestDispatcher.access$100(ServletRequestDispatcher.java:51) at com.evermind.server.http.ServletRequestDispatcher$2.oc4jRun(ServletRequestDispatcher.java:193) at oracle.oc4j.security.OC4JSecurity.doPrivileged(OC4JSecurity.java:283) at com.evermind.server.http.ServletRequestDispatcher.forward(ServletRequestDispatcher.java:198) at gov.mi.mdch.event.EventHandlerBase._dispatch(EventHandlerBase.java:153) at gov.mi.mdch.event.EventHandlerBase.forward(EventHandlerBase.java:137) at gov.mi.mdch.event.Controller.doPost(Controller.java:128) at gov.mi.mdch.event.Controller.doGet(Controller.java:81) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at gov.mi.mdch.filter.ValidationFilter.doFilter(ValidationFilter.java:241) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:623) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370) at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:871) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:453) at com.evermind.server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:221) at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:122) at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:111) at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.StreamCorruptedException: unexpected block data at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1313) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at
Re: Maven advice appreciated
Just discovered the reporting thanks. I will also try the effective pom report. Sounds cool. -Mike Martijn Dashorst wrote: Use the dependencies report. It gives you exactly which dependency comes from where. I think it also generates which dependencies are dupes. mvn site should create such a report iirc. Maybe you also need to specify the report, but I'm a bit rusty on that part. Another goldmine is: mvn help:effective-pom I also suggest using the dependencyManagement part to specify the versions of each dependency, and just use the dependency bit to specify groupId and artifactId. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-advice-appreciated-tf4497248.html#a12827577 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANN: beturtle.com launched
Nice layout, but only with firefox. It looks horrible with konquerrer. Sorry to say that. But hope you interessted in it :-). Cheers Per - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
On 9/21/07, hillj2 [EMAIL PROTECTED] wrote: Also are there any other issues with using HttpSessionStore besides losing back button support? Since I'm already forced to use ONE_PASS_RENDER (for now), I've already lost that support (haven't I?). ONE_PASS_RENDER does not kill back button support, but does provoke that blasted repost on back button for form submissions. So it prevents the double submit problem. The HttpSessionStore is the default store for wicket 1.2 and prior. It only limits the number of pages that are stored per session for backbutton support. So you will be able to press back, but not unlimited as with the disk based store. As for the serialization errors, somehow either you don't read the log too well, or you have a misconfigured Wicket. To fix them, you should return to the Disk store: it will report exactly what is wrong. Do you run the application in development mode on your local box? If so, you should see things like the following in your log: ERROR - Objects - Error serializing object class wicket.in.action.HomePage Field hierarchy is: 0 [class=wicket.in.action.HomePage, path=0] children [class=[Lorg.apache.wicket.Component;] children[0] [class=org.apache.wicket.markup.html.basic.Label, path=0:name] model [class=org.apache.wicket.model.PropertyModel] target [class=wicket.in.action.User] - field that is not serializable at org.apache.wicket.util.io.SerializableChecker.check() at org.apache.wicket.util.io.SerializableChecker.checkFields() Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
My mistake. I noticed there was a typo in my newSessionStore() declaration which caused it not to be called (obviously). One of the better additions to the JDK in my opinion were the @Override tags. If you use those (and e.g. use your IDE's autocomplete function) you would have avoided this in the first place. Also are there any other issues with using HttpSessionStore besides losing back button support? Since I'm already forced to use ONE_PASS_RENDER (for now), I've already lost that support (haven't I?). You're not loosing back button support, it is just limited to the last few entries (which is configurable) whereas the SLCSS is in principle unlimited. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANN: beturtle.com launched
super nice! i love turtles. WeaZeLb0y wrote: Hi Everyone, We just launched http://beTurtle.com/ - A 'green' social networking site. If your interested in healthy living, sustainable practices, have 'green' questions or just want to make some new friends, stop on by. Let us know what you think, we would really appreciate it. It runs on Spring2, Hibernate3, Wicket 1.3 plus many other open source projects. Without Wicket and the other frameworks I wouldn't have been able to develop the entire site so quickly. Thank you so much everyone for the great framework and answering any questions I had. Joe Toth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/ANN%3A-beturtle.com-launched-tf4491387.html#a12829553 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding wicket in jsp error
Martijn Dashorst wrote: ONE_PASS_RENDER does not kill back button support, but does provoke that blasted repost on back button for form submissions. So it prevents the double submit problem. Right, of course. I knew that. :) Martijn Dashorst wrote: The HttpSessionStore is the default store for wicket 1.2 and prior. It only limits the number of pages that are stored per session for backbutton support. So you will be able to press back, but not unlimited as with the disk based store. Well that doesn't bother me. The users really shouldn't need to press the back button at all, so only having a limited number of previous pages shouldn't be a problem. Martijn Dashorst wrote: As for the serialization errors, somehow either you don't read the log too well, or you have a misconfigured Wicket. To fix them, you should return to the Disk store: it will report exactly what is wrong. Do you run the application in development mode on your local box? If so, you should see things like the following in your log: ERROR - Objects - Error serializing object class wicket.in.action.HomePage Field hierarchy is: 0 [class=wicket.in.action.HomePage, path=0] children [class=[Lorg.apache.wicket.Component;] children[0] [class=org.apache.wicket.markup.html.basic.Label, path=0:name] model [class=org.apache.wicket.model.PropertyModel] target [class=wicket.in.action.User] - field that is not serializable at org.apache.wicket.util.io.SerializableChecker.check() at org.apache.wicket.util.io.SerializableChecker.checkFields() Well I thought what I put in the original post was all that I could see in the logs regarding this issue. I'll try again and see if I notice more, or fiddle with some of the config, if I can figure out what to change. I probably won't get to this until Mon though. I'll let you know what I discover. Thanks, Joel -- View this message in context: http://www.nabble.com/Embedding-wicket-in-jsp-error-tf4488872.html#a12829549 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Failing test org.apache.wicket.markup.html.image.ImageTest
Hi, am I the only one catching this on a mvn clean install? [...] [surefire] Running org.apache.wicket.markup.html.image.ImageTest [surefire] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,055 sec FAILURE !! [...] According to svn the ImageTest.java wasn't touched for over three month svn info ./jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java [...] Letzte geänderte Rev: 543933 Letztes Änderungsdatum: 2007-06-03 18:18:27 +0200 (So, 03 Jun 2007) [...] and I've definitely seen it running in that timespan. Following patch would fix the test, but fixing that doesn't feel right. Somehow I don't get it. Martin Index: ./jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java === --- /home/fnk64/tmp/wicket-1.x/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java (Revision 578270) +++ /home/fnk64/tmp/wicket-1.x/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java (Arbeitskopie) @@ -62,6 +62,6 @@ tester.clickLink(goUS); tester.startPage(Home.class); - tester.assertContains(src=\resources/org.apache.wicket.markup.html.image.Home/Beer_en_US.gif\); + tester.assertContains(src=\resources/org.apache.wicket.markup.html.image.Home/Beer.gif\); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Failing test org.apache.wicket.markup.html.image.ImageTest
Hi, I'm not 100% sure, but after a quick look, I'd say that it's possible that the following fix changed the test return. Cross-posted to dev@ to see if anyone's got any comments... Revision: 575980 Author: ivaynberg Date: 15/09/2007 22:09:08 Message: WICKET-974: Image#getResource always returns null even if there is a resource http://issues.apache.org/jira/browse/WICKET-974 Modified : /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/image/Image.java Modified : /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/image/resource/LocalizedImageResource.java /Gwyn On Friday, September 21, 2007, 10:29:57 PM, Martin [EMAIL PROTECTED] wrote: Hi, am I the only one catching this on a mvn clean install? [...] [surefire] Running org.apache.wicket.markup.html.image.ImageTest [surefire] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,055 sec FAILURE !! [...] According to svn the ImageTest.java wasn't touched for over three month svn info ./jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java [...] Letzte geänderte Rev: 543933 Letztes Änderungsdatum: 2007-06-03 18:18:27 +0200 (So, 03 Jun 2007) [...] and I've definitely seen it running in that timespan. Following patch would fix the test, but fixing that doesn't feel right. Somehow I don't get it. Martin Index: ./jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java === --- /home/fnk64/tmp/wicket-1.x/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java (Revision 578270) +++ /home/fnk64/tmp/wicket-1.x/jdk-1.4/wicket/src/test/java/org/apache/wicket/markup/html/image/ImageTest.java (Arbeitskopie) @@ -62,6 +62,6 @@ tester.clickLink(goUS); tester.startPage(Home.class); - tester.assertContains(src=\resources/org.apache.wicket.markup.html.image.Home/Beer_en_US.gif\); + tester.assertContains(src=\resources/org.apache.wicket.markup.html.image.Home/Beer.gif\); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket consulting/contracting/outsourcing
Hi, Can anyone provide me with pointers to individuals or companies providing Wicket consulting/contracting or outsourced personnel? We can provide those services but we're based in Sydney, Australia. Maybe that's not such a problem with us all living together in this global village these days. We've worked with a Boston company before back in 2000. These days of Skype and video conferencing would make that even easier and less expensive. Regards, Chris Colman Technical Directory http://stepaheadsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CheckGroup form submission bug
Nick Busey wrote: So I've got what appears to be a very strange bug. I have a CheckGroup with a ListView of Checks among other things. Everything seems to work fine if you render the form and submit it without any errors the first time. However, if you hit any errors (like not selecting any Checks), and are bounced back to the form with an error rendered, if you select a Check and re-submit it, it dies with the following error: I can't reproduce this behavior. My code seems to work fine. Try it. -- View this message in context: http://www.nabble.com/CheckGroup-form-submission-bug-tf4489122.html#a12832939 Sent from the Wicket - User mailing list archive at Nabble.com.
Re: Minneapolis Wicket Users Group
On 9/21/07, Craig Lenzen [EMAIL PROTECTED] wrote: Any interest in a Wicket User Group meeting in Minneapolis? Count me in! Register here, http://cwiki.apache.org/WICKET/community-meetups.html http://cwiki.apache.org/WICKET/community-meetups.html
Re: Versioning Problems With DataTable, Spring Hibernate
carloc wrote:
public CCTIDetachableModel extends Loadable DetachableModel {
private String id;
private Integer version;
private Dao dao;
public Object load() {
MyObject myobj = dao.get(id);
if (version == null) {
version = myobj.getVersion();
}
else if (!myobject.getVersion().equals(version)) {
throw new MyVersionMismatchException(MyObject.class, id, version);
}
return myobj;
}
}
The code shouldn't compile as myobject is undefined:
... if (!myobject.getVersion().equals(version)) {
--
View this message in context:
http://www.nabble.com/Versioning-Problems-With-DataTable%2C-Spring-Hibernate-tf4484198.html#a12833349
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom AjaxFormSubmitBehavior
NateBot2000 wrote: I created an extension of AjaxSubmitLink that accepts a static html form id string as an argument (AjaxFormSubmitBehavior forces setOutputMarkupId on the Form by default). In so doing, I extended AjaxFormSubmitBehavior... and then I add this custom behavior to my custom AjaxSubmitLink. My question is: what is the proper way of removing / overriding the old AjaxFormSubmitBehavior that's added by the parent class? I am currently doing a MarkupContainer.removeAll() on the link before I add my custom behavior (this seems to work fine), but that seems wrong and potentially dangerous. Why not just extend AbstractSubmitLink and add your behavior to it? -- View this message in context: http://www.nabble.com/Custom-AjaxFormSubmitBehavior-tf4481784.html#a12833535 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best approach for list items: discrete markup or panels?
I have a number of pages that display a list of items and am wondering about the best approach to implementing them in Wicket. To date I have created a single panel that contains the list and the markup for that panel holds the discrete markup elements for the fields in each item of the list. Another approach could be to create an individual panel that is responsible for providing the data for the items in the list. Then the list page markup just has a reference to that panel instead of holding the discrete item fields itself. I'm just wondering if anyone has used the later approach and with what success. It probably means there is a little bit of extra work up front to create the list panel markup and its class but then I end up with a reusable panel that I would easily be dropped into other pages as required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't access Javascript/CSS when in servletMode
Adam Koch wrote: In fact, I couldn't get the JS/CSS in any way when using the servlet. I tried putting the JS in my app.war in these directories: / (root) /classes/com/.../someJS.js /WEB-INF/classes/com/.../someJS.js (same directory as Class and html) Are you mapping the Wicket servlet to root? Try mapping it to something else like /app. -- View this message in context: http://www.nabble.com/Can%27t-access-Javascript-CSS-when-in-servletMode-tf4481265.html#a12833582 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
