Damn, you're right (thanks). An oversight on my part. I guess I have to
do some work on the Localizer as well, so that localizations pulled from
the database are not cached by the Localizer as well.
Regards,
Dave
Uwe Schäfer wrote:
Dave Schoorl schrieb:
updates the cached value. Of course,
> the cache. And force a roundtrip to the database.
>
>
> --
> View this message in context:
> http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24644843.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
>
this message in context:
http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24644843.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
There are other options like:
class MyLocalizer extends Localizer
{
getCacheKey() { if (xxx == yyy) return null} // dont return a cache
key for certain things
}
or
class MyLocalizer extends Localizer
{
public String getString(final String key, final Component component,
final IMo
Dave Schoorl schrieb:
updates the cached value. Of course, when you use an ORM-tool, you can
alternatively use it's second level cache.
i recently look in that corner, and iirc you don´t have to cache them at
all, because wicket does in a layer above (when running in prod).
cu uwe
--
Yes of course. I painted a simplified picture. The idea is that once you
implement your own ComponentStringResourceLoader you can do whatever you
want. It is just the glue between your localization mechanism and
Wicket. E.g. I delegate to a LocalizationManager that is capable of
reading and wri
And so on.
>
> But i guess the price to pay of clearing the whole cache and hitting the
> database again is a nice price to pay without spending time on this.
> --
> View this message in context:
> http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24635970.html
r key/keys.
ClearCacheStrategy // clears entier cache
ClearNonInheritedKeyStratergy //
And so on.
But i guess the price to pay of clearing the whole cache and hitting the
database again is a nice price to pay without spending time on this.
--
View this message in context:
http://www.nabble.com/Localizing-thr
etCachedKey. If the component is null only the key is returned.
> --
> View this message in context:
> http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24635300.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---
nabble.com/Localizing-thru-database-lookup-tp24627686p24635300.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mai
in context:
> http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24635015.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache
Couldn't the String getCacheKey(final String key, final Component component)
be used?
--
View this message in context:
http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24635015.html
Sent from the Wicket - User mailing list archive at Nabbl
.
-igor
On Thu, Jul 23, 2009 at 1:13 PM, Mathias
Nilsson wrote:
>
> maybe there should be methods to clear a part of the cache.
>
> Like getLocalizer().clearKey( key ); and getLocalizer.clearKeys(
> List keys );
>
>
> --
> View this message in context:
> http://www.nabbl
maybe there should be methods to clear a part of the cache.
Like getLocalizer().clearKey( key ); and getLocalizer.clearKeys(
List keys );
--
View this message in context:
http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24633675.html
Sent from the Wicket - User mailing list
ge in context:
http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24633532.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For addit
yep, you can clear the cache by calling localizer.clearCache()
-igor
On Thu, Jul 23, 2009 at 12:42 PM, Mathias
Nilsson wrote:
>
> It looks like Wicket caches the string when it has been loaded ones. Is this
> correct?
> --
> View this message in context:
> http://www.nabble.c
It looks like Wicket caches the string when it has been loaded ones. Is this
correct?
--
View this message in context:
http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24633121.html
Sent from the Wicket - User mailing list archive at Nabble.com
Ok thanks,
have you implemented some sort of cache for this, because we don't want to
get every value from database all the time.
--
View this message in context:
http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24631887.html
Sent from the Wicket - User mailing list archi
I get my localized data from the database. I do that by creating a class
that subclasses
org.apache.wicket.resource.loader.ComponentStringResourceLoader. My
subclass interacts with the database through a dao.
Then in the init-method of my Application, I register my implementation
through a ca
I have used .properties and .xml files in all of my Wicket projects and it
has worked great.
However, quite often someone in the translation team wants to changes some
text, image or something else that is localized in the properties files. Has
anyone moved propeties to database with success? Som
20 matches
Mail list logo
