Mailing-List: contact dev-help@click.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@click.apache.org
Message-ID: <468733.12311277208415021.JavaMail.jira@thor>
Date: Tue, 22 Jun 2010 08:06:55 -0400 (EDT)
From: "Bob Schellink (JIRA)" <jira@apache.org>
To: dev@click.apache.org
Subject: [jira] Issue Comment Edited: (CLK-661) Add Java based configuration
In-Reply-To: <30163817.21741271469864852.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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