>>>>> On Fri, 02 Mar 2012 11:33:56 +0100, Bernd Müller <bernd.mueller_at_ostfalia.de> said:
BM> 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 ?
BM> which are the relevant RichFaces and Mojarra classes?
BM> for me, to look into
In Mojarra, it is
jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java.
EB> Is this idea a way to provided a java-based analog for context-param
EB> entries?
BM> yes, it should be
EB> How would the runtime identify the class?
BM> by Annotation, of course.
BM> And, probably, JSF runtime is sufficient and the Annotation should
BM> not be used more than once in an archive.
BM> IDE support is mandatory to work with efficiently
But this needs to map to the web.xml fragment feature, right? In that
feature a "logical" web.xml is assembled from all the fragments found.
This implies that it is valid to have more than one class with our
proposed annotation. Right?
EB> How would the various specifications that want to define
EB> context-param-like properties for this system declare the mapping
EB> between context-param names and getter names?
BM> The other EGs don't have to be convinced. In my judgment it can
BM> be done in JSF alone.
BM> Over the time, maybe, the other EGs will join.
It's ok to define it here, but it must be defined in a way that has
little or no JSF specific syntax or names.
EB> We need to support the "fragment" concept introduced in Servlet 3.0,
EB> does this idea support that concept?
This question stands unanswered.
EB> What value does this provide over context-params in the web.xml?
BM> less XML
BM> to fulfill the promise " ... without XML..."
I believe at has to be more than that. Just trading in a human readable
xml file for something output by the Java compiler from a human readable
Java file isn't enough.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/