Re: [Xswt-developer] scripting

[David J. O. <dj...@co...>]

Hallvard Tr=E6tteberg wrote:
>> (Like you, I have two small children, so I'm pretty sure I'm=20
>> not in a position to try to get a PhD myself right now.
>>    =20
> The most promising part of my PhD is in fact a visual dataflow language=
 for
> UI components (named Diamodl, for Dialog modelling language) combined w=
ith
> Statecharts.=20
I've downloaded and been gradually working through your thesis.  It=20
looks cool, but it's not light reading either. :-)
> I hope to be able to combine Diamodl with XSWT in a way that
> lets the developer focus on concrete (XSWT) and/or abstract (Diamodl)
> elements as she wishes, while making them work painlessly together. But
> don't be afraid, I'm not trying to introduce Diamodl concepts into XSWT=
,
> just to make XSWT more powerful on its own.
>  =20
:-)  I'd love to collaborate on this.  I'm comfortable that we have a=20
similar vision for how the XSWT code base needs to be layered.
>> I can imagine several ways to think about this:
>>
>> 1) An XSWT file including its scripts and bindings behaves=20
>> like a single Java class.  Basically, we piggyback onto=20
>> Java's modularity semantics.
>>
>> 2) Something like what you propose: x:id in a script defines=20
>> a namespace for the script.  You can access stuff in that=20
>> namespace using dotted notation.  Multiple script tags with=20
>> x:ids of the same value may aggregate their contents into a=20
>> single namespace of the x:id's name.
>>    =20
> I've made pnuts work with x:ids in a single namespace. However, I found=
 it
> difficult to read the pnuts code, since it was difficult to spot which
> identifiers were pnuts variables and which were controls. The alternati=
ve is
> to utilize pnuts' own package mechanism. x:ids are inserted into the id
> package and the identifiers defined in a script are inserted into a pac=
kage
> with the script's x:id. Code will then refer to XSWT controls with pnut=
s'
> own package syntax, e.g. id::resultText.text =3D "" + (n1 + n2). The sc=
ripts
> may be broken into pieces and evaluated in their own packages, and
> references across scripts/packages will use the same :: notation that i=
s
> part of pnuts "native" syntax.
>
> The design I'm aiming for, should let the specific scripting language d=
ecide
> how scripts are separated from each other, using the language's own
> modularisation mechanism, e.g. pnuts' packages. A scripting language
> extension may also decide to not support modularisation and refer to x:=
ids
> directly.
>  =20
This sounds sensible, but I think we should eventually publish some kind=20
of recommendation about how to do this so that we don't wind up with=20
widely diverging implementations.
>>> 2) Is it OK to make a single function handle all methods of an=20
>>> interface, using Proxy/InvokationHandler.
>>>
>>>      =20
>> I really like dynamic proxies.  However, I'm hoping that at=20
>> some point we can get JFace to bring us back into Eclipse as=20
>> a subproject.  JFace is written to Foundation Profile, so=20
>> dynamic proxies are out.
>>    =20
>
> Aha, because it's not supported by every platform, like Pocket PC/Perso=
nal
> Java. Perhaps it's OK to use proxies for scripting, but not for data
> binding, since scripting usually entails a more powerful platform (byte=
code
> manipulation)?
>  =20
:-)  Okay go ahead.  We'll hope Eclipse doesn't make us take them out=20
again at some point.
>>> Do we still want to support=20
>>> SWTSourceBuilder? If we don't, we may do a lot of=20
>>> refactoring, also of the reflection code, to clean up the=20
>>> current code.
>>>  =20
>>>      =20
>> One of the advantages of keeping all our IDs in a single=20
>> namespace is that the semantics then stay mapped 1:1 onto=20
>> Java's semantics, making it possible (at least theoretically)=20
>> to support SWTSourceBuilder.  The XSWT compiler is really=20
>> larval right now, but I suspect that it might be necessary to=20
>> effectively support the embedded space.
>>    =20
> The current problem with IDataParsers and SWTSourceBuilder, is that the
> IDataParser must be able to both parse a string and translate the resul=
t
> into Java code that (re)constructs the same object. Suppose
> Integer.valueOf(String) is parsed into a reference to the Java method
> valueOf(String) in the Integer class. Then that IDataParser must also b=
e
> able to generate the code for finding that method, i.e. something like =
try {
> return Integer.class.getMethod("valueOf", new Class[]{String.class}); }
> catch (Exception e) {}
> Won't this essentially require adding a generateSource-method to the
> IDataParser interface? Or have I completely misunderstood (e.g. the
> IDataParsers may be part of the runtime)?
>  =20
No, there's a separate set of objects--the ICodeGenerator interface and=20
its implementations that handle this sort of thing.
>> What are your thoughts about all of these things?
>>    =20
> These are my thoughts 40 minutes past midnight after a very nice dinner=
 :-)
>  =20
Thanks for taking the time to write them down and I'm sorry I've taken=20
so long to get back to you. :-)
> I hope to summarise my current design for basic scripting next week (I'=
ll be
> away for the weekend at a mountain cottage, with only solar power). I
> haven't considered the data binding aspects, yet, but I believe that a
> Function (interface) that encapsulates a script should make data bindin=
g and
> scripting quite independent.
>  =20
Agreed that data binding is independent.

I'm slowly but surely making progress on the XSWT Builder.  After seeing=20
how nice it is to play with data binding interactively using the XSWT=20
Preview, I've decided to try to make the XSWT Builder operate on=20
completely live GUI objects.  So if this works out, you'll be able to=20
play with your objects live--including real data if you use data=20
binding--at the same time as you're designing your UI, right in the build=
er.


Best Regards,

Dave Orme