Hi Vinh, The custom-serializer-on-the-client-side problem is definitely a troublesome issue. The root cause of the problem is that we do not know which schema types should be mapped to which Java classes. Our last idea was to add annotations to the WSDL so that we could be sure to do the mapping correctly; if this is done, then we can fill in the arrays you see in the generated client code with the right types/values and have your custom serializers invoked automatically (per your last email). We could also automatically generate the boilerplate code to register the custom serializers. You wouldn't have to augment the generated client, it would already convert the DOM Elements to your custom types.
I'd like to avoid a separate client-side descriptor if at all-possible (the server side is already complicated enough, there's no reason the client programmer should have to suffer as well ;) ), but I would definitely like to solve this problem. Do you think WSDL annotations would be acceptable? It's not an excellent solution, but I don't think there are really any "excellent" solutions to this problem. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/30/2006 05:52:13 PM: > When creating custom serializers to handle custom types, I need to > specify the serializer classes in muse.xml on the server side. Muse > will automatically load and handle them for me. But, on the client > side, my code must still explicitly load and register the serializers > before it can handle the custom types. > > This brings up an idea: most of the current Muse implementation focuses > on the server side framework. I think a more robust client framework > should be built, too. For example, since the server framework can > autoload from wsdls and descriptor files, the same logic can be expanded > on the client side. This will: > > 1) Shield client developers from needing to know the low level details > of the server design, like what serializers to use for what custom > types, the xml structure of requests/responses, etc. Clients shouldn't > need to deal with serializers directly. The framework should do that > automatically. > 2) Reduce the code that client developers need to write just to make a > single call to the server. > 3) Allow clients to build on a framework consisting of config/descriptor > files just as is done on the server. > > I'm guessing this effort shouldn't take much work because the API's are > already there. They just need to be modularized and exposed to the > client, or built into a client framework. Any thoughts? > -Vinh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
