cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: Thoughts on generated Javascript
Date Tue, 25 Sep 2007 17:45:14 GMT
Hi Benson,
Agree with your delineation of artifacts here. Re: class collissions - 
not sure that there is anything we can do about them. I say for the 
first version at least we do the last loaded wins that you mention. 
Another option might be that the user can specify a "package prefix" or 
sorts. i.e. each class gets prepended with "acme.foo." I don't think we 
should worry too much about it for now though.

- Dan

Benson Margulies wrote:
> The Javascript project consists of deploying, really, three artifacts:
>
>  
>
> 1)     Some common code to manage communications with a server in
> Firefox/Mozilla or IE. (Don't ask me about https, I have no idea if it
> can be done). This code should only be loaded into the browser once per
> page, or perhaps once, altogether (*).
>
> 2)     Classes generated from the XSD that model the objects used in a
> service. We at Basis never considered the equivalent of the 'Soap 1.1'
> support in CXF, we only worked with per-service schemata. There are some
> issues with what consists of a clean way of managing the namespace in
> Javascript.
>
> 3)     Classes generated from the WSDL that model the operations.
>
>  
>
> (*) I'm wondering if we should even think about the mozilla Javascript
> code-signing mechanism here.
>
>  
>
> A page might talk to more than one service. So, to avoid redundancy, I
> think that we need a somewhat more complex URL structure than simple ?js
> delivering the entire pile. 
>
>  
>
> I have no idea how to avoid chaos if two services have classes in
> common, other than that the last one loaded wins.
>
>  
>
> I'm not especially attached to how the existing code wraps things for
> name isolation. If anyone else has a proposed best practice for mapping
> from a URI to some javascript scoping construct, please speak up.
>
>  
>
>
>   


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Mime
View raw message