your class loads one file from one directory if app is in dev mode,
another if app in deploy mode. not everyone wants this. further we
would have the names of properties configurable. another pain. maybe
someone wants to use an xml file to load properties because key value
pairs are not enough, should we support that as well? the rabbit hole
goes down pretty far.

the application settings are meant there for you to configure wicket,
not your own application.

simply expose the properties in the application and then your
components can get them like this:

MyApplication.get().getProperty("foo");

not so bad.

write a IComponentInstantiationListener and inject the properties, so
you can have

@Properties Properties props; fields in your component that are
magically populated.

there is no one way to do this, and its certainly not the job of the
UI layer to handle it for you. thus we do not do it.

as a last note, you can leverage wicket's i18n to load properties
stored in your MyApplication.properties.

getString("myproperty") is all you need.

-igor


On Sat, Jan 29, 2011 at 11:02 AM, Christian Grobmeier
<grobme...@gmail.com> wrote:
> On Sat, Jan 29, 2011 at 6:27 PM, Igor Vaynberg <igor.vaynb...@gmail.com> 
> wrote:
>> that actually looks pretty simple to me...
>
> On first glance yes. But bringing the application parameters into
> another component or api will become complicated.
>
> WIth this code I can only extend my Application with a new method
> (getProperties). I have to introduce a new interface to make my
> components generic, otherwise I need casting.
>
> I looked at the ApplicationSettings and I am wondering why this class
> does not provide the functionality to set user defined parameters in
> key/value manner. Are there any reasons against this? I can imagine a
> loadUserProperties which does what I wrote below and stores the
> key/values in ApplicationSettings.getValue( String key)
>
> ---------------------------------------------------------------------
> 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

Reply via email to