DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture ------- Additional Comments From [EMAIL PROTECTED] 2003-09-04 14:26 ------- I don't like the generic approach so much. It involves defining property names which introduce typos and requires converting data representations. If you know you need a boolean to indicate whether redirects should be chased or not (just to give an example), give it a setter and a getter and let the compiler check for typos. To me, a generic mechanism is something for "things we haven't thought about", or "things we couldn't know about" in Eric's case. Useful, but rather a fallback than a preferred choice. Unfortunately, I won't find the time to look at the code in the near future. But is there a way to have base class that provides a generic mechanism and to use adapter classes for the individual components? Something like: HttpParams: generic parameters and conversion methods from and to strings HttpClientParams: specific getters and setters for the client's properties, kept in attributes. Constructor and/or readFrom(HttpParams) to initialize the attributes, and saveTo(HttpParams) to write them back. HttpMethodParams: like HttpClientParams, just for the HttpMethodBase params HttpGetMethodParams: derived from HttpMethodParams, adding some GET-specific attributes. ...and so on for every component that defines parameters I know this may create a lot of new classes, but I always was a friend of lots of (simple) classes :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
