Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta-httpclient/GuidedTourOfHttpCore The comment on the change is: updated for changes in the parameter framework ------------------------------------------------------------------------------ objects involved in processing a message: interceptors, connections, and whatever else other modules are going to add on top of core. [[BR]] + The names of parameters are defined in {{{PNames}}} interfaces, + where each interface lists parameters for a particular part of the framework. + We also have {{{Bean}}} classes for these parameter sets. + These beans don't store the parameters in attributes, but put them into a + parameter map. This comes in handy if you want to use something like the + [http://www.springframework.org/about Spring framework], + which can populate beans from configuration files but wouldn't know what to do with a map. + [[BR]] In the old code, parameters were hierarchical. This feature is still present, - we can link a set of parameters with another one providing defaults. + we can link a map of parameters with another one providing defaults. However, this feature should ''never'' be used by applications directly. Parameters may and will be linked inside the framework, and having both application and framework set up parameter hierarchies would wreak havoc @@ -449, +457 @@ Furthermore, parameters are meant to hold data, whereas the context can hold any kind of attribute. As a rule of thumb, if it is something you'd write into a properties file, that's a candidate for parameters. If you - need to set up a callback at runtime, that does into the context. + need to set up a callback at runtime, that goes into the context. Caution has to be used when updating parameters after they have been passed to the framework. You should avoid to update a parameter set at @@ -478, +486 @@ Are these special implementations of the interface? [[BR]] '''A:''' - Ah, no. We define constants for the various parameters we are using. - Those classes contain the constants, and static helper methods for + Ah, no. Those classes contain static helper methods for getting and setting the respective parameters. This encapsulates typecasts and provides at least some type safety: {{{ @@ -493, +500 @@ '''A:''' No, core is hardcore. We don't deal with configuration via properties files in core. If we supported properties files today, we'd be asked to support - XML configuration tomorrow, and Spring instantiation the day after. + XML configuration tomorrow, and something else the day after. There would be no end to it. Besides, instantiating parameters with the correct type is not trivial. A string parameter needs to be stored as {{{String}}}, whereas an integer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
