You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by si...@avalon.apache.org on 2004/05/01 17:01:43 UTC
[Apache Avalon Wiki] Updated: AvalonMusings
Date: 2004-05-01T08:01:43
Editor: 80.143.56.145 <>
Wiki: Apache Avalon Wiki
Page: AvalonMusings
URL: http://wiki.apache.org/avalon/AvalonMusings
cosmetic changes
Change Log:
------------------------------------------------------------------------------
@@ -1,42 +1,47 @@
-''(this page is part of the wiki materials for ApacheAvalon; avalon main page in the wiki is AvalonProjectPages)''
-
-= Object Naming =
-
-Avalon has followed the principle that concrete objects should avoid directly interacting, but rather interfaces should be used liberally for maximum flexibility. The way the current AvalonNamingPolicy has been working, there are a lot of simple concrete classes that go by the name of Default(interface name). For example, DefaultConfiguration or DefaultServiceManager. Does the word 'Default' convey anything of value? It might be better to name the objects for what they really do. For example, the name MapServiceManager would convey the idea that it's really just a simple adaptor to a Map.
-
-= Auto-Generated Configuration =
-
-I know this is a pipe-dream, but here's an idea. If component uses the accessors on a Configuration object that supply defaults, a complete and consistant Configuration object could be built every time the component is initialized. What if the Configuration could be saved back to whatever medium it came from (XML or some other format)?
-
-For example, a configuration file looks like this:
-
-{{{ <components>
}}}
-{{{ <component name="Widget" class="com.WidgetClass">
}}}
-{{{ <color>green</color>
}}}
-{{{ <oldParamName>true</oldParamName>
}}}
-{{{ </component>
}}}
-{{{ </compoenents>
}}}
-
-You start the container. This code runs:
-
-{{{ class WidgetClass implements Configurable {
}}}
-{{{ public void configure(Configuration config) throws ConfigurationException {
}}}
-{{{ m_maxSize = config.getInt("mamimumWidgetSize", 5);
}}}
-{{{ m_color = config.getString("color", "red");
}}}
-{{{ // auto-upgrade
}}}
-{{{ if (config.getString("oldParamName") != null) config.rename("oldParamName", "newParamName");
}}}
-{{{ config.saveChanges();
}}}
-{{{ }
}}}
-{{{ }
}}}
-
-Suddently the container rewrites the configuration file:
-
-{{{ <components>
}}}
-{{{ <component name="Widget" class="com.WidgetClass">
}}}
-{{{ <color>green</color>
}}}
-{{{ <maximumWidgetSize>5</maximumWidgetSize>
}}}
-{{{ <newParamName>true</newParamName>
}}}
-{{{ </component>
}}}
-{{{ </compoenents>
}}}
-
-I know, I'm dreaming. It'd require a special XML parser that didn't muck up the formatting or remove comments and it would require other weirdness. On the plus side it would mean that keeping XML descriptors and actually classes in sync would be easier. Anyway, just an idle thought.
+''(this page is part of the wiki materials for ApacheAvalon; avalon main page in the wiki is AvalonProjectPages)''
+
+= Object Naming =
+
+Avalon has followed the principle that concrete objects should avoid directly interacting, but rather interfaces should be used liberally for maximum flexibility. The way the current AvalonNamingPolicy has been working, there are a lot of simple concrete classes that go by the name of Default(interface name). For example, DefaultConfiguration or DefaultServiceManager. Does the word 'Default' convey anything of value? It might be better to name the objects for what they really do. For example, the name MapServiceManager would convey the idea that it's really just a simple adaptor to a Map.
+
+= Auto-Generated Configuration =
+
+I know this is a pipe-dream, but here's an idea. If component uses the accessors on a Configuration object that supply defaults, a complete and consistant Configuration object could be built every time the component is initialized. What if the Configuration could be saved back to whatever medium it came from (XML or some other format)?
+
+For example, a configuration file looks like this:
+
+{{{
+ <components>
+ <component name="Widget" class="com.WidgetClass">
+ <color>green</color>
+ <oldParamName>true</oldParamName>
+ </component>
+ </compoenents>
+}}}
+
+You start the container. This code runs:
+
+{{{
+ class WidgetClass implements Configurable {
+ public void configure(Configuration config) throws ConfigurationException {
+ m_maxSize = config.getInt("mamimumWidgetSize", 5);
+ m_color = config.getString("color", "red");
+ // auto-upgrade
+ if (config.getString("oldParamName") != null) config.rename("oldParamName", "newParamName");
+ config.saveChanges();
+ }
+ }
+}}}
+Suddently the container rewrites the configuration file:
+
+{{{
+ <components>
+ <component name="Widget" class="com.WidgetClass">
+ <color>green</color>
+ <maximumWidgetSize>5</maximumWidgetSize>
+ <newParamName>true</newParamName>
+ </component>
+ </compoenents>
+}}}
+
+I know, I'm dreaming. It'd require a special XML parser that didn't muck up the formatting or remove comments and it would require other weirdness. On the plus side it would mean that keeping XML descriptors and actually classes in sync would be easier. Anyway, just an idle thought.
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org