Hi Everyone. I'd like to get your thoughts on ClientFacade API design. Please read below.
I've been meaning to talk about the design of ClientFacade for awhile now. Because this is an abstraction of HttpUnit, I knew it would be challenging to get this API just right. Thanks to those of you who have added suggestions and comments.
I think that the ClientFacade is proving to be very convenient, especially because it allows you to refer to client elements by component ID, which is what JSF relies upon. It is nice to be able to just say
The problem comes in because you sometimes need the full power that HttpUnit provides. This has already been shown in the case of secure pages and setting headers.
The current API for ClientFacade looks like this:
To fix this once and for all, we would remove the constructor that takes a username/password in favor of one that takes a WebConversation. And, we would add a getWebConversation() method.
WebConversation webConversation = WebConversationFactory.makeWebConversation(); .. // add username/password, headers, etc. .. ClientFacade client = new ClientFacade(webConversation, initialPage); // Access to internal WebConversation if you need it. You might need // to do this if you used the single-arg constructor for ClientFacade. WebConversation webConv = client.getWebConversation();
We would keep the single-arg constructor:
ClientFacade client = new ClientFacade(initialPage);
Right now, ClientFacade is not a clean facade because it allows access to some of the HttpUnit internals. If we add getWebConversation(), we will have these two methods that bleed through the facade:
WebResponse response = client.getWebRespons(); WebConversation webConv = client.getWebConversation();
And to some extent, this one bleeds as well:
WebForm form = client.getForm(componentID);
Maybe this is OK. Or maybe we can improve things?
Thoughts from anyone on this list? Is the ClientFacade API too polluted with HttpUnit? Is there a cleaner way to do this?