Editable localized messages

2010-07-14 Thread Harald Wellmann
The combination of wicket:message and custom IStringResourceLoader is really 
cool for building internationalized applications. We currently use a 
combination of static strings from property files and dynamic strings stored in 
a database table loaded via an IStringResourceLoader.

To edit a dynamic string, you need to know its key. Now it would be even cooler 
if you could simply click on a rendered string to open an edit form for the 
correct key.

E.g. when a page is in edit mode (as indicated by a request parameter or an 
authentication role), wicket:message is rendered not just as text but as a 
link. Clicking the link generates a request including the message key so you 
can open an edit form for the key.

I'm not sure where to hook into Wicket's default behaviour to implement this 
kind of logic or if there are better approaches - any suggestions welcome.

Best regards,

Harald


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Editable localized messages

2010-07-14 Thread Martin Grigorov
Check org.apache.wicket.markup.resolver.WicketMessageResolver
This is the default handler for wicket:message and it is registered in
org.apache.wicket.Application.internalInit()

See whether you can extend it.
The idea is to generate a href=... super.onComponentTagBody() /a

On Wed, 2010-07-14 at 13:54 +0200, Harald Wellmann wrote:
 The combination of wicket:message and custom IStringResourceLoader is 
 really cool for building internationalized applications. We currently use a 
 combination of static strings from property files and dynamic strings stored 
 in a database table loaded via an IStringResourceLoader.
 
 To edit a dynamic string, you need to know its key. Now it would be even 
 cooler if you could simply click on a rendered string to open an edit form 
 for the correct key.
 
 E.g. when a page is in edit mode (as indicated by a request parameter or an 
 authentication role), wicket:message is rendered not just as text but as a 
 link. Clicking the link generates a request including the message key so you 
 can open an edit form for the key.
 
 I'm not sure where to hook into Wicket's default behaviour to implement this 
 kind of logic or if there are better approaches - any suggestions welcome.
 
 Best regards,
 
 Harald
 
 
 -
 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: Editable localized messages

2010-07-14 Thread Igor Vaynberg
or rather create a component and use that instead of wicket:message

-igor

On Wed, Jul 14, 2010 at 5:21 AM, Martin Grigorov mcgreg...@e-card.bg wrote:
 Check org.apache.wicket.markup.resolver.WicketMessageResolver
 This is the default handler for wicket:message and it is registered in
 org.apache.wicket.Application.internalInit()

 See whether you can extend it.
 The idea is to generate a href=... super.onComponentTagBody() /a

 On Wed, 2010-07-14 at 13:54 +0200, Harald Wellmann wrote:
 The combination of wicket:message and custom IStringResourceLoader is 
 really cool for building internationalized applications. We currently use a 
 combination of static strings from property files and dynamic strings stored 
 in a database table loaded via an IStringResourceLoader.

 To edit a dynamic string, you need to know its key. Now it would be even 
 cooler if you could simply click on a rendered string to open an edit form 
 for the correct key.

 E.g. when a page is in edit mode (as indicated by a request parameter or an 
 authentication role), wicket:message is rendered not just as text but as a 
 link. Clicking the link generates a request including the message key so you 
 can open an edit form for the key.

 I'm not sure where to hook into Wicket's default behaviour to implement this 
 kind of logic or if there are better approaches - any suggestions welcome.

 Best regards,

 Harald


 -
 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



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



AW: Editable localized messages

2010-07-14 Thread Harald Wellmann
Hmm, yes, but then I'd have to add lots of tiny components to my pages. One of 
the main points of wicket:message is to avoid just that, isn't it?

Regards,
Harald

Von: Igor Vaynberg [igor.vaynb...@gmail.com]

or rather create a component and use that instead of wicket:message

-igor

On Wed, Jul 14, 2010 at 5:21 AM, Martin Grigorov mcgreg...@e-card.bg wrote:
 Check org.apache.wicket.markup.resolver.WicketMessageResolver
 This is the default handler for wicket:message and it is registered in
 org.apache.wicket.Application.internalInit()

 See whether you can extend it.
 The idea is to generate a href=... super.onComponentTagBody() /a

 On Wed, 2010-07-14 at 13:54 +0200, Harald Wellmann wrote:
 The combination of wicket:message and custom IStringResourceLoader is 
 really cool for building internationalized applications. We currently use a 
 combination of static strings from property files and dynamic strings stored 
 in a database table loaded via an IStringResourceLoader.

 To edit a dynamic string, you need to know its key. Now it would be even 
 cooler if you could simply click on a rendered string to open an edit form 
 for the correct key.

 E.g. when a page is in edit mode (as indicated by a request parameter or an 
 authentication role), wicket:message is rendered not just as text but as a 
 link. Clicking the link generates a request including the message key so you 
 can open an edit form for the key.

 I'm not sure where to hook into Wicket's default behaviour to implement this 
 kind of logic or if there are better approaches - any suggestions welcome.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org