ant elder wrote:
Supporting OO JavaScript sounds like a good idea to me, and I think I
also
prefer the attribute named 'constructor'. Have you thought about how
properties and references will work with OO? Right now in the Java impl I
set these in the script global scope, with OO I guess they should be
set on
the instance scope.
Here's what I propose:
Option 1:
- You write an SCDL componentType file for your Javascript component
- SCDL properties and references are set as fields on your JavaScript
object by the Tuscany runtime (the runtime invokes the constructor and
then sets the fields on the new object)
Option 2:
- You don't want to write an SCDL componentType file
- In your JavaScript object constructor you do the following:
function Calculator() {
scaproperty(this.precision)
scareference(this.divideService)
}
- This tells the Tuscany runtime what properties and references to
consider, the runtime initializes them on return from the constructor.
Another approach would be to say that all properties of a Javascript
object are potential SCA properties and references, and going even
further that you don't even need to declare them ahead of time. In other
words doing this:
<component...>
<implementation.javascript script="Calculator.js"
constructor="Calculator"/>
<property name="currency">EURO</property>
<reference name="stockQuote">StockQuoteService</reference>
</component>
will create the currency and stockQuote fields on your Calculator
object, without requiring you to initialize/declare these fields in your
constructor.
This approach would be more in line with how you develop with JavaScript
IMO, you don't always declare your fields ahead of time...
Thoughts?
While we're discussing the script language SCDL, one other feature I've
wondered about is embedding the script source in the scdl instead of a
seperate file, maybe in a sub-element to the implementation element. For
short, simple mediation functions that could keep things much more
concise,
and readable.
...ant
I'm less sure about this one. If we did that we'd have to provide good
support for debugging these inline scripts, understand how these scripts
could reference other scripts etc. In general I think Javascript
developers will want to see Javascript and less or no SCDL instead of
having to change their development habits and write Javascript inside
SCDL. I like the "more concise and readable" goal but to me this means
"less SCDL with my Javascript code" instead of "my Javascript code
inside SCDL".
On 9/2/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote:
> How about a C++ JavaScript extension to match the one we have in
> Java/SCA?
> You can use SpiderMonkey [1] which also has E4X support and then
we'd be
> able to switch SCA JavaScript components btw the Java and C++
runtimes.
> Using E4X would mean you don't have the databinding issues when using
web
> services as the data stays as XML, and you could show us how much
faster
> your C++ runtime is compared to the Java one ;)
>
> [1] http://www.mozilla.org/js/spidermonkey/
>
> ...ant
>
> (sorry a bit late replying but I'm still catching up on mail)
>
Sorry, a bit late replying to this one too :) but we first needed to
have a good extension story first. With Pete's and Andy's extension work
we now have a good base for looking into implementation and binding
extensions.
Andy's python extension nicely support OO and non-OO development:
<implementation.python module="CalculatorModule" class="Calculator"/>
if you want to implement your component with a Python Calculator class.
and
<implementation.python module="CalculatorModule"/> if you don't like
OO programming and don't need a Python class but just want to implement
your component with module-level functions.
I think this approach will work with Javascript as well.
If you want to implement your component with a a Javascript object:
<implementation.js script="Calculator.js" prototype="Calculator"/>
or
<implementation.js script="Calculator.js" constructor="Calculator"/>
The "prototype=" form may be more correct w.r.t the Javascript language
(which is prototype based instead of class based), but "constructor=" is
more intuitive to me. So I think I prefer the "constructor=" form.
The Calculator component will be implemented like this:
function Calculator() {
this.add=add
}
function add(a1, a2) {
return a1+a2;
}
The runtime will do:
o = new Calculator()
x= o.add(1,2)
Now if don't care about OO and just want functions you just write:
<implementation.js script="Calculator.js"/>
With this form the JS script will look like this:
function add(a1, a2) {
return a1+a2;
}
And the runtime will just do:
x= add(1, 2)
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
