You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Kevin Brown (JIRA)" <ji...@apache.org> on 2008/01/23 14:18:34 UTC
[jira] Created: (SHINDIG-33) Refactor GadgetServer to take a
configuration class in the ctor.
Refactor GadgetServer to take a configuration class in the ctor.
----------------------------------------------------------------
Key: SHINDIG-33
URL: https://issues.apache.org/jira/browse/SHINDIG-33
Project: Shindig
Issue Type: Improvement
Components: Gadgets Server - Java
Reporter: Kevin Brown
Assignee: Kevin Brown
GadgetServer is currently easy to configure incorrectly. This should be resolved by introducing a GadgetConfig class. Prototype as follows:
class GadgetConfig () {
private RemoteContentFetcher fetcher;
public setRemoteContentFetcher(RemoteContentFetcher fetcher) {
this.fetcher = fetcher;
return this;
}
...other injectable classes here...
Change GadgetServer's ctor to this:
public GadgetServer(GadgetConfig config) {
if (config.getRemoteContentFetcher() == null) { throw new GadgetException(...)}
.. check other injectable classes...
This solves two problems:
- Moving all the necessary config to the ctor causes the ctor to take 9 or 10 parameters, which hurts readability and makes distinguishing parameters difficult.
- Keeping the various set* methods on GadgetServer makes it too easy to forget to do something, and you won't find out until process() is called (can't check at startup)
The creation call can now look like this:
GadgetServer s = new GadgetServer(new GadgetConfig()
.setRemoteContentFetcher(...)
.setGadgetCache(...)
.setMessageBundleCache(...));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-33) Refactor GadgetServer to take a
configuration class in the ctor.
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Brown resolved SHINDIG-33.
--------------------------------
Resolution: Fixed
Implemented in revision 614753
> Refactor GadgetServer to take a configuration class in the ctor.
> ----------------------------------------------------------------
>
> Key: SHINDIG-33
> URL: https://issues.apache.org/jira/browse/SHINDIG-33
> Project: Shindig
> Issue Type: Improvement
> Components: Gadgets Server - Java
> Reporter: Kevin Brown
> Assignee: Kevin Brown
>
> GadgetServer is currently easy to configure incorrectly. This should be resolved by introducing a GadgetConfig class. Prototype as follows:
> class GadgetConfig () {
> private RemoteContentFetcher fetcher;
> public setRemoteContentFetcher(RemoteContentFetcher fetcher) {
> this.fetcher = fetcher;
> return this;
> }
> ...other injectable classes here...
> Change GadgetServer's ctor to this:
> public GadgetServer(GadgetConfig config) {
> if (config.getRemoteContentFetcher() == null) { throw new GadgetException(...)}
> .. check other injectable classes...
> This solves two problems:
> - Moving all the necessary config to the ctor causes the ctor to take 9 or 10 parameters, which hurts readability and makes distinguishing parameters difficult.
> - Keeping the various set* methods on GadgetServer makes it too easy to forget to do something, and you won't find out until process() is called (can't check at startup)
> The creation call can now look like this:
> GadgetServer s = new GadgetServer(new GadgetConfig()
> .setRemoteContentFetcher(...)
> .setGadgetCache(...)
> .setMessageBundleCache(...));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.