[
https://issues.apache.org/jira/browse/CLK-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881198#action_12881198
]
Md. Jahid Shohel commented on CLK-661:
--------------------------------------
Hi Finn and Bob,
The way I see it is, these services (xmlconfigservice,simpleconfigservice,
annotationconfigservice(which is on my doubleclick project)), requires a
massive refactoring. Each of these services should be event driven. I mean, if
these are the standard sequence(at least until now) -
1. loadLogService
2. loadMode
3. loadDeployFiles (must precede loadResourceService as the deployed resources
could be loaded by ResourceService if configured)
4. loadPages
5. order shouldn't matter
Then there should be one implementation which is generating event for all
config services. That way we can maintain the loading sequence. That way, first
it will generated "loadmode" event to the xmlconfigservice to load mode, then
annotationconfigservice to load mode......, then it will generate "load deploy
files", "load pages".... and so on.
The boostraping should not be sequential like as it is now on xmlconfig
service. which takes away the scope of extending/adding more config services
without touching existing one. right now, if we want to put in another config
service (say its simple config service, or annotation config service) we have
to touch the xmlconfigservice. because xmlconfigservice is putting it all
together inside it, and made methods package local or private.
And I absolutely agree with bob, that we should refactor the xmlconfig service
so that it does not takes xmlElm, but takes standard java element.
Please give input about the evendrive approach i mentioned above. if you guys
agree then i will really like to work with this task. right now i am sick, so i
could not finish one or more tasks that I said i will work no. but hope to
return soon.
> 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.
