Am 01.03.2012 20:38, schrieb Edward Burns:
>>>>>> On Tue, 28 Feb 2012 16:03:18 -0800, Alexander Smirnov <alsmirnnov_at_gmail.com> said:
>
> AS> One more context param attribute, with addition to dozens of others...
> AS> You recall me my old idea to put all configuration options into single
> AS> class, where each option has its own getter, with appropriate validation
> AS> and defaults.
> AS> It should read all options from context parameters in default
> AS> implementation, or can be replaced in faces config by custom class.
> AS> RichFaces has such class, and I saw similar in Mijarra implementation. Why
> AS> do not move it into public ?
which are the relevant RichFaces and Mojarra classes?
for me, to look into
>
> I'll bring this up to the Servlet EG, but before doing so, the idea
> needs to be more concrete.
>
> Is this idea a way to provided a java-based analog for context-param
> entries?
yes, it should be
>
> How would the runtime identify the class?
by Annotation, of course.
And, probably, JSF runtime is sufficient and the Annotation should
not be used more than once in an archive.
IDE support is mandatory to work with efficiently
>
> How would the various specifications that want to define
> context-param-like properties for this system declare the mapping
> between context-param names and getter names?
The other EGs don't have to be convinced. In my judgment it can
be done in JSF alone.
Over the time, maybe, the other EGs will join.
>
> We need to support the "fragment" concept introduced in Servlet 3.0,
> does this idea support that concept?
>
> What value does this provide over context-params in the web.xml?
less XML
to fulfill the promise " ... without XML..."
>
> Ed
>
Bernd