Yes, this should go in with the next release.
Kind regards
Bob
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 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.
