> class SomeParams extends BasicHttpParams {
>
> public static final String SOME_VALUE = "some.value";
>
> public String getSomeValue() {
> return (String) getParameter(SOME_VALUE);
> }
>
> public void setSomeValue(final String value) {
> setParameter(SOME_VALUE, value);
> }
>
> }
>
> Those classes could be arranged into a hierarchy, as you suggested.
This is pretty close to the 3.x style. I felt that the
static utility methods were an improvement over that.
By deriving from BasicHttpParams, a specific implementation
of the HttpParams interface is mandated. Also, a simple
tree would not help to define an AllClientParams which
ties together connection, auth, cookie and other params.
This can only be done easily on the interface level.
If you want to move towards bean-style, maybe:
class SomeParams {
public static final String SOME_VALUE = "some.value";
HttpParams params;
public SomeParams(HttpParams p) {
this.params = p;
}
public String getSomeValue() {
return (String) params.getParameter(SOME_VALUE);
}
...
}
I don't have a feeling how many of those beans would be
instantiated though. And I'm pretty sure the constructor
argument doesn't match the Spring POJO initialization.
Then there's the attribute with sync option:
class SomeParams {
public static final String SOME_VALUE = "some.value";
protected String someValue;
public String getSomeValue() {
return someValue;
}
public void setSomeValue(String v) {
someValue = v;
}
public void readFrom(HttpParams p) {
someValue = (String) p.getParameter(SOME_VALUE);
... // others
}
public void writeTo(HttpParams p) {
p.setParameter(SOME_VALUE, someValue);
... // others
}
}
But I'm afraid that synchronizing the contents of such
beans with a set of parameters will be hard to manage.
Also, it will fetch parameters that are not actually
needed in many cases.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
