click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Finn Bock (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CLK-661) Add Java based configuration
Date Fri, 02 Jul 2010 11:36:50 GMT

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

Finn Bock commented on CLK-661:
-------------------------------

> Why do you say it becomes a mess? 

well, automapping builds on the concept of <pages>, a concept that is not part of the
ConfigService interface, and I have really no idea how you envision the API to express the
<pages> tag.

As far as I can tell in click-annotation there are no use for a <pages> based automapping.
Jahid automaps pages by querying the annotationDB for classes with @Template and inserts these
classes in the path<->class maps.

My own use of the AbstractConfigService also does not need a API based on a <pages>
concept:

    @Override
    public void onInit(ServletContext servletContext) throws Exception {
        super.onInit(servletContext);
        setMode(Mode.DEBUG);
        setFileUploadService(new CommonsFileUploadService());
        setLogService(new Slf4jLogService());
        setResourceService(new MyResourceService());
        setTemplateService(new VelocityTemplateService());

        addPage("/home", HomePage.class);
        ...
    }



Having AbstractConfiogService.deployFiles() only deploy resources on classpath certainly helps,
but still, which class should check for isResourcesDeployable and how should the result and
the warning be comunicated to the other class.



> 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: abstract-config-service.patch, 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