Hi, Bob. The onInit() method is still there. It's actually calling onConfig() from the abstract base class, along with other methods. I named my method onConfigure() because it is only part of the initialization process. In addition to calling onConfigure(), onInit() sets default values and initializes services. My example did not illustrate this. I apologize for the misunderstanding.
I checked the JIRA you linked to. I looked at the implementation of AbstractConfigService posted there, and it looks good. I think I may use it as a basis for my own ConfigService implementations to support annotations, convention over configuration, etc.. And you're right, it's long overdue. Will this patch be included in the next release? Date: Thu, 25 Apr 2013 07:02:04 +0200 From: [email protected] To: [email protected] Subject: Re: ConfigService Support 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.
