I would really love to take a look into this one
On Thu, Jun 17, 2010 at 1:41 PM, Finn Bock (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/CLK-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Finn Bock updated CLK-661: > -------------------------- > > Attachment: defaultconfigservice.patch > > My view of the DefaultConfigService class is mostly a brainless bean that > stores the information that subclasses put into it. So the patch does not > move any of the automapping methods into the DefaultConfigService, but > leaves it in XmlConfigService. It also leaves the page interceptor handling > for subclasses since I didn't want to add an API for dealing with both > application and request page interceptor. > > > 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. > >
