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

Reply via email to