You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Rob Sonke <ro...@tigrou.nl> on 2015/02/21 14:01:44 UTC
Resolving nested properties
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: Resolving nested properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
Here is the link to the master - if something is going to be changed you
will see it.
https://github.com/klopfdreh/wicket-components-playground/blob/master/wicket-components-playground/src/main/java/org/apache/wicket/model/ReplacingResourceModel.java
kind regards
Tobias
Am 21.02.15 um 14:01 schrieb Rob Sonke:
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Resolving nested properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi again,
"I used Wicket 7.x - the API changed a little bit since 6.x so if you
are interested then let us know."
That was wrong - I copied the ReplacingResourceModel into my testproject
running with wicket 6.x and it is working without errors. Maybe it was
an error during the development of the Model itself.
kind regards
Tobias
Am 21.02.15 um 14:01 schrieb Rob Sonke:
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Resolving nested properties
Posted by Rob Sonke <ro...@tigrou.nl>.
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 <
tobiassoloschenko@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 <ro...@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 <mg...@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 <
> > > tobiassoloschenko@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 <ro...@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
> > > > > IModel<String> 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 <
> > > > > tobiassoloschenko@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 <ro...@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-unsubscribe@wicket.apache.org
> > > > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > > >>>
> > > > >>>
> > ---------------------------------------------------------------------
> > > > >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > >>> For additional commands, e-mail: users-help@wicket.apache.org
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > >> For additional commands, e-mail: users-help@wicket.apache.org
> > > > >>
> > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
Re: Resolving nested properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
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 <ro...@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 <mg...@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 <
> > tobiassoloschenko@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 <ro...@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
> > > > IModel<String> 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 <
> > > > tobiassoloschenko@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 <ro...@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-unsubscribe@wicket.apache.org
> > > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > >>> For additional commands, e-mail: users-help@wicket.apache.org
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > >> For additional commands, e-mail: users-help@wicket.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
Re: Resolving nested properties
Posted by Rob Sonke <ro...@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 <mg...@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 <
> tobiassoloschenko@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 <ro...@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
> > > IModel<String> 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 <
> > > tobiassoloschenko@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 <ro...@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-unsubscribe@wicket.apache.org
> > >>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Resolving nested properties
Posted by Martin Grigorov <mg...@apache.org>.
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 <
tobiassoloschenko@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 <ro...@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
> > IModel<String> 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 <
> > tobiassoloschenko@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 <ro...@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-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Resolving nested properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
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 <ro...@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
> IModel<String> 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 <
> tobiassoloschenko@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 <ro...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Resolving nested properties
Posted by Rob Sonke <ro...@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
IModel<String> 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 <
tobiassoloschenko@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 <ro...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Resolving nested properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
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 <ro...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Resolving nested properties
Posted by Sven Meier <sv...@meiers.net>.
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 <ro...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Resolving nested properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
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 <ro...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Resolving nested properties
Posted by Rob Sonke <ro...@tigrou.nl>.
Hi Sven,
Ah, that's the same kind of request. I can imagine that it's not a very hot
feature. But we use the variant/style settings to override properties with
kind of "theme" specific labels. But often such a theme only wants to use
different naming for specific elements. With this option, we can simply
override one property in a variant or style, and change a lot of labels all
at once.
I thought actually that this was a default feature in the java
ResourceBundles. But apart from that, I was expecting some feature like
myapp.getResourceSettings().addResourceResolver(new MyCustomResolver());
but this doesnt seem possible. With such an option, we can implement this
easily ourselves.
Rob
On Sat, Feb 21, 2015 at 4:37 PM, Rob Sonke <ro...@tigrou.nl> wrote:
> 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 <ro...@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: Resolving nested properties
Posted by Rob Sonke <ro...@tigrou.nl>.
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 <ro...@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: Resolving nested properties
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,
I dont know if there is a way to do it with Wicket default
ResourceModels, but I implemented a ReplacingResourceModel which is
seaching for the keys marked up with ${key} and replaces it with the
value of that key. I used Wicket 7.x - the API changed a little bit
since 6.x so if you are interested then let us know.
@others: Is there an existing way to do it without implementing a
"ReplacingResourceModel"?
https://github.com/klopfdreh/wicket-components-playground/blob/56cbe3ffd7a0f126f14f6bae77d36e75fd1c4ffc/wicket-components-playground/src/main/java/org/apache/wicket/model/ReplacingResourceModel.java
kind regards
Tobias
P.S.: The implementation is the first shot, so it has to be tested!
Am 21.02.15 um 14:01 schrieb Rob Sonke:
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org