click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis M. J. Yerger" <>
Subject RE: ConfigService Support
Date Thu, 25 Apr 2013 07:23:23 GMT
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
Subject: Re: ConfigService Support

    Hi Dennis,


      This is actually long overdue :)


      There was some work done in the past to improve ConfigService:



      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




      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:


            class TestConfigService extends AbstractConfigService {



              protected void onConfigure() throws Exception {


                  addPage("test_1.htm", TestPage1.class)

                      .setHeader("Pragma", "no-cache")

                      .setHeader("Cache-Control", "max-age=3600,

                  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.

View raw message