Oh sorry! Anyway, I would go for the suggested improvement.
@Ernesto: correct!
.
@Sven: this is true but ValidationError has #setMessage(), #setKeys(),
#addKey() for setting more specific message/keys. So the application has
much better control.
I agree - consistency is really important!
So one way is to keep it as it is now.
Another way is to apply:
---
i/wicket-core/src/main/java/org/apache/wicket/validation/ValidationError.java
+++
w/wicket-core/src/main/java/org/apache/wicket/validation/ValidationError.java
@@ -138,6 +138,7 @@ public final class ValidationError implements
IValidationError
public ValidationError addKey(IValidator<?> validator)
{
Args.notNull(validator, "validator");
+ addKey(Classes.name(validator.getClass()));
addKey(Classes.simpleName(validator.getClass()));
return this;
}
everywhere where only the simple name is currently used as a key, e.g. for
converters. This way it will be improved and backward compatible. A bit
slower too!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Aug 12, 2014 at 8:04 AM, Ernesto Reinaldo Barreiro <
[email protected]> wrote:
Hi Andrea,
On Mon, Aug 11, 2014 at 10:31 PM, Andrea Del Bene <[email protected]>
wrote:
Hi Sven,
I think i18n uses the full name (i.e it uses clazz.getName() ). See line
135 of ComponentStringResourceLoader.
I think that is to locate the file where properties are: if I understand
correctly Martin refers to the key on that method.
Hi Martin,
it's the same as for other i18n strings, e.g. validators:
They use the simple class name as resource key too.
Regards
Sven
On 08/08/2014 10:40 AM, Martin Grigorov wrote:
Hi,
While adding an entry to the migration guide about the new way to set
custom CSS class names [1] I realized a small problem:
What if the application needs to use the same functionality for its own
class with a simple name matching of of the Wicket's ones ?
For example "Folder"
(org.apache.wicket.extensions.markup.html.repeater.tree.content.Folder)
At the moment Wicket-extenstions' Initializer.properties define these:
Folder.CSS.other=tree-folder-other
Folder.CSS.closed=tree-folder-closed
Folder.CSS.open=tree-folder-open
Folder.CSS.selected=selected
so if the application has class com.example.Folder then these keys
cannot
be used. OK, it will use custom keys, but suppose the application uses
Folder.CSS.mine=value for its com.example.Folder and in some later
version
Wicket introduce the same key (mine) for its Tree Folder. Boom! The
application will have to change its key to something new to avoid the
clash.
Should we use the full name instead ?
1.
https://cwiki.apache.org/confluence/display/WICKET/
Migration+to+Wicket+7.0#MigrationtoWicket7.0-
Usei18npropertyfilesforCSSclassnamesWICKET-5257
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
--
Regards - Ernesto Reinaldo Barreiro
