Re: adding component Dynamically
Hi,
could you be more specific on how it doesn't work?
Check your browser's network console whether the request is sent
actually. Then put a breakpoint in
ListenerInterfaceRequestHandler#respond() and check what happens on the
server.
BTW you should use new AjaxEventBehavior(click) instead.
Have fun
Sven
Am 04.03.2015 um 14:41 schrieb avchavan:
Hi,
I want to add a link to my html dynamically via wicket.
I have written code for that which works as far as displaying the link is
concerned.
But the onclick of the link doesnt work.
final WebMarkupContainer more = new WebMarkupContainer(more);
final String toelichtingText =
item.getModelObject().getToelichting();
String less;
if(item.getModelObject().getToelichting().length() 20
javaScript){
if(toelichtingText.indexOf( , 20) != -1){
less = toelichtingText.substring(0,
toelichtingText.indexOf( , 20))+
...more ;
}else{
less = toelichtingText;
more.setVisible(false);
}
}else{
less = toelichtingText;
more.setVisible(false);
}
final ModelString strMdl = Model.of(less);
final WebMarkupContainer toelichtingContainer = new
WebMarkupContainer(toelichtingContainer);
final Label lessToelichting = new Label(toelichting, strMdl);
lessToelichting.setOutputMarkupPlaceholderTag(true);
lessToelichting.setEscapeModelStrings(false);
more.add(new AjaxEventBehavior(onclick) {
@Override
protected void onEvent(AjaxRequestTarget target) {
strMdl.setObject(toelichtingText);
more.setVisible(false);
target.add(lessToelichting);
target.add(more);
}
@Override
protected void
updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setEventPropagation(EventPropagation.STOP);
}
});
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/adding-component-Dynamically-tp4669838.html
Sent from the Users forum mailing list archive at Nabble.com.
-
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
How to convert component model object to rendered HTML?
Hi all, I have my own subclass of RequiredTextField for very specific reasons and need to convert input after form submit to a Wicket model and vice versa from a Wicket model to a form input value in case of errors and such, when Wicket renders the form with the current values. I have overridden Component.getConverter and can see that convertToObject of my implementation is called, but not convertToString. Instead Wicket renders exactly that data which it got submitted by the form, but is not what I need to show to the user. Any idea on where I have a problem? Thanks! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using wicket:... tags messes up css
Guten Tag Andreas Lundblad, am Mittwoch, 4. März 2015 um 22:14 schrieben Sie: That's a very crude solution. Almost as crude as switching deployment mode. From my point of view Wicket's tags are an implementation detail and don't belong to the HTML output, stripping them is therefore the only correct solution. The wicket tags are useful during debugging and I'd like them to be available (except possibly in this case) in development mode. You obviously can't have both, either you see them as part of your end user DOM, than you need to care in CSS of them, or not, then just strip them. What exactly do they help you with during debugging? There might be other solutions for what you are trying to achieve. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using wicket:... tags messes up css
Hi,
try getMarkupSettings().setStripWicketTags(true); in the applications init.
kind regards
Tobias
Am 04.03.15 um 22:03 schrieb Andreas Lundblad:
I've noticed that wicket:... tags such as wicket:enclosure messes up
the CSS sometimes.
In my particular example I have
div.formRows div {
display: table-row;
}
and when I try to put an enclosure around a table row, the CSS child
selector doesn't work.
Is there an easy workaround (except switching deployment mode)?
best regards,
Andreas Lundblad
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using wicket:... tags messes up css
I think:
getMarkupSettings().setStripWicketTags(true);
in your Application.init() would do the trick.
-Don
On Mar 4, 2015, at 1:03 PM, Andreas Lundblad andreas.lundb...@gmail.com
wrote:
I've noticed that wicket:... tags such as wicket:enclosure messes up
the CSS sometimes.
In my particular example I have
div.formRows div {
display: table-row;
}
and when I try to put an enclosure around a table row, the CSS child
selector doesn't work.
Is there an easy workaround (except switching deployment mode)?
best regards,
Andreas Lundblad
Using wicket:... tags messes up css
I've noticed that wicket:... tags such as wicket:enclosure messes up
the CSS sometimes.
In my particular example I have
div.formRows div {
display: table-row;
}
and when I try to put an enclosure around a table row, the CSS child
selector doesn't work.
Is there an easy workaround (except switching deployment mode)?
best regards,
Andreas Lundblad
Re: Using wicket:... tags messes up css
That's a very crude solution. Almost as crude as switching deployment mode.
The wicket tags are useful during debugging and I'd like them to be
available (except possibly in this case) in development mode.
best regards,
Andreas Lundblad
On Wed, Mar 4, 2015 at 10:11 PM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
try getMarkupSettings().setStripWicketTags(true); in the applications
init.
kind regards
Tobias
Am 04.03.15 um 22:03 schrieb Andreas Lundblad:
I've noticed that wicket:... tags such as wicket:enclosure messes up
the CSS sometimes.
In my particular example I have
div.formRows div {
display: table-row;
}
and when I try to put an enclosure around a table row, the CSS child
selector doesn't work.
Is there an easy workaround (except switching deployment mode)?
best regards,
Andreas Lundblad
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using wicket:... tags messes up css
Thanks Thorsten, I understand what you're saying and I agree to some extent. They're present by default in development mode (which I think makes sense) so I've gotten used to having them. Maybe I should try to break this habit. On Mar 4, 2015 10:27 PM, Thorsten Schöning tschoen...@am-soft.de wrote: Guten Tag Andreas Lundblad, am Mittwoch, 4. März 2015 um 22:14 schrieben Sie: That's a very crude solution. Almost as crude as switching deployment mode. From my point of view Wicket's tags are an implementation detail and don't belong to the HTML output, stripping them is therefore the only correct solution. The wicket tags are useful during debugging and I'd like them to be available (except possibly in this case) in development mode. You obviously can't have both, either you see them as part of your end user DOM, than you need to care in CSS of them, or not, then just strip them. What exactly do they help you with during debugging? There might be other solutions for what you are trying to achieve. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to convert component model object to rendered HTML?
You can call formComponent#clearInput() in #onError() callback method. This way Wicket will use the last (valid) model value. You can also set custom model value in #onError() if you need. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Mar 5, 2015 at 9:39 AM, Thorsten Schöning tschoen...@am-soft.de wrote: Guten Tag Martin Grigorov, am Donnerstag, 5. März 2015 um 08:05 schrieben Sie: If the validation fails then the *raw* input is rendered to the user and there is no usage of #convertToString() because there is no need. Thanks, I wasn't aware of this and that explains why it looked like it would work in other places, because there I have generated the exact same values in convertToString like came from the browser and didn't notice that the method wasn't ever called. But now I do need to render other values, in case of errors during form validation Wicket needs to render other values than came form the browser during the submit. Is there any way to do this? Some background: I have an Ajax auto complete input which searches based on company names, but sends company IDs to Wicket. If other forms on the page fail validation, I need to render the former searched company names instead of their IDs back into the form. Wicket by default renders IDs, because that's what it gets, but I thought I can simply change that on the server during the render process somehow back to company names. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to convert component model object to rendered HTML?
Hi, On Wed, Mar 4, 2015 at 11:21 PM, Thorsten Schöning tschoen...@am-soft.de wrote: Hi all, I have my own subclass of RequiredTextField for very specific reasons and need to convert input after form submit to a Wicket model and vice versa from a Wicket model to a form input value in case of errors and such, when Wicket renders the form with the current values. I have overridden Component.getConverter and can see that convertToObject of my implementation is called, but not convertToString. Instead Wicket renders exactly that data which it got submitted by the form, but is not what I need to show to the user. Any idea on where I have a problem? Thanks! FormComponent have two models - the model that every component has and input (raw converted). During form submit processing the raw input (the request parameter as String) is converted to the type of the model, here #convertToObject() is used. Next step in the processing is validation, the converted input is given to all registered IValidators and if all checks pass then finally the converted input is set as a model object/value. If the validation fails then the *raw* input is rendered to the user and there is no usage of #convertToString() because there is no need. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to convert component model object to rendered HTML?
Guten Tag Martin Grigorov, am Donnerstag, 5. März 2015 um 08:05 schrieben Sie: If the validation fails then the *raw* input is rendered to the user and there is no usage of #convertToString() because there is no need. Thanks, I wasn't aware of this and that explains why it looked like it would work in other places, because there I have generated the exact same values in convertToString like came from the browser and didn't notice that the method wasn't ever called. But now I do need to render other values, in case of errors during form validation Wicket needs to render other values than came form the browser during the submit. Is there any way to do this? Some background: I have an Ajax auto complete input which searches based on company names, but sends company IDs to Wicket. If other forms on the page fail validation, I need to render the former searched company names instead of their IDs back into the form. Wicket by default renders IDs, because that's what it gets, but I thought I can simply change that on the server during the render process somehow back to company names. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resolving nested properties
Hi,
It took a while to dive into this but I wrote a simple solution based on
the pattern/matcher example of Tobias and this seems to work well. It only
wraps the default Localizer class in Wicket by overriding the getString
method:
getResourceSettings().setLocalizer(new Localizer()
{
public String getString(final String key, final Component component,
final IModel? model, final Locale locale, final String style, final
IModelString defaultValue) throws MissingResourceException
{
String value = super.getString(key, component, model, locale, style,
defaultValue);
StringBuffer output = new StringBuffer();
final Pattern PLACEHOLDER_PATTERN = Pattern.compile(\\$\\{(.*)\\});
Matcher matcher = PLACEHOLDER_PATTERN.matcher(value);
// Search for other nested keys to replace
while (matcher.find())
{
String replacedPlaceHolder = getString(matcher.group(1), component,
model, locale, style, (String)null);
matcher.appendReplacement(output, replacedPlaceHolder);
}
matcher.appendTail(output);
return output.toString();
}
});
Any need for putting this in Wicket? Or maybe somebody has better options
how to do this. I'm all ears but I'm already happy that I could implement
this anyway without patching the Wicket source.
Rob
On Sat, Feb 21, 2015 at 6:14 PM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
if it gained not as much interest in the community, but there are still
some users asking for such an implementation - maybe we can put it into
wicketstuff-minis?
kind regards
Tobias
P.S.: I also answered the question in stackoverflow. :-)
Am 21.02.15 um 17:59 schrieb Sven Meier:
Hi,
such a feature was asked a few times, e.g.:
http://stackoverflow.com/questions/16684200/refer-to-
one-property-from-another
But apparently it never gained much interest in the community. In my
experience you won't find many cases where this is useful anyway.
Have fun
Sven
On 21.02.2015 16:51, Tobias Soloschenko wrote:
Rob,
we will see what others say and if there is a standard way for this in
wicket. I'm currently testing the implementation - it also replaces keys
found in hierarchy, because Wickets Localizer is going to be used for each
key which is going to be replaced. So the example of your first mail is
also covered.
kind regards
Tobias
Am 21.02.15 um 16:37 schrieb Rob Sonke:
Tobias,
Somehow I'm missing your replies in gmail. But thanks for the
suggestions.
Using custom models would be a last resort for me. Because I will have
to
replace all occurences. I'm somehow hoping to hook into the localizer.
On Sat, Feb 21, 2015 at 2:01 PM, Rob Sonke r...@tigrou.nl wrote:
Hi all,
I'm trying to achieve a fairly simple thing within .properties files to
avoid a lot of duplicate words through different files.
For example there's is a HomePage.properties with:
lbl.foo=This is an example text, we love ${lbl.item}
And then in MyWebApplication.properties:
lbl.item=Wicket
But as far as I can see, Wicket tries to resolve the parameters with
objects passed to eg StringResourceModel. How can I hook into this and
solve this in a nice way?
Kind regards,
Rob
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resolving nested properties
Hi,
maybe we can provide a new Localizer or change the existing default
implementation. As far as I know the StringResourceModel uses the same Syntax
for replacing which might lead to errors
@others: What do you think?
@Rob: the pattern should be modified a bit so that it is not greedy (.*?) -
have a look in WicketStuff / submodul html5 - there is a class
ReplacingResourceModel - the pattern you find there is a better one.
kind regards
Tobias
Am 04.03.2015 um 09:09 schrieb Rob Sonke r...@tigrou.nl:
Hi,
It took a while to dive into this but I wrote a simple solution based on
the pattern/matcher example of Tobias and this seems to work well. It only
wraps the default Localizer class in Wicket by overriding the getString
method:
getResourceSettings().setLocalizer(new Localizer()
{
public String getString(final String key, final Component component,
final IModel? model, final Locale locale, final String style, final
IModelString defaultValue) throws MissingResourceException
{
String value = super.getString(key, component, model, locale, style,
defaultValue);
StringBuffer output = new StringBuffer();
final Pattern PLACEHOLDER_PATTERN = Pattern.compile(\\$\\{(.*)\\});
Matcher matcher = PLACEHOLDER_PATTERN.matcher(value);
// Search for other nested keys to replace
while (matcher.find())
{
String replacedPlaceHolder = getString(matcher.group(1), component,
model, locale, style, (String)null);
matcher.appendReplacement(output, replacedPlaceHolder);
}
matcher.appendTail(output);
return output.toString();
}
});
Any need for putting this in Wicket? Or maybe somebody has better options
how to do this. I'm all ears but I'm already happy that I could implement
this anyway without patching the Wicket source.
Rob
On Sat, Feb 21, 2015 at 6:14 PM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
if it gained not as much interest in the community, but there are still
some users asking for such an implementation - maybe we can put it into
wicketstuff-minis?
kind regards
Tobias
P.S.: I also answered the question in stackoverflow. :-)
Am 21.02.15 um 17:59 schrieb Sven Meier:
Hi,
such a feature was asked a few times, e.g.:
http://stackoverflow.com/questions/16684200/refer-to-
one-property-from-another
But apparently it never gained much interest in the community. In my
experience you won't find many cases where this is useful anyway.
Have fun
Sven
On 21.02.2015 16:51, Tobias Soloschenko wrote:
Rob,
we will see what others say and if there is a standard way for this in
wicket. I'm currently testing the implementation - it also replaces keys
found in hierarchy, because Wickets Localizer is going to be used for each
key which is going to be replaced. So the example of your first mail is
also covered.
kind regards
Tobias
Am 21.02.15 um 16:37 schrieb Rob Sonke:
Tobias,
Somehow I'm missing your replies in gmail. But thanks for the
suggestions.
Using custom models would be a last resort for me. Because I will have
to
replace all occurences. I'm somehow hoping to hook into the localizer.
On Sat, Feb 21, 2015 at 2:01 PM, Rob Sonke r...@tigrou.nl wrote:
Hi all,
I'm trying to achieve a fairly simple thing within .properties files to
avoid a lot of duplicate words through different files.
For example there's is a HomePage.properties with:
lbl.foo=This is an example text, we love ${lbl.item}
And then in MyWebApplication.properties:
lbl.item=Wicket
But as far as I can see, Wicket tries to resolve the parameters with
objects passed to eg StringResourceModel. How can I hook into this and
solve this in a nice way?
Kind regards,
Rob
-
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
-
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: Resolving nested properties
Hi,
Since there were no many requests for this functionality I'd prefer if we
use a specialization of Localizer as Rob did.
The Pattern compilation is the slower operation, so it should be a static
final field. The matching is usually fast so maybe there is no problem to
put it directly in Localizer. But I don't see why to do it if there are
just few users of this functionality.
Please file a ticket!
Preferably with a patch/PR and some tests!
Thanks!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Mar 4, 2015 at 10:25 AM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
maybe we can provide a new Localizer or change the existing default
implementation. As far as I know the StringResourceModel uses the same
Syntax for replacing which might lead to errors
@others: What do you think?
@Rob: the pattern should be modified a bit so that it is not greedy (.*?)
- have a look in WicketStuff / submodul html5 - there is a class
ReplacingResourceModel - the pattern you find there is a better one.
kind regards
Tobias
Am 04.03.2015 um 09:09 schrieb Rob Sonke r...@tigrou.nl:
Hi,
It took a while to dive into this but I wrote a simple solution based on
the pattern/matcher example of Tobias and this seems to work well. It
only
wraps the default Localizer class in Wicket by overriding the getString
method:
getResourceSettings().setLocalizer(new Localizer()
{
public String getString(final String key, final Component component,
final IModel? model, final Locale locale, final String style, final
IModelString defaultValue) throws MissingResourceException
{
String value = super.getString(key, component, model, locale, style,
defaultValue);
StringBuffer output = new StringBuffer();
final Pattern PLACEHOLDER_PATTERN = Pattern.compile(\\$\\{(.*)\\});
Matcher matcher = PLACEHOLDER_PATTERN.matcher(value);
// Search for other nested keys to replace
while (matcher.find())
{
String replacedPlaceHolder = getString(matcher.group(1), component,
model, locale, style, (String)null);
matcher.appendReplacement(output, replacedPlaceHolder);
}
matcher.appendTail(output);
return output.toString();
}
});
Any need for putting this in Wicket? Or maybe somebody has better options
how to do this. I'm all ears but I'm already happy that I could implement
this anyway without patching the Wicket source.
Rob
On Sat, Feb 21, 2015 at 6:14 PM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
if it gained not as much interest in the community, but there are still
some users asking for such an implementation - maybe we can put it into
wicketstuff-minis?
kind regards
Tobias
P.S.: I also answered the question in stackoverflow. :-)
Am 21.02.15 um 17:59 schrieb Sven Meier:
Hi,
such a feature was asked a few times, e.g.:
http://stackoverflow.com/questions/16684200/refer-to-
one-property-from-another
But apparently it never gained much interest in the community. In my
experience you won't find many cases where this is useful anyway.
Have fun
Sven
On 21.02.2015 16:51, Tobias Soloschenko wrote:
Rob,
we will see what others say and if there is a standard way for this in
wicket. I'm currently testing the implementation - it also replaces
keys
found in hierarchy, because Wickets Localizer is going to be used for
each
key which is going to be replaced. So the example of your first mail
is
also covered.
kind regards
Tobias
Am 21.02.15 um 16:37 schrieb Rob Sonke:
Tobias,
Somehow I'm missing your replies in gmail. But thanks for the
suggestions.
Using custom models would be a last resort for me. Because I will
have
to
replace all occurences. I'm somehow hoping to hook into the
localizer.
On Sat, Feb 21, 2015 at 2:01 PM, Rob Sonke r...@tigrou.nl wrote:
Hi all,
I'm trying to achieve a fairly simple thing within .properties
files to
avoid a lot of duplicate words through different files.
For example there's is a HomePage.properties with:
lbl.foo=This is an example text, we love ${lbl.item}
And then in MyWebApplication.properties:
lbl.item=Wicket
But as far as I can see, Wicket tries to resolve the parameters with
objects passed to eg StringResourceModel. How can I hook into this
and
solve this in a nice way?
Kind regards,
Rob
-
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: Resolving nested properties
Hi Rob,
maybe we could name it KeyReplacingLocalizer.
Here is the reference of the ReplacingResourceModel. It wasn't in html5
submodule but in minis.
https://github.com/wicketstuff/core/blob/85bfa1b4bf67261ad4a7b07295c366c49733ad1f/jdk-1.7-parent/minis-parent/minis/src/main/java/org/wicketstuff/minis/model/ReplacingResourceModel.java
The pattern is like this:
private static final Pattern PLACEHOLDER_PATTERN = Pattern.compile(\\$\\
{(.*?)\\});
kind regards
Tobias
2015-03-04 9:57 GMT+01:00 Rob Sonke r...@tigrou.nl:
Agree Martin, thanks for the tips (also Tobias). I'll look into an
implementation of an extra Localizer, good names are welcome, and file a
ticket.
Rob
On Wed, Mar 4, 2015 at 9:46 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
Since there were no many requests for this functionality I'd prefer if we
use a specialization of Localizer as Rob did.
The Pattern compilation is the slower operation, so it should be a static
final field. The matching is usually fast so maybe there is no problem to
put it directly in Localizer. But I don't see why to do it if there are
just few users of this functionality.
Please file a ticket!
Preferably with a patch/PR and some tests!
Thanks!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Mar 4, 2015 at 10:25 AM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
maybe we can provide a new Localizer or change the existing default
implementation. As far as I know the StringResourceModel uses the same
Syntax for replacing which might lead to errors
@others: What do you think?
@Rob: the pattern should be modified a bit so that it is not greedy
(.*?)
- have a look in WicketStuff / submodul html5 - there is a class
ReplacingResourceModel - the pattern you find there is a better one.
kind regards
Tobias
Am 04.03.2015 um 09:09 schrieb Rob Sonke r...@tigrou.nl:
Hi,
It took a while to dive into this but I wrote a simple solution based
on
the pattern/matcher example of Tobias and this seems to work well. It
only
wraps the default Localizer class in Wicket by overriding the
getString
method:
getResourceSettings().setLocalizer(new Localizer()
{
public String getString(final String key, final Component component,
final IModel? model, final Locale locale, final String style, final
IModelString defaultValue) throws MissingResourceException
{
String value = super.getString(key, component, model, locale,
style,
defaultValue);
StringBuffer output = new StringBuffer();
final Pattern PLACEHOLDER_PATTERN =
Pattern.compile(\\$\\{(.*)\\});
Matcher matcher = PLACEHOLDER_PATTERN.matcher(value);
// Search for other nested keys to replace
while (matcher.find())
{
String replacedPlaceHolder = getString(matcher.group(1),
component,
model, locale, style, (String)null);
matcher.appendReplacement(output, replacedPlaceHolder);
}
matcher.appendTail(output);
return output.toString();
}
});
Any need for putting this in Wicket? Or maybe somebody has better
options
how to do this. I'm all ears but I'm already happy that I could
implement
this anyway without patching the Wicket source.
Rob
On Sat, Feb 21, 2015 at 6:14 PM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
if it gained not as much interest in the community, but there are
still
some users asking for such an implementation - maybe we can put it
into
wicketstuff-minis?
kind regards
Tobias
P.S.: I also answered the question in stackoverflow. :-)
Am 21.02.15 um 17:59 schrieb Sven Meier:
Hi,
such a feature was asked a few times, e.g.:
http://stackoverflow.com/questions/16684200/refer-to-
one-property-from-another
But apparently it never gained much interest in the community. In
my
experience you won't find many cases where this is useful anyway.
Have fun
Sven
On 21.02.2015 16:51, Tobias Soloschenko wrote:
Rob,
we will see what others say and if there is a standard way for
this
in
wicket. I'm currently testing the implementation - it also
replaces
keys
found in hierarchy, because Wickets Localizer is going to be used
for
each
key which is going to be replaced. So the example of your first
mail
is
also covered.
kind regards
Tobias
Am 21.02.15 um 16:37 schrieb Rob Sonke:
Tobias,
Somehow I'm missing your replies in gmail. But thanks for the
suggestions.
Using custom models would be a last resort for me. Because I will
have
to
replace all occurences. I'm
Re: Resolving nested properties
Agree Martin, thanks for the tips (also Tobias). I'll look into an
implementation of an extra Localizer, good names are welcome, and file a
ticket.
Rob
On Wed, Mar 4, 2015 at 9:46 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
Since there were no many requests for this functionality I'd prefer if we
use a specialization of Localizer as Rob did.
The Pattern compilation is the slower operation, so it should be a static
final field. The matching is usually fast so maybe there is no problem to
put it directly in Localizer. But I don't see why to do it if there are
just few users of this functionality.
Please file a ticket!
Preferably with a patch/PR and some tests!
Thanks!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Mar 4, 2015 at 10:25 AM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
maybe we can provide a new Localizer or change the existing default
implementation. As far as I know the StringResourceModel uses the same
Syntax for replacing which might lead to errors
@others: What do you think?
@Rob: the pattern should be modified a bit so that it is not greedy (.*?)
- have a look in WicketStuff / submodul html5 - there is a class
ReplacingResourceModel - the pattern you find there is a better one.
kind regards
Tobias
Am 04.03.2015 um 09:09 schrieb Rob Sonke r...@tigrou.nl:
Hi,
It took a while to dive into this but I wrote a simple solution based
on
the pattern/matcher example of Tobias and this seems to work well. It
only
wraps the default Localizer class in Wicket by overriding the getString
method:
getResourceSettings().setLocalizer(new Localizer()
{
public String getString(final String key, final Component component,
final IModel? model, final Locale locale, final String style, final
IModelString defaultValue) throws MissingResourceException
{
String value = super.getString(key, component, model, locale, style,
defaultValue);
StringBuffer output = new StringBuffer();
final Pattern PLACEHOLDER_PATTERN =
Pattern.compile(\\$\\{(.*)\\});
Matcher matcher = PLACEHOLDER_PATTERN.matcher(value);
// Search for other nested keys to replace
while (matcher.find())
{
String replacedPlaceHolder = getString(matcher.group(1),
component,
model, locale, style, (String)null);
matcher.appendReplacement(output, replacedPlaceHolder);
}
matcher.appendTail(output);
return output.toString();
}
});
Any need for putting this in Wicket? Or maybe somebody has better
options
how to do this. I'm all ears but I'm already happy that I could
implement
this anyway without patching the Wicket source.
Rob
On Sat, Feb 21, 2015 at 6:14 PM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
if it gained not as much interest in the community, but there are
still
some users asking for such an implementation - maybe we can put it
into
wicketstuff-minis?
kind regards
Tobias
P.S.: I also answered the question in stackoverflow. :-)
Am 21.02.15 um 17:59 schrieb Sven Meier:
Hi,
such a feature was asked a few times, e.g.:
http://stackoverflow.com/questions/16684200/refer-to-
one-property-from-another
But apparently it never gained much interest in the community. In my
experience you won't find many cases where this is useful anyway.
Have fun
Sven
On 21.02.2015 16:51, Tobias Soloschenko wrote:
Rob,
we will see what others say and if there is a standard way for this
in
wicket. I'm currently testing the implementation - it also replaces
keys
found in hierarchy, because Wickets Localizer is going to be used
for
each
key which is going to be replaced. So the example of your first mail
is
also covered.
kind regards
Tobias
Am 21.02.15 um 16:37 schrieb Rob Sonke:
Tobias,
Somehow I'm missing your replies in gmail. But thanks for the
suggestions.
Using custom models would be a last resort for me. Because I will
have
to
replace all occurences. I'm somehow hoping to hook into the
localizer.
On Sat, Feb 21, 2015 at 2:01 PM, Rob Sonke r...@tigrou.nl wrote:
Hi all,
I'm trying to achieve a fairly simple thing within .properties
files to
avoid a lot of duplicate words through different files.
For example there's is a HomePage.properties with:
lbl.foo=This is an example text, we love ${lbl.item}
And then in MyWebApplication.properties:
lbl.item=Wicket
But as far as I can see, Wicket tries to resolve the parameters
with
objects passed to eg StringResourceModel. How can I hook into this
and
solve this in a nice way?
Kind regards,
Rob
Re: Accessing Current Page In Custom Request Mapper
Thanks for your reply. But it's not a real REST service. I won't go to the details but to be honest this project is a mess. There is a lot couplings between application logic and wicket so they want a service to map JSON request to wicket. I will ask more about your note, but aside from that, can I access the current page at all? For example something like Application.get().getCurrentPage()? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Accessing-Current-Page-In-Custom-Request-Mapper-tp4669833p4669835.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Accessing Current Page In Custom Request Mapper
Hi, there's no *current* page when a REST request comes in. Your page should always fetch the current state from a central shared place. It can use an Ajax timer to check for updates or just live with outdated data until the next page refresh. Regards Sven Am 04.03.2015 um 12:12 schrieb jahandideh_iman: I'm new to wicket and I must create a custom REST api for wicket. I managed to create a IRequestMapper for accepting REST messages but the problem is I can't find a way to have access to current page to update it based on the message. It seems wicket find the current page based on the pageID that is provided in url, but I don't want to use this method. Is there any other methods? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Accessing-Current-Page-In-Custom-Request-Mapper-tp4669833.html Sent from the Users forum mailing list archive at Nabble.com. - 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
Accessing Current Page In Custom Request Mapper
I'm new to wicket and I must create a custom REST api for wicket. I managed to create a IRequestMapper for accepting REST messages but the problem is I can't find a way to have access to current page to update it based on the message. It seems wicket find the current page based on the pageID that is provided in url, but I don't want to use this method. Is there any other methods? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Accessing-Current-Page-In-Custom-Request-Mapper-tp4669833.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Accessing Current Page In Custom Request Mapper
I think I get your point now. Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Accessing-Current-Page-In-Custom-Request-Mapper-tp4669833p4669837.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
adding component Dynamically
Hi,
I want to add a link to my html dynamically via wicket.
I have written code for that which works as far as displaying the link is
concerned.
But the onclick of the link doesnt work.
final WebMarkupContainer more = new WebMarkupContainer(more);
final String toelichtingText =
item.getModelObject().getToelichting();
String less;
if(item.getModelObject().getToelichting().length() 20
javaScript){
if(toelichtingText.indexOf( , 20) != -1){
less = toelichtingText.substring(0,
toelichtingText.indexOf( , 20))+
...more ;
}else{
less = toelichtingText;
more.setVisible(false);
}
}else{
less = toelichtingText;
more.setVisible(false);
}
final ModelString strMdl = Model.of(less);
final WebMarkupContainer toelichtingContainer = new
WebMarkupContainer(toelichtingContainer);
final Label lessToelichting = new Label(toelichting, strMdl);
lessToelichting.setOutputMarkupPlaceholderTag(true);
lessToelichting.setEscapeModelStrings(false);
more.add(new AjaxEventBehavior(onclick) {
@Override
protected void onEvent(AjaxRequestTarget target) {
strMdl.setObject(toelichtingText);
more.setVisible(false);
target.add(lessToelichting);
target.add(more);
}
@Override
protected void
updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setEventPropagation(EventPropagation.STOP);
}
});
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/adding-component-Dynamically-tp4669838.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Resolving nested properties
Done:
https://issues.apache.org/jira/browse/WICKET-5847
I'll create a pull request too and I'll mention that in the jira ticket.
Rob
On Wed, Mar 4, 2015 at 10:16 AM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi Rob,
maybe we could name it KeyReplacingLocalizer.
Here is the reference of the ReplacingResourceModel. It wasn't in html5
submodule but in minis.
https://github.com/wicketstuff/core/blob/85bfa1b4bf67261ad4a7b07295c366c49733ad1f/jdk-1.7-parent/minis-parent/minis/src/main/java/org/wicketstuff/minis/model/ReplacingResourceModel.java
The pattern is like this:
private static final Pattern PLACEHOLDER_PATTERN = Pattern.compile(\\$\\
{(.*?)\\});
kind regards
Tobias
2015-03-04 9:57 GMT+01:00 Rob Sonke r...@tigrou.nl:
Agree Martin, thanks for the tips (also Tobias). I'll look into an
implementation of an extra Localizer, good names are welcome, and file a
ticket.
Rob
On Wed, Mar 4, 2015 at 9:46 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
Since there were no many requests for this functionality I'd prefer if
we
use a specialization of Localizer as Rob did.
The Pattern compilation is the slower operation, so it should be a
static
final field. The matching is usually fast so maybe there is no problem
to
put it directly in Localizer. But I don't see why to do it if there are
just few users of this functionality.
Please file a ticket!
Preferably with a patch/PR and some tests!
Thanks!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Mar 4, 2015 at 10:25 AM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
maybe we can provide a new Localizer or change the existing default
implementation. As far as I know the StringResourceModel uses the
same
Syntax for replacing which might lead to errors
@others: What do you think?
@Rob: the pattern should be modified a bit so that it is not greedy
(.*?)
- have a look in WicketStuff / submodul html5 - there is a class
ReplacingResourceModel - the pattern you find there is a better one.
kind regards
Tobias
Am 04.03.2015 um 09:09 schrieb Rob Sonke r...@tigrou.nl:
Hi,
It took a while to dive into this but I wrote a simple solution
based
on
the pattern/matcher example of Tobias and this seems to work well.
It
only
wraps the default Localizer class in Wicket by overriding the
getString
method:
getResourceSettings().setLocalizer(new Localizer()
{
public String getString(final String key, final Component
component,
final IModel? model, final Locale locale, final String style,
final
IModelString defaultValue) throws MissingResourceException
{
String value = super.getString(key, component, model, locale,
style,
defaultValue);
StringBuffer output = new StringBuffer();
final Pattern PLACEHOLDER_PATTERN =
Pattern.compile(\\$\\{(.*)\\});
Matcher matcher = PLACEHOLDER_PATTERN.matcher(value);
// Search for other nested keys to replace
while (matcher.find())
{
String replacedPlaceHolder = getString(matcher.group(1),
component,
model, locale, style, (String)null);
matcher.appendReplacement(output, replacedPlaceHolder);
}
matcher.appendTail(output);
return output.toString();
}
});
Any need for putting this in Wicket? Or maybe somebody has better
options
how to do this. I'm all ears but I'm already happy that I could
implement
this anyway without patching the Wicket source.
Rob
On Sat, Feb 21, 2015 at 6:14 PM, Tobias Soloschenko
tobiassolosche...@googlemail.com wrote:
Hi,
if it gained not as much interest in the community, but there are
still
some users asking for such an implementation - maybe we can put it
into
wicketstuff-minis?
kind regards
Tobias
P.S.: I also answered the question in stackoverflow. :-)
Am 21.02.15 um 17:59 schrieb Sven Meier:
Hi,
such a feature was asked a few times, e.g.:
http://stackoverflow.com/questions/16684200/refer-to-
one-property-from-another
But apparently it never gained much interest in the community. In
my
experience you won't find many cases where this is useful anyway.
Have fun
Sven
On 21.02.2015 16:51, Tobias Soloschenko wrote:
Rob,
we will see what others say and if there is a standard way for
this
in
wicket. I'm currently testing the implementation - it also
replaces
keys
found in hierarchy, because Wickets Localizer is going to be
used
for
