Craig,
Yes, we are thing along the same lines. As an example, I have a version
hardcoded to
MyFaces renderers in place [1][2]. I suspect configuring a digester type
utility that
reads faces-config.xml located in the class path like JSF implementation do,
but also
allows a file to be passed into the utility, would work very well.
After I hard coded the MyFaces stuff, I tried to run it using Sun's RI. As you
alluded to,
it failed since the package and class names are different.
Paul Spencer
[1]
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/AbstractTomahawkJsfTestCase.java?view=markup
[2]
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java?view=markup
Craig McClanahan wrote:
On 1/1/07, Paul Spencer [EMAIL PROTECTED] wrote:
How do I load faces-config.xml when running a test based on
AbstractJsfTestCase?
My current testing manually adds the renderers during setUp(). This
work,
but it has the
following drawbacks:
1) The association between a component and it renderer must be maintained
in more
then one place.
2) Testing with more then one JSF Implementation is a lot of extra work.
Ideally I would like to instruct shale-test to load the implementation's
jsf configuration file, i.e. faces-config.xml. How do I do this?
There is an outstanding Shale RFE for this feature already[1], and seeing
what you were doing kind of motivated me to start working on it a bit in
between plays in the football games today :-). My thinking is to
provide an
optional utility helper (based on Commons Digester) with a parse(URL)
method
that you could call to register things like components, converters,
validators, renderkits, and renderers. The parser would typically be
called
during a setUp() method of a test case.
We'll still have an implementation-specific issue for dealing with the
registration of the standard components (since MyFaces and the RI use
different resource names), but that's probably something that can be
abstracted into a get me the URL(s) of the standard component definitions
method that could isolate the differences into one place.
Is this what you had in mind?
Paul Spencer
Craig
[1] https://issues.apache.org/struts/browse/SHALE-262
