Hi,
I think using your own
org.apache.wicket.resource.loader.IStringResourceLoader impl would be
the best.
Then insert it at the first position with
org.apache.wicket.settings.def.ResourceSettings#getStringResourceLoaders().add(0,
yours)
Then something like this should work:
class MyEditableLabel extends
org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel {
public MyEditableLabel(String id, LoadSaveModel model)
...
}
class LoadSaveModel implements IModel<String> {
@Override
public String getObject() // just as ResourceModel
{
return
Application.get().getResourceSettings().getLocalizer().getString(resourceKey,
null, defaultValue);
}
@Override
public void setObject(String newValue)
{
// save the new value
}
}
On Thu, Feb 23, 2012 at 3:20 AM, Colin Rogers
<colin.rog...@objectconsulting.com.au> wrote:
> Hi,
>
>
>
> We’re using Wicket on a massive project. One of our customer requirements
> has been to enable all strings and text to be easily modifiable by the
> client, and we thought that using Wicket resource bundles would achieve
> this.
>
>
>
> We’ve got an issue, that isn’t a bug – it’s actually the way Wicket was
> designed to work - but is something we need to change to match our clients
> requirements, and I’d hope someone might be able to guide me in the best way
> to achieve this. We’ve been using Wicket 1.4.13 (latest version of 1.4.X
> actually makes our issue more difficult, but I’ll get on to that later.)
>
>
>
> Originally we were creating Containers for use within a Repeating View –
> that sounds odd I know, but the RepeatingView represents a generic container
> for holding major elements on a standard application-wide BasePage – these
> Containers were from unique Classes, for example;
>
>
>
> MyFirstContainer
>
> MySecondContainer
>
> MyThirdContainer
>
> MyForthContainer
>
>
>
> Which enabled us to specify in our properties files as;
>
>
>
> X.Y.1.A.B.C.label = My First Container
>
> X.Y.2.A.B.C.label = My Second Container
>
> X.Y.3.A.B.C.label = My Third Container
>
> X.Y.4.A.B.C.label = My Forth Container
>
>
>
> Since then, we’ve generisied some of our containers as follows;
>
>
>
> MyFirstContainer
>
> MyGenericContainer
>
> MyGenericContainer
>
> MyForthContainer
>
>
>
> This created the issue were the second use of MyGenericContainer picked up
> the label for the first, so that they both said “My Second Container”. I’ve
> written a small test case and included it to illustrate the issue, using
> Labels.
>
>
>
> In the latest version of Wicket, this has been “fixed” even further to
> totally exclude the index of the RepeatingView, meaning there is no
> possibility of any specification of individual resources for components in a
> List or Repeating View, at all.
>
>
>
> As I understand, the way wicket is designed to work would be to pass in the
> value as a parameter, e.g;
>
>
>
> X.Y.1.A.B.C.label = My ${value} Container
>
>
>
> But this breaks internationalisation and externalisation of labels and
> string, and, more importantly, isn’t what our client wants - they want to be
> able to change all elements of labels without code changes.
>
>
>
> While I realise this is the way Wicket was designed to work, I need to
> override this behaviour so that we can specify component resources in
> properties file for Repeating and List Views. Also I need to override this
> behaviour so I can upgrade to the latest version of Wicket without breaking
> our existing specification of labels, that use the index.
>
>
>
> Is there a feature of Wicket that I’ve missed that would better solve this
> issue? Or could anyone be able to guide me as to the best way of going about
> this? I can’t override Component#getString() as it’s finalised. Would
> creating my own ComponentStringResourceLoader be the best way to go about
> it? Or overriding Localizer? Both?
>
>
>
> Cheers,
>
> Col.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
