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.
