base pages without kludge initialization
Everyone,
Let's say I want to make a base page, extending WebPage. I want to make
it flexible so that subpages may initialize either using a model or page
parameters. So I try to do this:
protected BasePage()
{
this(null, null);
}
protected BasePage(final IModel? model)
{
this(null, model);
}
protected BasePage(final PageParameters parameters)
{
this(parameters, null);
}
private BasePage(final PageParameters parameters, IModel? model)
{
super(null, model);
//initialize stuff here
Obviously I can't do this, because several of the WebPage (and ancestor)
constructors are marked private. I'm forced to do this:
protected BasePage()
{
super();
//initialize stuff here
}
protected BasePage(final IModel? model)
{
super(model);
//initialize stuff here
}
protected BasePage(final PageParameters parameters)
{
super(parameters);
//initialize stuff here
}
private BasePage(final PageParameters parameters, IModel? model)
{
super(parameters, model);
//initialize stuff here
Look at all the duplicated initialization code! Sure, I could create a
local initialize() method that each of the methods delegate to, but not
only is that ugly it prevents me from making my class variables final
(because final variable must be initialized in the constructor).
Couldn't the parent classes be a little more lenient, allowing access to
all the constructors, making child classes meant to be base pages more
elegant?
Garret
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
need not-submitting button
Everyone, There needs to be a way to have a Button that does not perform an HTML submit, such as Link, which allows onClick() handling instead of onSubmit(). Your first response will probably tell me to RTFM and setDefaultFormProcessing(false). :) But hear me out. If I have a submit button button wicket:id=cancel type=submit... in the HTML, and set an input as required in the HTML, then modern browsers will be so nice as to pop up a little flyover bubble pointing right at the field in question, and say, You need to fill in this field. The problem is that the cancel button button wicket:id=cancel type=submit... will also cause this browser response, even with setDefaultFormProcessing(false) in the code, because the browser does this validation before submission even occurs. I can short-circuit browser validation on cancellation by using button wicket:id=cancel type=reset... in the HTML, but then my Button.onSubmit() code in Java won't get called! I can work around this by using Link in the code instead of Button, using button with type=reset in the HTML, and overriding onClick() in the Java code. But it seems strange (and semantically silly) to use a Button in one instance and Link in another, just to get different submit activity---that is, unless all Wicket Buttons are really SubmitButtons. In fact, that's what I'm getting to: a Button is a button, and it should have an onClick() method just like a link. Only a specialized SubmitButton should have an onSubmit(). A normal Button shouldn't cause automatic submission of the form just because I used a Button instead of a Link. You may say that I should turn off required in the HTML so as to disable all browser validation, and let Wicket take care of all validation for consistency. There is some validity to this, but the flyover notifications the browser uses for empty required fields are so pretty and so much more user-friendly... Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: need not-submitting button
On 7/9/2014 11:11 PM, Martin Grigorov wrote: There are three types of HTML buttons: submit, reset and button. You need the third one: button type=buttonLike Link/button. Ah, yes---I was a little HTML-rusty and the button type slipped my mind. Unfortunately, using type=button my Button.onClick() method still does not get called. Only when I change it to type=submit does my Button.onClick() method get called. For now I'm going to turn off the required attributes and let Wicket do all the validation on the server side, which in this case is probably better, anyway. But I still think it is a Wicket shortcoming that does not allow a Button to receive input from a button unless the button is set to submit so that the browser thinks the form will be submitted, even if Wicket decided to skip form processing on the server side. A Button click should be able to be detected regardless of whether it submits the form or not in the HTML, in my opinion. Cheers, Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: base pages without kludge initialization
On 7/10/2014 3:43 AM, Martin Grigorov wrote:
I
think
org.apache.wicket.Page#Page(org.apache.wicket.request.mapper.parameter.PageParameters,
org.apache.wicket.model.IModel?) is private to make it explicit that a
page with PageParameters is bookmarkable and possibly stateless, and a Page
with IModel is not bookmarkable and stateful.
That makes sense. But that issue can be taken care of easily enough
using a precondition:
protected BasePage(final PageParameters parameters, final IModel?
model)
{
super(parameters);
checkArgument(parameters == null || model == null, Must not
provide both parameters and a model.);
There is a very simple workaround for you:
super(parameters);
setDefaultModel(model);
this.myConstant1 = ...
this.myConstant2 = ...
Ah, thanks! I will use that.
Still, it seems a shame to explicitly set the default model (which goes
through a lot of change-reporting logic), when we could have provided it
to the constructor. I note that even the Page constructor uses the sort
of constructor chaining that I want to do:
protected Page()
{
this(null, null);
}
protected Page(final IModel? model)
{
this(null, model);
}
protected Page(final PageParameters parameters)
{
this(parameters, null);
}
private Page(final PageParameters parameters, IModel? model)
{
But because the ultimate constructor is marked private, even WebPage is
forced to go through the common-initialization drudgery:
protected WebPage(final IModel? model)
{
super(model);
commonInit();
}
etc.
I recommend Wicket modify the Page ultimate constructor to be protected,
and add a simple precondition to keep it from being accidentally misused:
protected Page(final PageParameters parameters, final IModel? model)
{
super(parameters);
checkArgument(parameters == null || model == null, Must not
provide both parameters and a model.);
Cheers,
Garret
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
best model for editing a list of items in a table?
I have my own WidgetManager interface, and I want to edit a list of
widgets in a table. I create an IDataProviderWidget:
final IDataProviderWidget widgetProvider = new
ListDataProviderWidget() {
@Override
protected ListWidget getData() {
return widgetManager.getWidgets());
}
};
Then I populate my table like so:
final DataViewWidget widgetDataView = new
DataViewWidget(widget, widgetProvider) {
@Override
protected void populateItem(final ItemWidget item) {
The problem is when one of the buttons in a widget table row uses the
WidgetManager to delete a Widget. yet the table doesn't get updated in
that request.
What's the appropriate way to populate a table so that a button in the
table can delete one of the items backing the row of a table? Should I
be using a ListView with a LoadableDetachableModel instead? See
http://stackoverflow.com/questions/4353732/wicket-listview-not-refreshing .
Thanks,
Garret
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: best model for editing a list of items in a table?
Ah, never mind. I found the problem. The code below will work, except
for the Delete action I was using an Ajax button (with confirmation).
I needed to add the following after deletion so that it will get
refreshed after the Ajax processing:
target.addComponent(MyPage.this);
Best,
Garret
On 7/10/2014 4:59 PM, Garret Wilson wrote:
I have my own WidgetManager interface, and I want to edit a list of
widgets in a table. I create an IDataProviderWidget:
final IDataProviderWidget widgetProvider = new
ListDataProviderWidget() {
@Override
protected ListWidget getData() {
return widgetManager.getWidgets());
}
};
Then I populate my table like so:
final DataViewWidget widgetDataView = new
DataViewWidget(widget, widgetProvider) {
@Override
protected void populateItem(final ItemWidget item) {
The problem is when one of the buttons in a widget table row uses the
WidgetManager to delete a Widget. yet the table doesn't get updated in
that request.
What's the appropriate way to populate a table so that a button in the
table can delete one of the items backing the row of a table? Should I
be using a ListView with a LoadableDetachableModel instead? See
http://stackoverflow.com/questions/4353732/wicket-listview-not-refreshing
.
Thanks,
Garret
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
resource encoding troubles
I have Wicket 7.0.0-M2 running on embedded Jetty, which is correctly returning a content type of UTF-8 for my Wicket page: Date: Thu, 28 Aug 2014 15:37:52 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache Cache-Control: no-cache, no-store Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Server: Jetty(9.1.0.v20131115) I have a properties file FooterPanel.properties that contains the following line (encoded in ISO-8859-1, as properties files unfortunately require): copyright=© 2014 Example, Inc. FooterPanel.html is encoded in UTF-8, has the appropriate XML prolog, and contains the following reference to the property resource: ?xml version=1.0 encoding=utf-8? ... psmallwicket:message key=copyright© Example/wicket:message/small/p When this all is rendered, here is what I see in Firefox 31 and Chrome 37: � 2014 Example, Inc. I thought I had all the correct encoding indicators at each stage in the pipeline. But somebody blinked. Where is the problem? Garret
Re: resource encoding troubles
Please explain explicitly what you are trying to say. I don't see how that link is relevant. * I am using FooterPanel.properties. * Java properties files, as per the specification http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html, are (and always have been) encoded in ISO-8859-1. (I don't like this either, but that's how it is.) * My FooBar.properties file is encoded in ISO-8859-1, and there is nothing to indicate otherwise. There is no BOM present. There is no utf in the filename. * The character © is U+00A9, which takes up exactly one byte in ISO-8859-1. It is correctly encoded in FooterPanel.properties. So what specifically are you implying by the link? Are you implying that Wicket does not support the Java properties specification? Are you implying I did something incorrectly in my properties file? Please elaborate. Garret On 8/28/2014 9:57 AM, Francois Meillet wrote: Look at http://apache-wicket.1842946.n4.nabble.com/How-to-localize-options-in-drop-down-tt4661751.html#a4661768 François Meillet Formation Wicket - Développement Wicket Le 28 août 2014 à 17:47, Garret Wilson gar...@globalmentor.com a écrit : I have Wicket 7.0.0-M2 running on embedded Jetty, which is correctly returning a content type of UTF-8 for my Wicket page: Date: Thu, 28 Aug 2014 15:37:52 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache Cache-Control: no-cache, no-store Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Server: Jetty(9.1.0.v20131115) I have a properties file FooterPanel.properties that contains the following line (encoded in ISO-8859-1, as properties files unfortunately require): copyright=© 2014 Example, Inc. FooterPanel.html is encoded in UTF-8, has the appropriate XML prolog, and contains the following reference to the property resource: ?xml version=1.0 encoding=utf-8? ... psmallwicket:message key=copyright© Example/wicket:message/small/p When this all is rendered, here is what I see in Firefox 31 and Chrome 37: � 2014 Example, Inc. I thought I had all the correct encoding indicators at each stage in the pipeline. But somebody blinked. Where is the problem? Garret
Re: resource encoding troubles
So are you saying that Wicket does not support ISO-8859-1 properties files that adhere do the Java standard? Or are you saying, I don't know what the problem is, I'm just giving you a workaround? If so, I appreciate the workaround tip, but that still doesn't explain what the problem is. I'm the sort of person who doesn't like to wave my hands as we say. I like to find the source of the problem. My configuration, as far as I can tell, is correct. Moreover, it is technically more correct than the *.utf8.properties approach, as my approach follows the standard. In fact my approach should be the default. So does anyone know why my configuration does not work? What am I doing wrong? Sincerely, Garret On 8/28/2014 10:18 AM, Francois Meillet wrote: use *.utf8.properties François Meillet Formation Wicket - Développement Wicket Le 28 août 2014 à 17:47, Garret Wilson gar...@globalmentor.com a écrit : I have Wicket 7.0.0-M2 running on embedded Jetty, which is correctly returning a content type of UTF-8 for my Wicket page: Date: Thu, 28 Aug 2014 15:37:52 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache Cache-Control: no-cache, no-store Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Server: Jetty(9.1.0.v20131115) I have a properties file FooterPanel.properties that contains the following line (encoded in ISO-8859-1, as properties files unfortunately require): copyright=© 2014 Example, Inc. FooterPanel.html is encoded in UTF-8, has the appropriate XML prolog, and contains the following reference to the property resource: ?xml version=1.0 encoding=utf-8? ... psmallwicket:message key=copyright© Example/wicket:message/small/p When this all is rendered, here is what I see in Firefox 31 and Chrome 37: � 2014 Example, Inc. I thought I had all the correct encoding indicators at each stage in the pipeline. But somebody blinked. Where is the problem? Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: resource encoding troubles
Exactly! Quoting from the page you provided: Java uses the standard character set ISO 8859-11 to encode text files like properties files. ... (Note that this is a typo above---the author meant to say ISO 8859-1, not ISO 8859-11. The link to http://en.wikipedia.org/wiki/ISO/IEC_8859-1 in the text is correct, however.) So according to that description, my FooterPanel.properties file is expected to be encoded in ISO-8859-1. And indeed it is, as I have repeatedly explained. So I ask again: what is wrong with my current configuration? Garret On 8/28/2014 10:25 AM, Francois Meillet wrote: http://wicket.apache.org/guide/guide/ François Meillet Formation Wicket - Développement Wicket Le 28 août 2014 à 19:24, Garret Wilson gar...@globalmentor.com a écrit : So are you saying that Wicket does not support ISO-8859-1 properties files that adhere do the Java standard? Or are you saying, I don't know what the problem is, I'm just giving you a workaround? If so, I appreciate the workaround tip, but that still doesn't explain what the problem is. I'm the sort of person who doesn't like to wave my hands as we say. I like to find the source of the problem. My configuration, as far as I can tell, is correct. Moreover, it is technically more correct than the *.utf8.properties approach, as my approach follows the standard. In fact my approach should be the default. So does anyone know why my configuration does not work? What am I doing wrong? Sincerely, Garret On 8/28/2014 10:18 AM, Francois Meillet wrote: use *.utf8.properties François Meillet Formation Wicket - Développement Wicket Le 28 août 2014 à 17:47, Garret Wilson gar...@globalmentor.com a écrit : I have Wicket 7.0.0-M2 running on embedded Jetty, which is correctly returning a content type of UTF-8 for my Wicket page: Date: Thu, 28 Aug 2014 15:37:52 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache Cache-Control: no-cache, no-store Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Server: Jetty(9.1.0.v20131115) I have a properties file FooterPanel.properties that contains the following line (encoded in ISO-8859-1, as properties files unfortunately require): copyright=© 2014 Example, Inc. FooterPanel.html is encoded in UTF-8, has the appropriate XML prolog, and contains the following reference to the property resource: ?xml version=1.0 encoding=utf-8? ... psmallwicket:message key=copyright© Example/wicket:message/small/p When this all is rendered, here is what I see in Firefox 31 and Chrome 37: � 2014 Example, Inc. I thought I had all the correct encoding indicators at each stage in the pipeline. But somebody blinked. Where is the problem? Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: resource encoding troubles
I appreciate all the workarounds suggested. But no one has addressed the core issue: Is this a Wicket bug, or am I using standard property files incorrectly? Garret On 8/28/2014 10:42 AM, Andrea Del Bene wrote: Have you tried using directly unicode character? i.e.: copyright=\u00A9 2014 Example, Inc. If you don't want to use unicode characters you should use an xml file as bundle file. Exactly! Quoting from the page you provided: Java uses the standard character set ISO 8859-11 to encode text files like properties files. ... (Note that this is a typo above---the author meant to say ISO 8859-1, not ISO 8859-11. The link to http://en.wikipedia.org/wiki/ISO/IEC_8859-1 in the text is correct, however.) So according to that description, my FooterPanel.properties file is expected to be encoded in ISO-8859-1. And indeed it is, as I have repeatedly explained. So I ask again: what is wrong with my current configuration? Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: resource encoding troubles
On 8/28/2014 10:53 AM, Stefan Renz wrote: ... if I read your original post correctly, you have not used ISO-8859-1 encoding in your property file, as I clearly see a (C) symbol. Since when is © (U+00A9) not part of ISO-8859-1? http://en.wikipedia.org/wiki/ISO/IEC_8859-1 Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: resource encoding troubles
On 8/28/2014 11:14 AM, Andrea Del Bene wrote: It's just an encoding conflict: your properties uses ISO-8859-1, your page UTF-8. The result is a bad rendering, as you can see. When Java designers decided to adopt ISO-8859-1 they didn't consider most of the Asian languages... PS: just as a personal advice, try to be less rude in your answers ;) Andrea, I'm sorry, I'll really try. My answers were probably terse (short and to the point), and you probably sense a frustration on my part with the lack of basic understanding in the software development world on the fundamentals of software encoding. For example, your answer seems to assume that some function simply loads two sets of bytes and merges them together. That's not what happens at all. (Or at least I hope that's not what happens---it would indicate that the coder had no idea how to approach the task.) In fact their are two layers to the encoding stack: the byte-level processing, and the character level processing. The Java Properties class should correctly take the bytes in the character file and do the ISO 8859-1 encoding, producing a character stream to be parsed. This is already implemented in Java, and has been for well over a decade, I believe. Similarly, an XML processor will take the bytes in an XML file and transform them based upon the encoding (in this case, UTF-8) and produce a stream of characters. All XML processors are required to be able to perform this transformation, and have been for well over a decade. Now that bother input sources produce data and the character level, the original byte-level encoding is irrelevant. At the character level, there is no encoding conflict, because there is no encoding. (There exists the in-memory encoding used by the JVM, but that's irrelevant to the discussion and will certainly be the same for all strings used.) Thus the two input streams can be mixed together without worry of encoding. If this is not what happens within Wicket, there is a software bug---but not an encoding conflict. I recommend you start by reading read http://www.joelonsoftware.com/articles/Unicode.html . If you have any questions, I'll be happy to answer any specific questions. I apologize again for being brusk, but I'll do my best to explain things if others honestly have questions. Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: resource encoding troubles
On 8/28/2014 12:08 PM, Sven Meier wrote: ... My configuration, as far as I can tell, is correct. From what you've written, I'd agree. You should create a quickstart. This will easily allow us to find a possible bug. Better than that, I'd like to trace down the bug, fix it, and file a patch. But currently I'm blocked from working with Wicket on Eclipse https://issues.apache.org/jira/browse/WICKET-5649. Garret
Re: resource encoding troubles
Hi, all. Thanks Andrew for that attempt to reproduce this. I have
verified this on Wicket 6.16.0 and 7.0.0-M2.
I have checked out the latest code from
https://git-wip-us.apache.org/repos/asf/wicket.git . I was going to
trace this down in the code, but then I was stopped in my tracks with an
Eclipse m2e bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=371618
that won't even let me clean/compile the project. Argg!! Always
something, huh?
But I did start looking in the code. IsoPropertiesFileLoader looks
completely OK; it uses Properties.load(InputStream), and the file even
indicates that the input encoding must be ISO-8859-1. Not much could go
wrong there. I back-referenced the calls up the chain to
WicketMessageTagHandler.onComponentTag(Component, ComponentTag), and it
looks straightforward there---but that's for message tags, not message body.
I investigated downwards from WicketMessageResolver.resolve(...) (which
I presume is what is at play here), which has this code:
MessageContainer label = new MessageContainer(id, messageKey);
The MessageContainer.onComponentTagBody(...) simply looks up the value
and calls renderMessage(), which in turn does some complicated ${var}
replacement using MapVariableInterpolator and then write out the result
using getResponse().write(text). Unless MapVariableInterpolator messes
up the value during variable replacement (but there are no variables to
replace in this situation), then on the surface everything looks OK.
So I decided to do an experiment; I changed the HTML to this:
pThis a © copyright. smallwicket:message key=copyrightdummy
text/wicket:message/small/p
And I changed the properties to this:
copyright=This a © copyright.
Here is what was produced:
This a © copyright. This a � copyright.
So something is going on here in the generation of the included message,
because as you can see the content from XML gets produced correctly. It
turns out http://stackoverflow.com/a/6367675/421049 that � is the
UTF-8 sequence for U+FFFD, which is the Unicode replacement character
when an invalid UTF-8 sequence is encountered. And of course, the
copyright symbol U+00A9 is not a valid UTF-8 value, even thought it is
fine as part of ISO-8859-1.
So here is the problem: something is taking the string generated by the
message (which was parsed correctly from the properties file) and
writing it to the output stream, not in UTF-8 as it should, but in some
other encoding. If I were to guess here, I would say that the embedded
message is writing out in Windows cp1252 (more or less ISO-8859-1),
which is my default encoding (which would explain why Andrew didn't see
this, if his system is Linux and the default encoding happens to be
UTF-8 for example). This seems incorrect to me; the embedded message
should know that it is writing into a UTF-8 output stream and should use
that instead of the system encoding.
Remember that I can't even compile the code because of an m2e bug, so
all of this is highly conjectural, just from visually inspecting the
code and doing a few experiments. But I have a hunch that if you switch
to a machine that has a default system encoding that isn't UTF-8, you'll
reproduce this issue. And I further predict that if you trace through
the code, the embedded wicket:message tag is incorrectly injecting its
contents using the system encoding rather than the entire output stream
encoding (however that is configured in Wicket). Put another way,
whatever is producing the bytes from the main HTML page is using UTF-8
(as it should), but whatever is taking the message tag output is
spitting out its bytes using cp1252 or something similar.
As soon as I can get Eclipse to be happier with the Wicket build, I'll
give you some more exact details. But I'll have to take a break and get
back to main my work for a while---we're nearing a big deadline and I
have some actual functionality to implement! :)
Thanks again for investigating, Andrew.
Garret
On 8/28/2014 8:22 PM, Andrew Geery wrote:
I created a Wicket quickstart (from
http://wicket.apache.org/start/quickstart.html) [this is Wicket 6.16.0] and
made two simple changes:
1) I created a HomePage.properties file, encoded as ISO-8859-1, with a
single line as per the example above: copyright=© 2014 Example, Inc.
2) I added a line to the HomePage.html file as per the example
above: psmallwicket:message key=copyright©
Example/wicket:message/small/p
The content is served as UTF-8 and the copyright symbol is rendered
correctly on the page.
It doesn't look like the problem is in Wicket (at least not in 6.16). I
guess your next steps would be to verify that you get the same results and,
assuming that you do, start removing things from your page that has the
problem until you find an element that is causing the problem.
Thanks
Andrew
On Thu, Aug 28, 2014 at 5:38 PM, Garret Wilson gar...@globalmentor.com
wrote:
On 8/28/2014 12:08 PM, Sven Meier
Re: resource encoding troubles
On 8/29/2014 9:15 AM, Garret Wilson wrote: ... So here is the problem: something is taking the string generated by the message (which was parsed correctly from the properties file) and writing it to the output stream, not in UTF-8 as it should, but in some other encoding. Hmmm... the sequence of events would have to be a little more complicated than that. If somehow the properties file were being read as UTF-8 (it shouldn't be), then when U+00A9 it would be mapped to the replacement character U+FFFD. Then if /that/ UTF-8 stream were in turn interpreted as cp1252/ISO-8859-1, then it would produce the sequence �, which I'm seeing. But that would require two levels of errors, it would seem. And the code looks like the properties file is being read correctly in IsoPropertiesFilePropertiesLoader. (Maybe something is being cached in the system encoding, and then being read from the cache using UTF-8.) So I can sense the problem here, but I don't yet see where it's happening in the code. As soon as I'm able to trace the code, I would imagine I could find it pretty quickly. Garret
Wicket meet-and-greet at JavaOne 2014?
Hi, all. I'm traveling at the moment, but I plan to be back in San Francisco around the start of JavaOne. Do any Wicket users plan on being in town for the conference? Would you like me to organize a meet-and-greet at a local restaurant or even (depending on the number of guests) at my place? Perhaps it would be helpful and fun to put some faces with some names on the list. Let me know if you like the idea. Best, Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: resource encoding troubles
I'm finally able to trace the code, and this is getting very odd.
I use a hex editor, and the bytes in the properties file are ... 3D A9
... (=©), just as I expect.
But when I trace through the Wicket code, the
IsoPropertiesFilePropertiesLoader is using a UrlResourceStream which
uses a URLConnection, which under the hood uses a BufferedInputStream to
a FileInputStream. This in turn is wrapped in another
BufferedInputStream. When the Properties class (from
IsoPropertiesFilePropertiesLoader) parses the file, the internal
Properties.LineReader reads into its inByteBuf variable the sequence ...
3D EF BF BD ...! As mentioned below, EF BF BD is the UTF-8 sequence for
U+FFFD, which is the Unicode replacement character.
So it appears that the UrlResourceStream/URLConnection for the
properties file is somewhere trying to open the stream as UTF-8.
Therefore the A9 © character gets converted into the EF BF BD sequence
before it even gets to the parser in
IsoPropertiesFilePropertiesLoader/Properties!
But what would be causing the UrlResourceStream/URLConnection to default
to UTF-8 when opening my properties file? This seems to be the answer
that lies at the heart of this problem. Is there some Wicket or Java
setting that is defaulting a URLConnection to use UTF-8 encoding? (As I
mentioned above, the underlying input stream seems to be a
FileInputStream wrapped in two layers of BufferedInputStream.)
Garret
On 8/29/2014 1:15 PM, Garret Wilson wrote:
Hi, all. Thanks Andrew for that attempt to reproduce this. I have
verified this on Wicket 6.16.0 and 7.0.0-M2.
I have checked out the latest code from
https://git-wip-us.apache.org/repos/asf/wicket.git . I was going to
trace this down in the code, but then I was stopped in my tracks with
an Eclipse m2e bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371618 that won't even
let me clean/compile the project. Argg!! Always something, huh?
But I did start looking in the code. IsoPropertiesFileLoader looks
completely OK; it uses Properties.load(InputStream), and the file even
indicates that the input encoding must be ISO-8859-1. Not much could
go wrong there. I back-referenced the calls up the chain to
WicketMessageTagHandler.onComponentTag(Component, ComponentTag), and
it looks straightforward there---but that's for message tags, not
message body.
I investigated downwards from WicketMessageResolver.resolve(...)
(which I presume is what is at play here), which has this code:
MessageContainer label = new MessageContainer(id, messageKey);
The MessageContainer.onComponentTagBody(...) simply looks up the value
and calls renderMessage(), which in turn does some complicated ${var}
replacement using MapVariableInterpolator and then write out the
result using getResponse().write(text). Unless MapVariableInterpolator
messes up the value during variable replacement (but there are no
variables to replace in this situation), then on the surface
everything looks OK.
So I decided to do an experiment; I changed the HTML to this:
pThis a © copyright. smallwicket:message key=copyrightdummy
text/wicket:message/small/p
And I changed the properties to this:
copyright=This a © copyright.
Here is what was produced:
This a © copyright. This a � copyright.
So something is going on here in the generation of the included
message, because as you can see the content from XML gets produced
correctly. It turns out http://stackoverflow.com/a/6367675/421049
that � is the UTF-8 sequence for U+FFFD, which is the Unicode
replacement character when an invalid UTF-8 sequence is encountered.
And of course, the copyright symbol U+00A9 is not a valid UTF-8 value,
even thought it is fine as part of ISO-8859-1.
So here is the problem: something is taking the string generated by
the message (which was parsed correctly from the properties file) and
writing it to the output stream, not in UTF-8 as it should, but in
some other encoding. If I were to guess here, I would say that the
embedded message is writing out in Windows cp1252 (more or less
ISO-8859-1), which is my default encoding (which would explain why
Andrew didn't see this, if his system is Linux and the default
encoding happens to be UTF-8 for example). This seems incorrect to me;
the embedded message should know that it is writing into a UTF-8
output stream and should use that instead of the system encoding.
Remember that I can't even compile the code because of an m2e bug, so
all of this is highly conjectural, just from visually inspecting the
code and doing a few experiments. But I have a hunch that if you
switch to a machine that has a default system encoding that isn't
UTF-8, you'll reproduce this issue. And I further predict that if you
trace through the code, the embedded wicket:message tag is
incorrectly injecting its contents using the system encoding rather
than the entire output stream encoding (however that is configured in
Wicket). Put
Re: resource encoding troubles
Hahahaha! I found the problem!
When I looked at the HomePage.properties file in a hex editor, I was
looking at the HomePage.properties file in my source tree. But remember
that this file isn't the one that Wicket loads! After a Maven build,
Wicket will load the HomePage.properties file that Maven copies the
target directory!! (I should have paid closer attention to the URL used
by URLConnection.) And sure enough, when I open that copied version of
HomePage.properties, it contains the sequence EF BF BD! In other words,
when Maven copied the HomePage.properties file from the source tree to
the target directory, it must have opened it up as UTF-8, converting the
A9 © character (not valid UTF-8) into EF BF BD, the UTF-8 sequence for
U+FFFD, the Unicode replacement character. Thus when Wicket came along
to read the file from the target directory, it (correctly) loaded it as
ISO-8859-1, interpreting EF BF BD as three characters, �.
But why did Maven use UTF-8 when it copied my HomePage.properties source
file to the target directory? Ummm... because I told it to, sort of:
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
includes
include**/*.properties/include
/includes
Apparently when Maven copies resources using filtering, it opens and
parses them using the ${project.build.sourceEncoding} setting, which of
course I had set to UTF-8. I probably I need to set the encoding
parameter of the maven-resources-plugin
http://maven.apache.org/plugins/maven-resources-plugin/copy-resources-mojo.html#encoding.
Argg!! So much pain and agony for such a tiny mistake! But I'm glad I
found it. I'll fix it... another day. Right now I'm going to grab some
tequila and celebrate!!
Have a great rest of the weekend, everybody!
Garret
On 9/20/2014 4:14 PM, Garret Wilson wrote:
I'm finally able to trace the code, and this is getting very odd.
I use a hex editor, and the bytes in the properties file are ... 3D A9
... (=©), just as I expect.
But when I trace through the Wicket code, the
IsoPropertiesFilePropertiesLoader is using a UrlResourceStream which
uses a URLConnection, which under the hood uses a BufferedInputStream
to a FileInputStream. This in turn is wrapped in another
BufferedInputStream. When the Properties class (from
IsoPropertiesFilePropertiesLoader) parses the file, the internal
Properties.LineReader reads into its inByteBuf variable the sequence
... 3D EF BF BD ...! As mentioned below, EF BF BD is the UTF-8
sequence for U+FFFD, which is the Unicode replacement character.
So it appears that the UrlResourceStream/URLConnection for the
properties file is somewhere trying to open the stream as UTF-8.
Therefore the A9 © character gets converted into the EF BF BD sequence
before it even gets to the parser in
IsoPropertiesFilePropertiesLoader/Properties!
But what would be causing the UrlResourceStream/URLConnection to
default to UTF-8 when opening my properties file? This seems to be the
answer that lies at the heart of this problem. Is there some Wicket or
Java setting that is defaulting a URLConnection to use UTF-8 encoding?
(As I mentioned above, the underlying input stream seems to be a
FileInputStream wrapped in two layers of BufferedInputStream.)
Garret
On 8/29/2014 1:15 PM, Garret Wilson wrote:
Hi, all. Thanks Andrew for that attempt to reproduce this. I have
verified this on Wicket 6.16.0 and 7.0.0-M2.
I have checked out the latest code from
https://git-wip-us.apache.org/repos/asf/wicket.git . I was going to
trace this down in the code, but then I was stopped in my tracks with
an Eclipse m2e bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371618 that won't
even let me clean/compile the project. Argg!! Always something, huh?
But I did start looking in the code. IsoPropertiesFileLoader looks
completely OK; it uses Properties.load(InputStream), and the file
even indicates that the input encoding must be ISO-8859-1. Not much
could go wrong there. I back-referenced the calls up the chain to
WicketMessageTagHandler.onComponentTag(Component, ComponentTag), and
it looks straightforward there---but that's for message tags, not
message body.
I investigated downwards from WicketMessageResolver.resolve(...)
(which I presume is what is at play here), which has this code:
MessageContainer label = new MessageContainer(id, messageKey);
The MessageContainer.onComponentTagBody(...) simply looks up the
value and calls renderMessage(), which in turn does some complicated
${var} replacement using MapVariableInterpolator and then write out
the result using getResponse().write(text). Unless
MapVariableInterpolator messes up the value during variable
replacement (but there are no variables to replace in this
situation), then on the surface everything looks OK.
So I
turning off page versioning
Can someone explain to me exactly how page versioning works, and how to turn it off? I have a page StagingPage that contains a file uploader. This page is interesting in that when you upload some files with Button1, the page lists the files on the page and keeps them in a collection until you hit Button2, at which point the pages does Some Other Really Interesting Thing with the files. In other words, the page acts like a staging area for files, allowing you to 1) upload files and then 2) do something with them. I get this number on the end of the URLs which, from the page versioning and caching reference documentation http://wicket.apache.org/guide/guide/versioningCaching.html, seems to indicate the version of the page. I don't want this. I just want there to be one version of the page (even though it is stateful). The back button can go to the previous page; I don't care. So I turn off versioning in StagingPage with: setVersioned(false); But I still get numbers at the end of the StagingPage URL. Worse, back and forward in my browser goes between apparently two versions of the page (one with the Choose Files button selecting files, and one without)---but the number in the URL doesn't change! Worse still, when I remove the number and reload the URL without the number, Wicket puts the number back but first increments the number! Now back and forward cycle between numbered URLs. I thought setVersioned(false) was supposed to turn all that off? In my own Guise framework, each page has a single component instance tree on the back end. Whatever you do at that URL, whenever you come back to it it will be just like you left it. Granted, there are several drawbacks such as memory consumption; Guise can learn a lot from Wicket in how the latter can serialize each page between requests, and versioning can be very useful in some situations. But here I just want a stateful page that has one single version---the current version. I don't want it to remember any previous versions. And I don't want numbers on the end of the URL. How can I turn off versioning for real? Thanks, Garret
Re: turning off page versioning
OMG. What a sad email to wake up to. :( Let me let all that digest for a while. I never would have imagined a situation this dire. Imagine if every time you went to Facebook, it generated a new https://www.facebook.com/jdoe?124154451 version! So basically Facebook could never use Wicket without rewriting the whole page caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't even think of a single site that functions like Wicket, incrementing some page version counter every time you interact with the page, so that you can go back to other versions. (Users don't want to go back to other versions! They may want to go back to other /pages/ at different URLs, but they realize that interacting with a single pages changes the state of that page---they don't expect that other versions are kept around somewhere.) Continuing my scenario I outlined earlier, I have an HTML page called MenuPage, which has wicket:linka href=StagingPage.html..., the target page of which functions as I explained below. Every time the user goes to the MenuPage and clicks on the link, you're saying that Wicket will generate a new version of StagingPage in the cache, even with setVersioned(false)? It will generate a new ...StagingPage.html?23423414 URL? There is no way to turn that off... without essentially rewriting the whole Wicket page request and caching mechanism?? This is not good news. I'm not ranting, I'm crying. Garret On 9/23/2014 8:24 AM, Martin Grigorov wrote: Hi, In short, to accomplish all this you will need several custom impls of Wicket interfaces. 1) custom IRequestMapper that just ignores PageInfo when generating the url for IPageRequestHandler. Search in the archives for NoVersionRequestMapper 2) a completely new IPageManager (interface!) that works with ClassPage instead of with Integer (pageId) So everytime a url is mapped to a page class you should use it to load the Page instance for this class In details: By design only stateless pages do not have the pageId in the url! If a request without pageId comes then a completely new page instance is created. By using something like NoVersionRequestMapper (not supported officially!) only the url for the browser address bar will miss the pageId (see PageAndComponentInfo class), but the pageId is in all link/form urls so clicking/submitting still works. But if the user refreshes the page (F5) then the state is lost! About Page#setVersioned(boolean) This tells Wicket to not increment the pageId after an interaction with the page. A pageId is associated with the page when it is instantiated, but any link click, form submit, etc. won't create a new version of the page. The final result is that every interaction (i.e. state change) with the page will lead to overriding the old one in the page stores. Wicket's IPageStore/IDataStore use API like: put(String sessionId, int pageId, byte[] serializedPage). At the end of every request cycle all rendered stateful pages are stored. If the pageId doesn't change then some old serializedPage would be overriden. For your requirements you will need an API like: put(String sessionId, ClassPage pageClass, byte[] serializedPage) and byte [] get(String sessionId, ClassPage pageClass). You can create a IPageManager wrapper that maps sessionId+pageId to pageClass and use that pageClass with custom IMyPageStore and IMyDataStore impls. (Just an idea out of my mind.) Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson gar...@globalmentor.com wrote: Can someone explain to me exactly how page versioning works, and how to turn it off? I have a page StagingPage that contains a file uploader. This page is interesting in that when you upload some files with Button1, the page lists the files on the page and keeps them in a collection until you hit Button2, at which point the pages does Some Other Really Interesting Thing with the files. In other words, the page acts like a staging area for files, allowing you to 1) upload files and then 2) do something with them. I get this number on the end of the URLs which, from the page versioning and caching reference documentation http://wicket.apache.org/ guide/guide/versioningCaching.html, seems to indicate the version of the page. I don't want this. I just want there to be one version of the page (even though it is stateful). The back button can go to the previous page; I don't care. So I turn off versioning in StagingPage with: setVersioned(false); But I still get numbers at the end of the StagingPage URL. Worse, back and forward in my browser goes between apparently two versions of the page (one with the Choose Files button selecting files, and one without)---but the number in the URL doesn't change! Worse still, when I remove the number and reload the URL without the number, Wicket puts the number back but first increments the number! Now back and forward cycle between numbered
Re: turning off page versioning
On 9/23/2014 12:08 PM, Martin Grigorov wrote: On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson gar...@globalmentor.com wrote: OMG. What a sad email to wake up to. :( Let me let all that digest for a while. I never would have imagined a situation this dire. Imagine if every time you went to Facebook, it generated a new https://www.facebook.com/jdoe?124154451 version! So basically Facebook could never use Wicket without rewriting the whole page caching scheme. Or this particular url (https://www.facebook.com/jdoe?124154451) returns 404, but otherwise Facebook renders completely different content on page refresh (and I'm OK with that!) Ah, I wasn't clear. I meant, imagine if Facebook was running on Wicket. Each time you go to https://www.facebook.com/jdoe, it would redirect you to https://www.facebook.com/jdoe?1. Imagine if you went there again and it redirected you to https://www.facebook.com/jdoe?2. Imagine if you clicked Like on somebody's picture, and it redirectred you to https://www.facebook.com/jdoe?3. But it still kept https://www.facebook.com/jdoe?2 in memory, so that when you hit Back you'd see the picture before you liked it. Soon you'd have https://www.facebook.com/jdoe?124154451... What is the actual problem ? The number in the url ? Yes. Or that a new page instance is created ? ...and yes. And both of those together cause even more problems, because not only are new page instances created, the user can navigate among them. I'm not denying that versioned pages may be a useful concept for some use cases (even though I can't think of any offhand). I'm just saying it's not my use case, and I had assumed throughout development on our project that I could just turn it off by calling setVersioned(false). Your email this morning informed me that I had been under an incorrect assumption, and that made me sad. Imagine this: PageA initial state renders PanelA and a LinkA. Clicking on LinkA PanelA is replaced with PanelB. case 1) with the pageId in the url if you refresh the page then you will still see PanelB in the page case 2) without the pageId you will see PanelA, because a new page instance is created Now imagine that Wicket stores pages by type. It's not necessarily by type---it's by mounted URL. Maybe you mount the same type at various URLs; they would all be kept track of separately. This is how Guise does it. (I'm not saying Oh, Guise is better than everything. I'm just using it as an example reference here. It does some things better. It does some things worse. It functions like I'm describing now because that's the only thing I thought of when I wrote it.) Each mount point has a single version that is changed as the user interacts with it. Granted, this causes some problems when multiple browser tabs are opened with the same page; in the future I hope to address this, but it's not trivial. Guise started out with the assumption that the user would only have one tab opened for a page. But in this example, yeah, a Wicket page type equates to a single URL mount point. I was being pedantic. Once the user clicks LinkA how (s)he will be able to see the initial state with PanelA again ? Why would the user expect or want to see PanelA again? Didn't (s)he just click on the link that said remove panel A and add panel B? If the user wants to see PanelA again, (s)he clicks on the link that says put panel A back! Apparently Wicket thinks the browser back button is an undo button. But in my mind it's not---it's a back button that goes to the previous page. If you're still on the same page but you've changed that page, then you see the new version of the page! Imagine that you're on Facebook, and you click on the button that says unfriend Jane Doe (that is, don't be friends anymore with Jane Doe). What happens when you hit the back button? Do you expect to get Jane Doe back as a friend? Hahahah! Sorry, please forgive me for laughing at my own example. It's been a long, exhausting day---allow me a bit of humor before heading to bed. Anyway, I hope you see my point. Like I said, maybe versioning has its use cases. It's just not /my/ use case, and I want to turn it off. Best, Garret
Re: turning off page versioning
On 9/24/2014 4:28 AM, Martin Grigorov wrote: ... Apparently Wicket thinks the browser back button is an undo button. But in my mind it's not---it's a back button that goes to the previous page. If you're still on the same page but you've changed that page, then you see the new version of the page! This is not 100% correct. Going back will tell Wicket to load some previous page version. But it is your code logic that decides what to show. If you use dynamic model then you will ask the DB whether the current user is a friend with Jane Doe and it will return the current state of affairs. Wicket renders pages with cache disabled so #onConfigure, #onBeforeRender, #onRender, #onAfterRender, onDetach are called and your application logic decides what exactly to render. So you're saying that if I'm careful to use all dynamic models (even overriding isVisible() for components to dynamically query whether they should be visible), then my web application will wind up with many versions of the same page serialized on disk somewhere, all with different URL queries, and the user can navigate among them, but when rendered they will all show 100% the same data? Yeah, I definitely want to turn that off. Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: turning off page versioning
On 9/24/2014 9:26 AM, Martijn Dashorst wrote: On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson gar...@globalmentor.com wrote: I'm not denying that versioned pages may be a useful concept for some use cases (even though I can't think of any offhand). Persioning is a very useful concept and used in many applications. You are just focussing on your particular use case for today and not thinking of broader issues that we have tackled for about a decade. Take google's search page with the pagination at the bottom. Click on 2, click on back. What do you expect? go back to the page before you searched google? Or go back to page 1? But note that in your example you're not talking about the version of the page. You're pointing to a /navigation control/, which of course I would expect to interact with navigation. Notice that when you page back and forth, you actually change the URL query (e.g. start=10). So you're not changing the version of the page---you're actually modifying the query you send to the page, and of course you can navigate among different page queries. In fact Wicket already has a totally separate mechanism for sending queries to pages through page parameters, exactly like Google is doing. I am completely in favor of sending page query parameters in the URL when I want to specify what data should be retrieved from a query, and for the user to navigate among queries. But I still (in my use case) don't have a need for that same query page to be versioned. Garret
Re: turning off page versioning
On 9/24/2014 11:18 AM, Martijn Dashorst wrote: ... And ranting about how stupid we are for having page versions doesn't help either. Hey, wait a minute. Where did that come from? That sort of hurts my feelings. I brought up this topic, and I've said throughout this discussion that versioning may have its use cases, but it's just not what I need at the moment, and I simply asked for a way to turn it off. That was sort of a cheap shot as we say, Martijn. I never said anyone was stupid. I asked a simple, honest developer question about how to turn off a feature. I was very disappointed to learn that it couldn't be turned off. But I tried to make clear I wasn't angry at anyone specifically nor was I questioning anybody's competence. I think that comment was totally unfair. Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket meet-and-greet at JavaOne 2014?
It turns out that I'll still be out of the country trying to address a few things, so I'm going to miss JavaOne altogether. But if any of you is ever in San Francisco at any time, please drop me a note and we can grab a drink and chat about web application frameworks. Best, Garret On 9/8/2014 8:17 PM, Garret Wilson wrote: Hi, all. I'm traveling at the moment, but I plan to be back in San Francisco around the start of JavaOne. Do any Wicket users plan on being in town for the conference? Would you like me to organize a meet-and-greet at a local restaurant or even (depending on the number of guests) at my place? Perhaps it would be helpful and fun to put some faces with some names on the list. Let me know if you like the idea. Best, Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
unable to find property UploadProgressBar.starting
Friends, I have a Wicket page using the upload progress bar: span wicket:id=progress[[upload progress bar]]/span form.add(new UploadProgressBar(progress, form, fileUpload)); Dependencies are declared normally in Maven: dependency groupIdorg.apache.wicket/groupId artifactIdwicket-core/artifactId version7.0.0-M3/version /dependency dependency groupIdorg.apache.wicket/groupId artifactIdwicket-auth-roles/artifactId version7.0.0-M3/version /dependency dependency groupIdorg.apache.wicket/groupId artifactIdwicket-extensions/artifactId version7.0.0-M3/version /dependency We're using embedded Jetty 9.1.0.v20131115. Running from my IDE (Eclipse) this works just fine. But when our team creates a jar file and distributes the application with an installer, just tried to browser to the page in question gives us a MissingResourceException: Unable to find property: 'UploadProgressBar.starting' (see below). No doubt there's something simple I'm forgetting. Any suggestions? Here's the stack trace: 2014-09-22 07:40:49 ERROR (DefaultExceptionMapper) [2014-09-22 07:40:49,433] - org.apache.wicket.DefaultExceptionMapper. internalMap(DefaultExceptionMapper.java:128): Unexpected error occurred org.apache.wicket.WicketRuntimeException: Exception in rendering component: [HtmlHeaderContainer [Component id = _header _0]] at org.apache.wicket.Component.internalRenderComponent(Component.java:2566) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1550) at org.apache.wicket.Component.internalRender(Component.java:2357) at org.apache.wicket.Component.render(Component.java:2285) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1418) at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1611) at org.apache.wicket.Page.onRender(Page.java:879) at org.apache.wicket.markup.html.WebPage.onRender(WebPage.java:142) at org.apache.wicket.Component.internalRender(Component.java:2357) at org.apache.wicket.Component.render(Component.java:2285) at org.apache.wicket.Page.renderPage(Page.java:1018) at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:122) at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:247) at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:837) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:284) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1539) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:524) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:544) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1110) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:453) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1044) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:459) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:280) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:229) at org.eclipse.jetty.io.AbstractConnection$1.run(AbstractConnection.java:505) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.MissingResourceException: Unable to find property: 'UploadProgressBar.starting' for
Re: unable to find property UploadProgressBar.starting
On 10/1/2014 12:33 PM, Martin Grigorov wrote: Hi, Do you by chance manipulate the list of IStringResourceLoader's in DEPLOYMENT mode ? I don't think I touched anything related to IStringResourceLoader. The only thing I've done relating to modes is this: //turn on Wicket development mode if in debug mode final String wicketConfiguration = Debug.isDebug() ? development : deployment; filterHolder.setInitParameter(configuration, wicketConfiguration); In other words, in embedded Jetty, if we've started up specifying a debug mode (using a system variable), then I set the Wicket configuration to development; otherwise, I set it to deployment. Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: unable to find property UploadProgressBar.starting
I think I've found the source of the problem (even though I don't understand the internal details). Our installer creates an uber-JAR that has all the dependencies exploded and then placed inside a single JAR file. I looked inside wicket-extensions-7.0.0-M3.jar, and it has a file wicket.properties /in the root of the JAR file!/ Unfortunately, wicket-core-7.0.0-M3.jar (and likely other Wicket JARs) also have a wicket.properties file in their root as well. As you might guess, these have conflicting values: initializer=org.apache.wicket.extensions.Initializer initializer=org.apache.wicket.Initializer So when we create our uber-JAR only one of these wicket.properties files wins and gets placed in the uber-JAR. The one we happen to have now contains initializer=org.apache.wicket.Initializer. I will check with the installer team to see if we can distribute the application with all its dependencies as separate JARs rather than an uber-JAR. But on Wicket's side, is it really a good practice to stick some file in the root directory of a JAR, outside of any package, with a name you expect to be identical across JARs but with different contents? I naively would imagine that some better approach exists. Garret On 10/1/2014 1:22 PM, Martin Grigorov wrote: The .properties file is packed inside wicket-extensions.jar, not in his application. I have no other ideas but to attach a remote debugger to org.apache.wicket.resource.loader.InitializerStringResourceLoader#loadStringResource(java.lang.Class?, java.lang.String, java.util.Locale, java.lang.String, java.lang.String) and set condition on the key parameter to be equal to the missing resource key. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Oct 1, 2014 at 5:55 PM, Andrew Geery andrew.ge...@gmail.com wrote: As a sanity check, is the property file with the property UploadProgressBar.starting in the jar file? Perhaps it didn't get copied over by the Maven build process into the jar but the IDE was properly copying it over... Andrew On Wed, Oct 1, 2014 at 11:38 AM, Garret Wilson gar...@globalmentor.com wrote: On 10/1/2014 12:33 PM, Martin Grigorov wrote: Hi, Do you by chance manipulate the list of IStringResourceLoader's in DEPLOYMENT mode ? I don't think I touched anything related to IStringResourceLoader. The only thing I've done relating to modes is this: //turn on Wicket development mode if in debug mode final String wicketConfiguration = Debug.isDebug() ? development : deployment; filterHolder.setInitParameter(configuration, wicketConfiguration); In other words, in embedded Jetty, if we've started up specifying a debug mode (using a system variable), then I set the Wicket configuration to development; otherwise, I set it to deployment. Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: unable to find property UploadProgressBar.starting
On 10/1/2014 3:31 PM, Martin Grigorov wrote: Apache Isis uses http://simplericity.org/jetty-console/jetty-console-maven-plugin/ to generate an executable .jar that contains all dependencies in WEB-INF/lib/ folder inside. Exactly as you need it. Yeah, in another subproject I had already created a .zip with all the dependency JARs. I have instructed to the person creating the product installer to do the same for the subproject that uses Wicket, so that should probably be taken care of shortly. I was just wanted to give feedback, though, that perhaps there is a better way to do this IIinitializer thing. About IIinitializer: this is the simple plugin system Wicket uses. It loads all /wicket.properties from the root of the classpath and executes the IInitializer implementations. If wicket.properties is not in the root (or another predefined location) then Wicket should do full scan of the classpath to find it. This may be expensive! * Maybe a better place for these files would be inside /META-INF/wicket or something. * Maybe rather than using the same filename, you could name it based upon the package+class, e.g. org.apache.wicket.extensions.Initializer.properties. Then the plugin system could simply look for all the /META-INF/wicket/*.properties files. That wouldn't be expensive at all, and it would cause no conflicts. Plus it wouldn't clutter the root classpath with clashing filenames. I don't claim to know anything about this IIinitializer system, other than it causes a problem under a certain use case. I'm just offering brainstorming suggestions for improvement. ... I don't know what you use to merge the making the uberjar but maven-shade-plugin provides hooks to merge such files. Yeah, there are several options. I think we have that covered, now that we know what the problem was. I hope some of my feedback was helpful. A workaround is to register and call the initializer in your code... I'll keep that in mind as a last resort, thanks. Garret
Re: unable to find property UploadProgressBar.starting
On 10/1/2014 5:17 PM, Martin Grigorov wrote: ... Are you aware of JDK APIs (e.g. ClassLoader) or Servlet APIs (e.g. SevletContext) that make it simple to find the list of resources in a folder in the classpath ? E.g. give me a list of all files with extension '.properties' in /META-INF/wicket/ ? Hmmm... not offhand. That was the brainstorming part. ;) I don't claim to know anything about this IIinitializer system, other than it causes a problem under a certain use case. I'm just offering brainstorming suggestions for improvement. Suggestions and feedback (especially negative!) are always welcome! Now let's find a technical solution that doesn't cost much! Assign me a JIRA item and I'll look into it more, I promise. :D OK, I imagine once my team gets the installer code to use separate dependency JARs all will be OK even under the current system. I'm back to my project now. Thanks for the tips. Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: unable to find property UploadProgressBar.starting
I just wanted to report back and say that, after our installer team updated the distribution to maintain the individual JARs (and thus not overwrite the files with clashing filenames), that solved the problem! Thanks to Martin Grigorov and Andrew Geery for helping point me in the direction of the problem. Garret On 10/1/2014 1:04 PM, Garret Wilson wrote: I think I've found the source of the problem (even though I don't understand the internal details). Our installer creates an uber-JAR that has all the dependencies exploded and then placed inside a single JAR file. I looked inside wicket-extensions-7.0.0-M3.jar, and it has a file wicket.properties /in the root of the JAR file!/ Unfortunately, wicket-core-7.0.0-M3.jar (and likely other Wicket JARs) also have a wicket.properties file in their root as well. As you might guess, these have conflicting values: initializer=org.apache.wicket.extensions.Initializer initializer=org.apache.wicket.Initializer So when we create our uber-JAR only one of these wicket.properties files wins and gets placed in the uber-JAR. The one we happen to have now contains initializer=org.apache.wicket.Initializer. I will check with the installer team to see if we can distribute the application with all its dependencies as separate JARs rather than an uber-JAR. But on Wicket's side, is it really a good practice to stick some file in the root directory of a JAR, outside of any package, with a name you expect to be identical across JARs but with different contents? I naively would imagine that some better approach exists. Garret On 10/1/2014 1:22 PM, Martin Grigorov wrote: The .properties file is packed inside wicket-extensions.jar, not in his application. I have no other ideas but to attach a remote debugger to org.apache.wicket.resource.loader.InitializerStringResourceLoader#loadStringResource(java.lang.Class?, java.lang.String, java.util.Locale, java.lang.String, java.lang.String) and set condition on the key parameter to be equal to the missing resource key. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Oct 1, 2014 at 5:55 PM, Andrew Geery andrew.ge...@gmail.com wrote: As a sanity check, is the property file with the property UploadProgressBar.starting in the jar file? Perhaps it didn't get copied over by the Maven build process into the jar but the IDE was properly copying it over... Andrew On Wed, Oct 1, 2014 at 11:38 AM, Garret Wilson gar...@globalmentor.com wrote: On 10/1/2014 12:33 PM, Martin Grigorov wrote: Hi, Do you by chance manipulate the list of IStringResourceLoader's in DEPLOYMENT mode ? I don't think I touched anything related to IStringResourceLoader. The only thing I've done relating to modes is this: //turn on Wicket development mode if in debug mode final String wicketConfiguration = Debug.isDebug() ? development : deployment; filterHolder.setInitParameter(configuration, wicketConfiguration); In other words, in embedded Jetty, if we've started up specifying a debug mode (using a system variable), then I set the Wicket configuration to development; otherwise, I set it to deployment. Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
disabling IndicatingAjaxButton during submision?
IndicatingAjaxButton is nice. But I need one more step: I need the button to be disabled during submission. Mystic Coders indicated a solution http://www.mysticcoders.com/blog/disabling-an-ajax-submit-button/, but that doesn't seem to work with Wicket 7. Some have filed bugs to Wicket https://issues.apache.org/jira/browse/WICKET-5360 and filed bugs to Wicket stuff https://github.com/wicketstuff/core/issues/272 to have this added, but were turned down. In the Wicket documentation there is some complicated code http://wicket.apache.org/guide/guide/ajax.html#ajax_6 for adding layers and having indicators---but I already have an indicator. I just want to disable the button. How can I simply disable the Ajax button during submission? I can't find the page that tells me how to do this---but I find lots of people wanting to do it, and lots of people providing complicated workarounds that break from one version of Wicket to the next. Any easy solutions? Thanks in advance, Garret
Re: disabling IndicatingAjaxButton during submision?
On 10/9/2014 1:21 PM, Martin Grigorov wrote: ... It was as simple as these two lines: https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/65529876b31781bc27441b6b2e17559c97abbd0d/bootstrap-extensions/src/main/java/de/agilecoders/wicket/extensions/markup/html/bootstrap/ladda/LaddaAjaxCallListener.java#L15-L16 It looks like I would spend half the day just trying to figure out how to integrate yet another library. So how can I easily and simply disable a button during submission using only core Wicket? Can it be done? Garret P.S. When somebody wanted to integrate a solution into core Wicket, they were turned down https://issues.apache.org/jira/browse/WICKET-5360.
Re: disabling IndicatingAjaxButton during submision?
One of the reasons I chose Wicket for my client's project was that I expected that at this level of maturity Wicket would support the most common use cases . (Disabling a submission button during submission is one of the most common use cases I can think of.) Let me first say that IndicatingAjaxButton is really cool, and works great! It was just what I needed. Thanks to whoever wrote it. Disabling the submission button during submission, however, is just going to load me down a rat's hole of research and experimentation and trial-and-error and half-solutions. We have a tight deadline to meet. We're going to have to go with just IndicatingAjaxButton and leave it at that. Hopefully we can come back and address this in a future version of our project. I'm just explaining our situation as it is. Nothing personal directed to anyone, and I appreciate the suggestions from Martin Grigorov. Garret On 10/9/2014 12:29 PM, Garret Wilson wrote: IndicatingAjaxButton is nice. But I need one more step: I need the button to be disabled during submission. Mystic Coders indicated a solution http://www.mysticcoders.com/blog/disabling-an-ajax-submit-button/, but that doesn't seem to work with Wicket 7. Some have filed bugs to Wicket https://issues.apache.org/jira/browse/WICKET-5360 and filed bugs to Wicket stuff https://github.com/wicketstuff/core/issues/272 to have this added, but were turned down. In the Wicket documentation there is some complicated code http://wicket.apache.org/guide/guide/ajax.html#ajax_6 for adding layers and having indicators---but I already have an indicator. I just want to disable the button. How can I simply disable the Ajax button during submission? I can't find the page that tells me how to do this---but I find lots of people wanting to do it, and lots of people providing complicated workarounds that break from one version of Wicket to the next. Any easy solutions? Thanks in advance, Garret - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
simple confirmation on button/link
All, I've created a simple confirmation link based on Sven Meier's ConfirmationLink code https://cwiki.apache.org/confluence/x/X4U on Confluence. For the most part it works, but... ...but if I'm on an upload form, then an an Ajax link won't work because I need to actually submit the multipart information. The theory behind Sven's code should work the same with or without an Ajax link. Wicket's AjaxLink simply provides an easy way to inject the confirmation JavaScript without having to wire the event handling manually. You'll see on the same page listed above other examples that do this wiring manually, and do it in a way that is decidedly not correct (replacing the onclick attribute) according to today's modern JavaScript best practices (and frankly hasn't been correct for almost a decade). There is some discussion of this sort on that page, with a bit of back-and-forth about wanting a general, reusable solution, but in the end only giving an example of something in that fashion and with another contributor noting that their solution isn't working and I need to figure out why. And now we're at Wicket 7 and even the incomplete examples on this page don't work anymore because the underlying classes have been removed. (On that page the idea of Ed Eustace is also mentioned, namely to use Component.replaceWith() to have an embedded confirmation panel that appears when needed. But it's as usually a completely do-it-yourself project.) So, friends, does the latest version of Wicket have an easy way to make a confirmation dialog? If not, does it have an easy way for me to inject JavaScript using best-practice DOM event binding? Garret
Re: simple confirmation on button/link
Andrea, thanks for jolting my brain; I was a little sleepy this morning. I was using a subclass of AjaxLink that added confirmation JavaScript as I outlined below. My original HTML was: button wicket:id=foo type=submit The root of the problem is that Wicket kept turning that into: button wicket:id=foo type=button id=foo7 Thus even though I got a confirmation dialog, the FileUpload was never being populated because the form was never being submitted. It turns out that apparently I have to use a subclass of AjaxSubmitLink rather than AjaxLink if I want the form to actually be submitted, even though I specified type=submit in the HTML. So my immediate problem is solved. On a higher level, though, it means that I now have to go create a ConfirmationAjaxSubmitLink along with my ConfirmationAjaxLink. I would have thought/hoped that things like submission and confirmation were something that could be injected to various components using behaviors rather that subclassing all over the place. But for now the program is working. Thanks again, Andrea, for asking the right question that made me investigate further in the right spot. Garret On 10/30/2014 1:14 PM, Andrea Del Bene wrote: On 30/10/14 17:57, Garret Wilson wrote: All, I've created a simple confirmation link based on Sven Meier's ConfirmationLink code https://cwiki.apache.org/confluence/x/X4U on Confluence. For the most part it works, but... ...but if I'm on an upload form, then an an Ajax link won't work because I need to actually submit the multipart information. Hi, not sure I've got your problem. Are you submitting a form using a Ajax link? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
hiding a bit of markup
All, I have a little list in HTML: ul lifoo/li libar/li /ul There are some wicket:message tags, but no components on the page. I want only to show the foo list item if the flag variable is set to true. What's the easiest way to do this in Wicket? I've read the documentation on controlling HTML http://wicket.apache.org/guide/guide/keepControl.html. It seems I can use a WebMarkupContainer, but only if I add some extra HTML. Obviously I don't want this: ul div wicket:id=foolifoo/li/div libar/li /ul It seems I can also use a Fragment (which presumably wouldn't require the extra HTML because it would use wicket:fragment, but the constructor for that component requires that I specify the Wicket ID of the container, which doesn't exist. How can I simply reference some piece of HTML so that I can show or hide it based on some flag? Garret
Re: hiding a bit of markup
Haha! OK, this was simple---my brain apparently hasn't got started yet.
I can use a WebMarkup container, and I don't have to add any HTML---I
can add the wicket:id on the li itself:
ul
li wicket:id=flagItemfoo/li
libar/li
/ul
Duh! The code looks like this:
add(new WebMarkupContainer(flagItem) {
@Override
public boolean isVisible() {
return flag;
}
});
Happy Friday!
Garret
P.S. Thanks to the Wicket SourceForge FAQ
http://wicket.sourceforge.net/faqs.html#how-hide-markup, even though a
bit old, for giving my mind a kick.
On 11/7/2014 10:32 AM, Garret Wilson wrote:
All,
I have a little list in HTML:
ul
lifoo/li
libar/li
/ul
There are some wicket:message tags, but no components on the page. I
want only to show the foo list item if the flag variable is set to
true. What's the easiest way to do this in Wicket?
I've read the documentation on controlling HTML
http://wicket.apache.org/guide/guide/keepControl.html. It seems I
can use a WebMarkupContainer, but only if I add some extra HTML.
Obviously I don't want this:
ul
div wicket:id=foolifoo/li/div
libar/li
/ul
It seems I can also use a Fragment (which presumably wouldn't require
the extra HTML because it would use wicket:fragment, but the
constructor for that component requires that I specify the Wicket ID
of the container, which doesn't exist.
How can I simply reference some piece of HTML so that I can show or
hide it based on some flag?
Garret
clearing feedback messages on Ajax upload
Hi, all. I've done a bit of searching to find the answer, and nothing quite seemed to fit, or was obsolete, or was deprecated, or was vague. So I'll ask on the list. I have a page that uses a multipart form submit. It allows the user to select a file, and has an AjaxSubmitLink with the label Go that 1) uploads a large file and then 2) does something that takes a long time. When finished, it calls info(finished!) to show a success message in the feedback area. So let's suppose that the user selects a file and selects Go. After the file is uploaded, the processing takes place and the feedback area says finished! Perfect. Question: If the user selects /another/ file and selects Go /again/, how can I immediately remove the finished! message, either A) as soon as the user selects Go or B) as soon as the file finishes uploading but before processeing starts? (I greatly prefer option B.) Thanks, Garret
Re: clearing feedback messages on Ajax upload
I actually mistyped; I greatly prefer option A, not B, below. So Martin,
your suggestion sounds good.
My JavaScript is great, but my JQuery is not so hot. I added your code
and... my AjaxSubmitLink now no longer performs an upload at all. Here's
the script that's being added to the page:
script type=text/javascript
/*![CDATA[*/
Wicket.Event.add(window, domready, function(event) {
new Wicket.WUPB('id4', 'id5', 'id6',
'../resource/org.apache.wicket.Application/org.apache.wicket.extensions.ajax.markup.html.form.upload.UploadProgressBar?upload=5',
'id3', 'Upload starting...');;
Wicket.Ajax.ajax({u:./com.example.ExamplePage?5-4.IBehaviorListener.0-form-go,m:POST,c:id8,f:id4,mp:true,sc:go,bsh:[function(attrs,
jqXHR, settings){$('#'id7).empty();}],e:click});;
;});
/*]]*/
/script
Here's what my button (id8) HTML looks like:
button class=pure-button type=button id=id8
i class=fa fa-cloud-upload/i
Go!
/button
/div
id7 is indeed the ID of the feedback div (which starts out empty anyway).
Garret
P.S. A few IDs and strings were changed here and there to generalize the
code.
On 11/13/2014 7:50 PM, Martin Grigorov wrote:
Hi,
On Thu, Nov 13, 2014 at 11:36 PM, Garret Wilson gar...@globalmentor.com
wrote:
Hi, all. I've done a bit of searching to find the answer, and nothing
quite seemed to fit, or was obsolete, or was deprecated, or was vague. So
I'll ask on the list.
I have a page that uses a multipart form submit. It allows the user to
select a file, and has an AjaxSubmitLink with the label Go that 1)
uploads a large file and then 2) does something that takes a long time.
When finished, it calls info(finished!) to show a success message in the
feedback area.
So let's suppose that the user selects a file and selects Go. After the
file is uploaded, the processing takes place and the feedback area says
finished! Perfect.
Question: If the user selects /another/ file and selects Go /again/, how
can I immediately remove the finished! message, either A) as soon as the
user selects Go or B) as soon as the file finishes uploading but before
processeing starts? (I greatly prefer option B.)
How is your JavaScript ?
For A)
AjaxSubmitLink(...) {
@Override protected void updateAjaxAttributes(attrs) {
attrs.getAjaxCallListeners().add(new
AjaxCallListener().onBeforeSend($('#'+feedback.getMarkupId()+).empty();))
}
}
For B)
I can imagine this only with WebSockets.
With HTTP 1.1 the Ajax response should be complete to be flushed to the
client by Wicket.
With WebSockets you can push data at any point of the request processing.
If you choose to use Wicket Native WebSockets then see
WebSocketRequestHandler#push(String). You can push JSON that tells the
client side WebSocket listener at the browser to do the same as the JS in A)
Thanks,
Garret
Re: clearing feedback messages on Ajax upload
Martin, after fixing the ID selector (#id7) it works great! (The page
jumps up because the feedback area disappears, but I can live with that
for now.) It even works in conjunction with Sven Meier's confirmation
message button https://cwiki.apache.org/confluence/x/X4U.
Very nice. Thank you very much, Martin!
I really recommend that Wicket add some prebuilt behaviors. There should
be some sort of Ajax clear component behavior, and some Ajax
confirmation behavior, etc. This is so that we can get hard-coded,
manual JavaScript out of our code, and start developing in terms of
semantically-named prebuilt classes rather than coding JavaScript
boilerplate. Now I know that the Ajax core team hate this idea, because
they say, 1) Wicket is so easy that you can just add in whatever you
want; we don't need to encapsulate this in a class, and 2) there are
so many different ways people want to do it, we don't even want to
include one or two of them in the Wicket library. I don't want to start
that argument here; I'll write an essay about it another day.
For now I'll just hard-code the JavaScript as Martin suggested and get
my app working. Thanks again, Martin! Very helpful.
Garret
On 11/13/2014 8:39 PM, Martin Grigorov wrote:
On Fri, Nov 14, 2014 at 12:36 AM, Garret Wilson gar...@globalmentor.com
wrote:
I actually mistyped; I greatly prefer option A, not B, below. So Martin,
your suggestion sounds good.
My JavaScript is great, but my JQuery is not so hot. I added your code
and... my AjaxSubmitLink now no longer performs an upload at all. Here's
the script that's being added to the page:
script type=text/javascript
/*![CDATA[*/
Wicket.Event.add(window, domready, function(event) {
new Wicket.WUPB('id4', 'id5', 'id6',
'../resource/org.apache.wicket.Application/org.apache.
wicket.extensions.ajax.markup.html.form.upload.
UploadProgressBar?upload=5',
'id3', 'Upload starting...');;
Wicket.Ajax.ajax({u:./com.example.ExamplePage?5-4.
IBehaviorListener.0-form-go,m:POST,c:id8,f:id4,
mp:true,sc:go,bsh:[function(attrs,
jqXHR, settings){$('#'id7).empty();}],e:click});;
it should produce $('#id7').empty(). Note the string parameter to $()
I see that my example is broken.
Check for JS errors in the Dev tools console when you deal with JS ;-)
;});
/*]]*/
/script
Here's what my button (id8) HTML looks like:
button class=pure-button type=button id=id8
i class=fa fa-cloud-upload/i
Go!
/button
/div
id7 is indeed the ID of the feedback div (which starts out empty anyway).
Garret
P.S. A few IDs and strings were changed here and there to generalize the
code.
On 11/13/2014 7:50 PM, Martin Grigorov wrote:
Hi,
On Thu, Nov 13, 2014 at 11:36 PM, Garret Wilson gar...@globalmentor.com
wrote:
Hi, all. I've done a bit of searching to find the answer, and nothing
quite seemed to fit, or was obsolete, or was deprecated, or was vague. So
I'll ask on the list.
I have a page that uses a multipart form submit. It allows the user to
select a file, and has an AjaxSubmitLink with the label Go that 1)
uploads a large file and then 2) does something that takes a long time.
When finished, it calls info(finished!) to show a success message in
the
feedback area.
So let's suppose that the user selects a file and selects Go. After the
file is uploaded, the processing takes place and the feedback area says
finished! Perfect.
Question: If the user selects /another/ file and selects Go /again/,
how
can I immediately remove the finished! message, either A) as soon as
the
user selects Go or B) as soon as the file finishes uploading but before
processeing starts? (I greatly prefer option B.)
How is your JavaScript ?
For A)
AjaxSubmitLink(...) {
@Override protected void updateAjaxAttributes(attrs) {
attrs.getAjaxCallListeners().add(new
AjaxCallListener().onBeforeSend($('#'+feedback.
getMarkupId()+).empty();))
}
}
For B)
I can imagine this only with WebSockets.
With HTTP 1.1 the Ajax response should be complete to be flushed to the
client by Wicket.
With WebSockets you can push data at any point of the request processing.
If you choose to use Wicket Native WebSockets then see
WebSocketRequestHandler#push(String). You can push JSON that tells the
client side WebSocket listener at the browser to do the same as the JS in
A)
Thanks,
Garret
Re: programmatic resources lookup
On 12/24/2015 9:39 AM, Garret Wilson wrote: ... The use of StringResourceModel as you provided almost solved my problem, but not quite. When calling from MyPage.java, I had to add "this" to the constructor in order for it to pick up resources in the MyPage.properties files. P.S. It's a shame there's no way to do the lookup from a static context, e.g. my passing a reference to MyPage.class rather than an actual instance of MyPage. But I'll get by. Thanks again for the help. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
programmatic resources lookup
I've been away from Wicket for a year, working on other areas of my
client's code. I'm doing a pass by to add i18n to a page. I have a
MyPage.properties file with all sorts of properties. I have lots of
tags in MyPage.html.
But how do I manually look up one of these values from the resources?
For example, in MyPage.onAccept() I have something like this:
getSession().success("Successfully munged the " + fooBar + ".");
I want to look up the value from MyPage.properties:
success.message=Successfully munged the {0}.
Looking at the source code of StringResourceModel, it seems I'll have to
do the following:
1. Get a localizer.
2. Ask the localizer to get the resource string.
3. Escape single quotes.
4. Escape substitution expressions (e.g. ${some.other.property}).
5. Use MessageFormat to substitute the parameters (e.g. fooBar, above).
6. Unescape the substitution expression.
7. Ask the localizer to perform substitution for all the expressions.
Whew! I'm exhausted just writing that. Surely there is a utility method
that would do that for me?
Garret
P.S. A /single/ method. There should be a single method for this.
Re: programmatic resources lookup
Sven (and Martin, who provided a similar but less complete answer), I'd
rather not use ${} because in our properties files (for other parts of
the application unrelated to Wicket) we use ${...} to refer to other
string resources.
The use of StringResourceModel as you provided almost solved my problem,
but not quite. When calling from MyPage.java, I had to add "this" to the
constructor in order for it to pick up resources in the
MyPage.properties files. But then it worked---thanks!
Garret
On 12/24/2015 2:44 AM, Sven Meier wrote:
Hi,
the easiest solution would be not to use MessageFormat:
getSession().success(getString("success.message", Model.of(fooBar)));
with:
success.message=Successfully munged the ${}.
If you insist on using MessageFormat, you can just use
StringResourceModel for that:
getSession().success(new
StringResourceModel("success.message").setParameters(fooBar).getString());
Have fun
Sven
On 24.12.2015 01:11, Garret Wilson wrote:
I've been away from Wicket for a year, working on other areas of my
client's code. I'm doing a pass by to add i18n to a page. I have a
MyPage.properties file with all sorts of properties. I have lots of
tags in MyPage.html.
But how do I manually look up one of these values from the resources?
For example, in MyPage.onAccept() I have something like this:
getSession().success("Successfully munged the " + fooBar + ".");
I want to look up the value from MyPage.properties:
success.message=Successfully munged the {0}.
Looking at the source code of StringResourceModel, it seems I'll have
to do the following:
1. Get a localizer.
2. Ask the localizer to get the resource string.
3. Escape single quotes.
4. Escape substitution expressions (e.g. ${some.other.property}).
5. Use MessageFormat to substitute the parameters (e.g. fooBar, above).
6. Unescape the substitution expression.
7. Ask the localizer to perform substitution for all the expressions.
Whew! I'm exhausted just writing that. Surely there is a utility
method that would do that for me?
Garret
P.S. A /single/ method. There should be a single method for this.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
