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] Commented: (CLK-661) Add Java based configuration
Date Tue, 22 Jun 2010 23:15:51 GMT

    [ https://issues.apache.org/jira/browse/CLK-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881443#action_12881443
] 

Bob Schellink commented on CLK-661:
-----------------------------------

I'd thought that AnnotationService will extend from the SimpleConfigService, not XML. If AnnotationService
extends from XmlConfigService then users will have to manage two separate configuration files
eg: click.xml and AnnotationService. That would create a lot of confusion. For example, if
a developer arrives at a Click app, finds the click.xml and proceeds to change the "mode"
to trace and nothing happens. Reason is because there is another configService somewhere that
applies an Annotation based "mode".

By extending from SimpleConfigService (or whatever we want to call it) there is only one ConfigService
defined.

Implementation wise I'd imagine this:

AnnotConfigService extends SimpleConfigService {

  public void onInit() {
    String from = ...
    annots = loadAnnotations(from);
    super.onInit();
  }

  protected void loadAutobinding() {
    if (annots.getAutobinding()==null) {
      super.loadAutobinding();
    } else {
      setAutobinding(annots.getAutobinding());
    }
  }
}


> 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