click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Md. Jahid Shohel (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CLK-661) Add Java based configuration
Date Sat, 03 Jul 2010 17:18:51 GMT

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

Md. Jahid Shohel commented on CLK-661:
--------------------------------------

>I'm also not sure that autobinding should be switched on/off at the page level, instead
if could be moved to the app level.

If we support modularity, then app level autobinding might not be reasonable. Because each
module should have option to live in its own world.

>In the XmlConfigService impl you'll note that the last autobinding setting overrides the
others, so it is currently an application wide setting as well. 

Yes, its the last configuration which overrides all other early configurations. I am not sure
if we should call this an application wide settings or not. Because its confusing. Configuration
wise its seems to developer that, they are configuring page or package wise, but in fact its
not.


>Btw I haven't looked at the code so there might be some pitfalls I'm overlooking. 

I did not run into a debate, but the way I see it is, those config services does not scale
(development wise). The implementation does not include a clear chaining of config services.
The way it works right now is, there can be only one config service. I think that is the main
problem here.



> 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