I was doing this at first, hinging many things on the production mode
symbol.  But things got hairy and I needed more flexibility.
I wanted a central place where settings based on "production mode" were
being decided, and that was taking place either the app module or a child
module.  Even using a central location to keep things consistent, I ended up
with very verbose code.  Maybe that's just me, but I was trying my best.

Now I have reordered my symbol providers so that it looks in a context.xml
that resides in a separate place from my deployed war.  Those context files
hardly change on production, but for test/development it's nice to flip just
a few switches to turn on certain features in the app.  (I do restart the
app container so the changes take effect)

I probably have 20 to 25 symbols that get looked up by Tapestry for doing
things like displaying cookie values in a grid (as a bean!),
enabling/disabling menu items and certain parts of the app, disabling
regular user logins, and performing startup functions (such as how the app
should behave if it can't connect to the db on startup), etc.

Anyway, it's nice to have

@Inject
@Property("${helpdesk.email}}
private String helpdeskemail

Now a sys-admin can go in there and change the email address, etc, restart
the service and no have to bother me about it.

If it helps any, you can group your production/dev symbols into a similar
area of your context/property file so it's easy to make the changes you
want.

On Mon, Apr 13, 2009 at 4:25 PM, Markus Joschko <markus.josc...@gmail.com>wrote:

> Hi list,
> I have a couple of settings which are dependent on the environment I am in.
> E.g. pathes that are different on my dev environment compared with the
> prod environment.
>
> Normally I would use symbols to store the values but I don't want to
> make all of them SystemProperties
> but rather base them on the Production_mode symbol of tapestry. Is
> there a way to specify new symbols which are different based on
> another symbol?
> Or how do you manage these settings?
>
> Thanks,
>  Markus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>

Reply via email to