[
https://issues.apache.org/jira/browse/CLK-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881179#action_12881179
]
Bob Schellink edited comment on CLK-661 at 6/22/10 8:05 AM:
------------------------------------------------------------
Hi Finn,
This is a good start. My idea was to have a standalone Java based configuration
that can be used in place of the click.xml file. While click.xml is quite
simple and easy to read it becomes cumbersome when configuring multiple
services or having dynamic behavior based on the production vs development
modes.
I shouldn't have called it DefaultConfigService since XmlConfigService will
still be the default. Perhaps SimpleConfigService or even AbstractConfigService
is a more apt name. Guess it will depend on how this service ends up being
implemented.
Ideally SimpleConfigService should be usable on its own with a minimal amount
of configuration. I can imagine the following:
public class MyCorpConfigService extends SimpleConfigService {
@Override
protected List<String> loadPagePackages() {
return Collections.singletonList("com.mycorp");
}
}
This could be enough to get a basic application up and running using the
automapping feature to load pages from the given package.
The order in which some services are loaded is quite sensitive so I agree with
Jahid comments[1] that it shouldn't be left to the subclasses as they would
likely get it wrong. If necessary we could group together related services.
From memory I think the following order must be maintained:
1. loadLogService
2. loadMode
3. loadDeployFiles (must precede loadResourceService as the deployed resources
could be loaded by ResourceService if configured)
4. loadPages
5. order shouldn't matter
So assuming we agree that SimpleConfigService should be usable on its own, the
question comes how we expect users to customize it. On the face of it it seems
like a good fit for Template Pattern where the SimpleConfigService contains the
driver code and expose some loadXXX methods which users or subclasses can
override to return alternate implementations. XmlConfigService already follows
this pattern except the loadXXX methods are private and accepts a rootElm as
argument. This does highlight an immediate issue on how XmlConfigService would
override the loadXXX methods. Since SimpleConfigService won't pass any
arguments to its methods, the Xml rootElm would need to be stored as a variable
on XmlConfigService for these methods to access.
Anyway I've rambled enough, let me know what you think.
[1]: http://markmail.org/message/4iyaqlqyroyw7rjs
was (Author: sabob):
Hi Finn,
This is a good start. My idea was to have a standalone Java based configuration
that can be used in place of the click.xml file. While click.xml is quite
simple and easy to read it becomes cumbersome when configuring multiple
services or having dynamic behavior based on the production vs development
modes.
I shouldn't have called it DefaultConfigService since XmlConfigService will
still be the default. Perhaps SimpleConfigService or even AbstractConfigService
is a more apt name. Guess it will depend on how this service ends up being
implemented.
Ideally SimpleConfigService should be usable on its own with a minimal amount
of configuration. I can imagine the following:
public class MyCorpConfigService extends SimpleConfigService {
public List<String> loadPagePackages() {
return Collections.singletonList("com.mycorp");
}
}
This could be enough to get a basic application up and running using the
automapping feature to load pages from the given package.
The order in which some services are loaded is quite sensitive so I agree with
Jahid comments[1] that it shouldn't be left to the subclasses as they would
likely get it wrong. If necessary we could group together related services.
From memory I think the following order must be maintained:
1. loadLogService
2. loadMode
3. loadDeployFiles (must precede loadResourceService as the deployed resources
could be loaded by ResourceService if configured)
4. loadPages
5. order shouldn't matter
So assuming we agree that SimpleConfigService should be usable on its own, the
question comes how we expect users to customize it. On the face of it it seems
like a good fit for Template Pattern where the SimpleConfigService contains the
driver code and expose some loadXXX methods which users or subclasses can
override to return alternate implementations. XmlConfigService already follows
this pattern except the loadXXX methods are private and accepts a rootElm as
argument. This does highlight an immediate issue on how XmlConfigService would
override the loadXXX methods. Since SimpleConfigService won't pass any
arguments to its methods, the Xml rootElm would need to be stored as a variable
on XmlConfigService for these methods to access.
Anyway I've rambled enough, let me know what you think.
[1]: http://markmail.org/message/4iyaqlqyroyw7rjs
> Add Java based configuration
> ----------------------------
>
> Key: CLK-661
> URL: https://issues.apache.org/jira/browse/CLK-661
> Project: Click
> Issue Type: Improvement
> Reporter: Bob Schellink
> Assignee: Finn Bock
> Fix For: 2.3.0-M1
>
> Attachments: defaultconfigservice.patch
>
>
> click.xml has grown over the years especially since we introduced the service
> based architecture. Some of the problems with xml based configurations is:
> - no compile time checking
> - no JavaDoc help in IDE
> I propose we add a new DefaultConfigService class that is Java based which
> XmlConfigService extends from.
> Its advantages is the polar opposite of xml disadvantage:
> - compile time checking
> - JavaDoc help in IDE
> - More powerful configuration options, e.g. its possible to configure
> FileUpload in ways not exposed by xml config. Also possible to create more
> powerful algorithms e.g. which templates to include/exclude.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
