Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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 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
wicket.program...@gmail.comwrote:
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
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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 Nilssonwicket.program...@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-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
Re: Localizing thru database lookup
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-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
Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
yep, you can clear the cache by calling localizer.clearCache() -igor On Thu, Jul 23, 2009 at 12:42 PM, Mathias Nilssonwicket.program...@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-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
Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
maybe there should be methods to clear a part of the cache. Like getLocalizer().clearKey( key ); and getLocalizer.clearKeys( ListString 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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 Nilssonwicket.program...@gmail.com wrote: maybe there should be methods to clear a part of the cache. Like getLocalizer().clearKey( key ); and getLocalizer.clearKeys( ListString 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-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
Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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 Nilssonwicket.program...@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-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
Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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
Nilssonwicket.program...@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-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
Re: Localizing thru database lookup
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Localizing thru database lookup
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 Nilssonwicket.program...@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-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
