Re: [Xswt-developer] Xswt-developer digest, Vol 1 #158 - 5 msgs

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

I just got this email; it looks rather old; sorry!

Hallvard Tr=E6tteberg wrote:
> I've now checked in preliminary code for two extension points:
> 1) data-parser extension tag for contributing IDataParsers for specific
> classes. The empty DataParser constructor registers the standard
> IDataParsers and the ones contributed by means of the extension point.
> 2) import extension tag for importing packages and classes in ClassBuil=
ders.
> Importing classes means registering the simple class name as an alias f=
or
> the fully qualified one. This is useful when a package contains many cl=
asses
> that you don't want to expose.
>  =20
Looks good!  Thanks!
> I didn't find org.eclipse.jface.databinding at this location, but I alr=
eady
> have checked out the one at /cvsroot/eclipse !?!
>  =20
:-)  Glad you found it.
>> Since the script is encapsulated in a data binding, data=20
>> binding will=3D20 automatically keep track of when dependent=20
>> objects change and re-run the=3D20 script at the right time. =20
>> (Data binding basically implements kind of a spreadsheet=20
>> recalc engine.  The script is just the formula.)
>>    =20
> I think I understand the basic idea. Being able to trigger script code =
when
> data changes in this way is very neat! Similarly for the listener scrip=
ts.
>
> I have one suggestion: It should be possible to include scripts that de=
fine
> functions that may be accessed from many places, i.e. separate common c=
ode
> and the place where it is activated from. The idea is to evalutate scri=
pts
> in the context of a bindings object (most scripting engines I've seen h=
ave
> an interface for this, that may be used to interface to outside objects=
, a
> kind of global context), and make this available to other scripts. So c=
ommon
> functions may be defined in one place and called from such script bindi=
ngs
> or event handlers. Such a bindings object may also support common varia=
bles.
>  =20
Yes.  Similarly, XSWT doesn't have any notion of a module.  As soon as=20
you let folks build function libraries, you need modules of some sort.
>> The objects in the ID map can then be copied by the=20
>> IScriptable object into the scripting language's=20
>> interpreter.
>>    =20
> I'd rather interface to the idMap by means of the interpreters bindings
> interface, in effect, defining the ids as global variables for the
> script(s). It would also be interesting to map the other way, i.e. make=
 the
> variables and functions defined in scripts available as ids of some kin=
d to
> Xswt.
>  =20
Yes.
>> - Within the scripting language, it would be nice to=20
>> implement autoboxing for IObservableValue types--at least=20
>> for the unboxing side of things.
>>    =20
> pnuts lets you customize property access (field or get/set methods), el=
ement
> access ([] or get(int)) and method invocation for special objects, eith=
er by
> the object itself or by a "object model" object (Configuration). This
> me
Cool.  Yes, I'm liking pnuts more and more.
>> So that's a general description of my vision for how to=20
>> implement scripting in the simplest way possible.  I think=20
>> that the result solves two significant concerns:
>>
>> (1) How to express computed values in XSWT naturally so that=20
>> these values can be bound to user interface controls.
>>    =20
> The only problem is when dependencies are implicit within a script, e.g.
> navigating through a property inside a script will not create a DataBin=
ding
> that will trigger recomputing the result if the property changes. This =
may
> be technically possible, but not desirable as a general mechanism, I gu=
ess.
>  =20
Yes.  This is one thing we need to consider carefully.
>> (2) How to write event handlers in XSWT.
>>    =20
>> I'm a little bit scared about #2.  Part of me still thinks=20
>> that event handlers belong in Java code only.
>> ...
>> Thoughts about this (from anyone) are appreciated.
>>    =20
> I've never liked anonymous classes used for creating listeners (new
> <interface>{ ... }), as they remind me to much of closures without thei=
r
> elegance.
Agreed.
> I'd rather automatically create a wrapper using Proxy which calls
> a function. E.g. define a Function interface, with (scripting) language
> specific implementations (MethodFunction, PnutsFunction, ...), and
> IDataParsers for them. Then write a generic IDataParser for listener
> interfaces, that uses parse(source, Function.class) and wraps it using
> Proxy/InvokationHandler. Sounds like a nice hack, doesn't it?
>  =20
I'm not quite following you here.  Could you provide a quick example of=20
the kind of code this would let you write?


Regards,

Dave Orme