click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <>
Subject Re: ConfigService Support
Date Thu, 25 Apr 2013 07:55:42 GMT
Yes, this should go in with the next release.

Kind regards


On 2013/04/25 09:23, Dennis M. J. Yerger wrote:
> Hi, Bob. The onInit() method is still there. It's actually calling onConfig() from the
> 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
> 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
> Will this patch be included in the next release?
> ----------------------------------------------------------------------------------------------------
> Date: Thu, 25 Apr 2013 07:02:04 +0200
> From:
> To:
> 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
> 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
>     Click applications are typically configured with a click.xml file. This file is usually
>     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
>     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
>     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
>     named onConfigure() where developers can plug in custom logic to configure their
>     It also defines protected methods for adding pages, interceptors, and other objects
>     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("");
>             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.

View raw message