Thoughts on generated Javascript

[Benson Margulies <bi...@basistech.com>]

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.

 

Re: Thoughts on generated Javascript

[Dan Diephouse <da...@mulesource.com>]

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