>the StringResourceModel appears to break its contract since every
LoadableDetachableModel
> should be loaded using its load() method which cannot be used here
Yes, this is inconsistent.
>This should either be fixed ...
load() cannot be overriden "as expected", since it can never work
relative to the assigned components.
Feel free to open a JIRA issue, but please include a suggestion how to
improve this.
Sven
On 08/09/2012 08:21 AM, Matthias Keller wrote:
Hi Sven
Thanks for your explanations.
I do now see why there's this wrapper. However, the
StringResourceModel appears to break its contract since every
LoadableDetachableModel should be loaded using its load() method which
cannot be used here!
I can fix this by just using delegation instead of subclassing but in
my opinion this is just plain wrong that implementors need to know
which classes may be overriden and which do not. We have several
subclasses of StringResourceModel doing some special stuff like
reducing all unresolved properties to the empty string or even
returning a completely different String if not all expressions were
resolved correctly (for cases where the model object itself is null
and thus no properties can be resolved at all) etc...
This should either be fixed so that load() can be overriden and works
as expected or then it should be made final with a notice why it's not
supposed to be overridden.
Shall I open a JIRA for that?
Regards
Matt
On 06.08.2012 21:41, Sven Meier wrote:
Hi Matt,
I don't know about your example but the following makes perfect sense:
new Label("id", new StringResourceModel("foo"));
This way the message is resolved relative to the label.
If the StringResourceModel's constructor is given a component
argument, it doesn't make sense to pass it to other components as
model, since it will be reassigned anyway.
AFAIK this variant is meant to be used ad-hoc without passing it to a
component.
Maybe it would be better for your OurStringResourceModel *not* to
extend StringResourceModel?
Sven
On 08/06/2012 06:38 PM, Matthias Keller wrote:
Hi
I'm having some trouble porting a 1.4 application to 1.5 since we're
using our own subclass of a StringResourceModel implementing load()
in a special way.
However, in some cases this does not work as our subclass might get
wrapped in a AssignmentWrapper and since we do not provide the
component instance (since it's not relevant for this model), load()
is never called on our model but instead the load() method of the
AssignmentWrapper calls the private getString() directly.
I don't see why a model should behave so differently whether it
knows its component or not, and where's the point to do something like:
label = new Label("id");
model=new OurStringResourceModel(..., label);
label.setDefaultModel(model);
just to have load() called on our own model?
Could someone with some insight shed some light on it?
Thanks
Matt
---------------------------------------------------------------------
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
