You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Mathias Nilsson <wi...@gmail.com> on 2009/07/23 16:57:36 UTC
Localizing thru database lookup
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? Something like
component // The wicket component
language // the language
country // the country
variant // the variant
key // the key
value // the actual value
This could allow text to be changed thrue a web form. If the text was
changed a callback to the resource loader to refresh the value.
Can anyone lead me to the right path of implementing this. What classes
should I look at? Has someone used something like this and is the
.properties, .xml preferred over the database?
It would be nice to not have to redeploy the whole application if just a
text should be altered.
// Mathias
Re: Localizing thru database lookup
Posted by Dave Schoorl <ma...@cyber-d.com>.
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, 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
>
>
>
> ---------------------------------------------------------------------
> 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: Localizing thru database lookup
Posted by Uwe Schäfer <sc...@thomas-daily.de>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Dave Schoorl <ma...@cyber-d.com>.
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 writing from/to the database and that uses a cache. The
LocalizationManager is also used when the values are updated by a web
form. It saves the new value to the database and when present, it
updates the cached value. Of course, when you use an ORM-tool, you can
alternatively use it's second level cache.
Mathias Nilsson wrote:
> 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.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 archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Dave Schoorl <ma...@cyber-d.com>.
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 call to:
getResourceSettings().addStringResourceLoader(new
MySubclassOfComponentStringResourceLoader());
//Dave
Mathias Nilsson wrote:
> 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? Something like
>
> component // The wicket component
> language // the language
> country // the country
> variant // the variant
> key // the key
> value // the actual value
>
>
> This could allow text to be changed thrue a web form. If the text was
> changed a callback to the resource loader to refresh the value.
> Can anyone lead me to the right path of implementing this. What classes
> should I look at? Has someone used something like this and is the
> .properties, .xml preferred over the database?
>
> It would be nice to not have to redeploy the whole application if just a
> text should be altered.
>
> // Mathias
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Igor Vaynberg <ig...@gmail.com>.
thats fine, but do be careful. there is a lot of tricky stuff in the
default localizer code that builds cache keys and manages the cache.
it is easy to make a mistake and cache too much or use the wrong cache
key and get the wrong resource returned back.
-igor
On Fri, Jul 24, 2009 at 6:48 AM, Mathias
Nilsson<wi...@gmail.com> wrote:
>
> Thanks,
>
> I think extending or writing my Localizer would be the path to go.
>
> * Rolling my own cache that gets the key from the primary key in the
> database.
> * If an administrator updates a value then I can delete the primary key from
> 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.
>
>
> ---------------------------------------------------------------------
> 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: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.com>.
Thanks,
I think extending or writing my Localizer would be the path to go.
* Rolling my own cache that gets the key from the primary key in the
database.
* If an administrator updates a value then I can delete the primary key from
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Johan Compagner <jc...@gmail.com>.
There are other options like:
class MyLocalizer extends Localizer
{
getCacheKey(xxxx) { 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 IModel model,
final String defaultValue) throws MissingResourceException
{
// do your own stuff when you see its a key from the db:
if (key.startswith(mydbkey))
{
// do you own stuff
}
else return super getString(key, component, model,defaultValue)
}
}
On Thu, Jul 23, 2009 at 16:57, Mathias Nilsson
<wi...@gmail.com>wrote:
> 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? Something like
>
> component // The wicket component
> language // the language
> country // the country
> variant // the variant
> key // the key
> value // the actual value
>
>
> This could allow text to be changed thrue a web form. If the text was
> changed a callback to the resource loader to refresh the value.
> Can anyone lead me to the right path of implementing this. What classes
> should I look at? Has someone used something like this and is the
> .properties, .xml preferred over the database?
>
> It would be nice to not have to redeploy the whole application if just a
> text should be altered.
>
> // Mathias
>
Re: Localizing thru database lookup
Posted by Igor Vaynberg <ig...@gmail.com>.
there is only one correct way to clear the cache, so i do not see why
that needs to be externalized.
-igor
On Thu, Jul 23, 2009 at 3:47 PM, Mathias
Nilsson<wi...@gmail.com> wrote:
>
> Yes I get you point.
>
> What about assigning clearing strategies that can be added and implemented.
> let's say it's sufficient for me to just clear the cache if the component is
> not a subclass of another component. I can implement my own strategy for
> clearing the cache or 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-thru-database-lookup-tp24627686p24635970.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.com>.
Yes I get you point.
What about assigning clearing strategies that can be added and implemented.
let's say it's sufficient for me to just clear the cache if the component is
not a subclass of another component. I can implement my own strategy for
clearing the cache or 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-thru-database-lookup-tp24627686p24635970.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Igor Vaynberg <ig...@gmail.com>.
class B extends A
class C extends A
A.properties { foo=bar }
Component b=new B();
Component c=new C();
b.getString("foo");
c.getString("foo");
someone edits A.properties in the database
ui calls clearkey("foo",b) <== does not clear the cache used by (c),
need to call clearkey("foo", set of all descendants of A that loaded
the key)
this is just a class hieararchy example, what about component
hierarchy examples where multiple descendant components can inherit
keys from their parent component?
-igor
On Thu, Jul 23, 2009 at 3:01 PM, Mathias
Nilsson<wi...@gmail.com> wrote:
>
> Ok maybe there is a lot of work for this issue. It isn't a problem when using
> wicket ComponentStringResourceLoader is just a problem if we need to access
> the database all the time for a string and clear the entier cache if the
> database is updated.
>
> when looking at the source for Localizer#getCachedKey it returns the whole
> path, with style and locale. If I implemented a clearCachedKey like this. (
> just on top of my head )
>
> /**
> * Clear a key from the cache.
> *
> */
> public void clearCachedKey( final String key, final Component component ){
> if( cache == null ) return;
> String cachedKey = getCacheKey( key, component );
> if( cachedKey != null ){
> cache.remove( cachedKey );
> }
> }
>
> wouldn't that be sufficient. The entire locale, style is taken care of by
> the getCachedKey. 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.
>
>
> ---------------------------------------------------------------------
> 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: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.com>.
Ok maybe there is a lot of work for this issue. It isn't a problem when using
wicket ComponentStringResourceLoader is just a problem if we need to access
the database all the time for a string and clear the entier cache if the
database is updated.
when looking at the source for Localizer#getCachedKey it returns the whole
path, with style and locale. If I implemented a clearCachedKey like this. (
just on top of my head )
/**
* Clear a key from the cache.
*
*/
public void clearCachedKey( final String key, final Component component ){
if( cache == null ) return;
String cachedKey = getCacheKey( key, component );
if( cachedKey != null ){
cache.remove( cachedKey );
}
}
wouldn't that be sufficient. The entire locale, style is taken care of by
the getCachedKey. 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Igor Vaynberg <ig...@gmail.com>.
the point is that there can be more then one component that use the
property key.
-igor
On Thu, Jul 23, 2009 at 2:31 PM, Mathias
Nilsson<wi...@gmail.com> wrote:
>
> 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 Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.com>.
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 Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Igor Vaynberg <ig...@gmail.com>.
you are more then welcome to add an rfe, however it is not a simple fix.
the cachekey currently contains a lot more information then just the
propertykey and its all sandwiched into a single string, it contains
the whole path. remember, in wicket components can inherit properties
form their super class, as well as resolve properties based on locale,
style, and variation.
to implement what you want we would have to break the string up into
an object with multiple properties, then the clearcachekey() method
would have to iterate over all cache keys and match any that use that
property.
-igor
On Thu, Jul 23, 2009 at 1:13 PM, Mathias
Nilsson<wi...@gmail.com> wrote:
>
> maybe there should be methods to clear a part of the cache.
>
> Like getLocalizer().clearKey( key ); and getLocalizer.clearKeys(
> List<String> keys );
>
>
> --
> View this message in context: http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24633675.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.com>.
maybe there should be methods to clear a part of the cache.
Like getLocalizer().clearKey( key ); and getLocalizer.clearKeys(
List<String> keys );
--
View this message in context: http://www.nabble.com/Localizing-thru-database-lookup-tp24627686p24633675.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.com>.
Ok thanks,
that would clear the whole cache. is there already a method to clear just
one localized message.
here is the thing, I want the administrator to be able to update a key,
value. I don't want to clear the whole cache just the one key connected to
the cache.
--
View this message 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Localizing thru database lookup
Posted by Igor Vaynberg <ig...@gmail.com>.
yep, you can clear the cache by calling localizer.clearCache()
-igor
On Thu, Jul 23, 2009 at 12:42 PM, Mathias
Nilsson<wi...@gmail.com> 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.com/Localizing-thru-database-lookup-tp24627686p24633121.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Localizing thru database lookup
Posted by Mathias Nilsson <wi...@gmail.com>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org