click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CLK-661) Add Java based configuration
Date Tue, 22 Jun 2010 12:06:55 GMT

    [ 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.


Mime
View raw message