[jira] Commented: (CLK-661) Add Java based configuration

["Adrian A. (JIRA)" <ji...@apache.org>]

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

Adrian A. commented on CLK-661:
-------------------------------

> - no compile time checking
> - no JavaDoc help in IDE
IMHO this is not a disadvantage of Click's XML configuration, but a shortcoming of IDE plug-ins/configuration.

The IDE could enforce the DTD to show "compilation" like errors (red stripes on the right margin like Java compiler errors).
Also the IDE plug-ins could simply forward the QuickHelp from the corresponding XML tag (to the mapped java method doc) - like they already do with the many other XML files (ANT build.xml, Maven POM xml, etc.)
E.g. IntelliJ already code completes in click.xml the classes and packages values - I suppose NB and Eclipse might know that too.

Besides the effort, extra code, the Java based configuration also has the constant disadvantage that compilation is required on every change.

IMHO the best idea is to have very good defaults - they can keep the XML file very small.
In most of my projects too (like other Click users mentioned), click.xml is the file that changes the least (once I configure it at project start).

For better configuration support, IMHO, the effort would be worth in improving the IDE plug-ins like mentioned above.
As some other Click committers said: "this is something that belongs more into a tool (an external tool), not the (runtime)framework" :).




> Add Java based configuration
> ----------------------------
>
>                 Key: CLK-661
>                 URL: https://issues.apache.org/jira/browse/CLK-661
>             Project: Click
>          Issue Type: Improvement
>            Reporter: Bob Schellink
>             Fix For: 2.3.0
>
>
> 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.