That gets pretty darn tricky; the current lifecycle of the
SymbolSource service, and its SymbolSourceProvider contributions,
would make this very complicated to accomplish. It's a step away from
a declarative model to an imperative model, and it would necessitate
making the SymbolSource service even more "special" than it currently
is (as it is quite twined into the overall fabric of injection). But
I'll think about it, or some alternative that is as effective.
On Mon, Apr 13, 2009 at 1:55 PM, Markus Joschko
<markus.josc...@gmail.com> wrote:
> That would be great.
> What about adding a new symbolsource depending on a symbol (production-mode).
> This would allow to add a production symbolsource just before the
> application source.
> Here it would be easy to override the dev symbols if needed.
>
>
> On Mon, Apr 13, 2009 at 10:36 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
>> I've been thinking of expanding how symbols are interpreted, so that
>> you could do this kind of thing more easily.
>>
>> I.e.
>>
>> ${jdbc.url} = "jdbc:mysql:${jdbc.hostname}/..."
>> ${jdbc.hostname} =
>> "${jdbchostname.production-mode.${tapestry.production-mode}}"
>> ${jdbc.production-mode.true} = "proddb";
>> ${jdbc.production-mode.false} = "testdb";
>>
>> That is, allow nested symbols that would be expanded to form symbol
>> names, that would then be expanded.
>>
>> On Mon, Apr 13, 2009 at 1:30 PM, Markus Joschko
>> <markus.josc...@gmail.com> wrote:
>>> Isn't that slightly more verbose when trying to retrieve the settings?
>>> A symbol can simply be injected, for a service I would need to inject
>>> the service and then get the value from it.
>>>
>>> Which means I always have to add something into the initialization
>>> mehtod of a page/component.
>>>
>>> - Markus
>>>
>>> On Mon, Apr 13, 2009 at 10:27 PM, Thiago H. de Paula Figueiredo
>>> <thiag...@gmail.com> wrote:
>>>> What about having a service that reads the tapestry.production-mode
>>>> symbol and provides all the settings based on it?
>>>>
>>>> --
>>>> Thiago
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>> Director of Open Source Technology at Formos
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
