Hi Dennis,
This is actually long overdue :)
There was some work done in the past to improve ConfigService:
https://issues.apache.org/jira/browse/CLK-661
You might be interested in the comments on that JIRA.
My feeling is that "onConfigure" should be "onInit" as that is consistent with
other services.
Kind regards
Bob
On 2013/04/25 02:34, Dennis M. J. Yerger wrote:
Hello, everyone. I agree with Bob that CDI support fits better as an extra. However, there is
something I believe should be a core part of Click, and that is better configuration support.
Click applications are typically configured with a click.xml file. This file is usually simple and
causes no serious problems. However, I believe Click would be a more flexible framework if it had
less dependence on XML. This would allow Click to be configured in other languages, including
Java. The key to this flexibility is ConfigService. However, implementing this interface is no
small task. Extending XmlConfigService is one way to address this problem, but you're still tied
to XML. I believe the solution is to create a generic abstract class with functionality common to
all configurations. This class can be extended by implementing methods and overriding others.
To demonstrate my idea, I created a class named AbstractConfigService. This class contains all the
same logic as XmlConfigService, minus the XML parsing. It contains an abstract method named
onConfigure() where developers can plug in custom logic to configure their applications. It also
defines protected methods for adding pages, interceptors, and other objects easily. The following
is an example of how the AbstractConfigService API may be used:
public class TestConfigService extends AbstractConfigService {
@Override
protected void onConfigure() throws Exception {
addPackage("click.tapestryioc.page");
addPage("test_1.htm", TestPage1.class)
.setHeader("Pragma", "no-cache")
.setHeader("Cache-Control", "max-age=3600, must-revalidate");
addPage("test_2.htm", TestPage2.class);
addPageInterceptor(TestInterceptor.class, "request")
.setProperty("property1", "value1")
.setProperty("property2", "value2");
}
}
As you can see, this is the same configuration data that would be typically defined in a click.xml
file. I would like to submit my code for consideration in a future release.
