xswt-developer — Talk about developing/developing with XSWT

Re: [Xswt-developer] the XML parser

[Drews, H. <H....@ce...>]

Hello,

I have started to experiment with XSWT by using the latest binary download.

I have also checked out the plugin project and found, that there are a lot
of enhancements and modifications.
E.g. the samples in the project don't work with the installed plugin.

Which of the projects in the source repository are required to build an
installable plugin?
Are there some guidelines available?

Best regards,
Heinz   

Re: [Xswt-developer] the XML parser

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

Hallvard Tr=E6tteberg wrote:
>>> Phrased another way: Do we still have to base our design on a one-pas=
s=20
>>> parsing process?
>>>      =20
>> Not in my book.  For modules, I think we need some kind of=20
>> in-memory tree we can use to represent XSWT in an=20
>> intermediate form.  Naturally, we'll walk that tree as many=20
>> times as the module is used.  Or the style is used.  Or=20
>> something like that. :-)
>>    =20
> OK, this is similar to how I view it. In the case we stick to a pull pa=
rser,
> we may build the tree ourselves, but it's far better to (re)use en exis=
ting
> parser.
>  =20
Agreed.
>> if we can find a way to not need swappable parsing layers,
>> I would prefer to not have a swappable XML parser API.
>>    =20
> I think understand what you mean. What we could do us define a minimal =
API
> that may be wrapped around an existing parser, so we have something to =
work
> on until we settle on the small one. E.g. we define IMinimumParser, wra=
p it
> around XOM (which is the one I'm familiar with), and rewrite XSWT to us=
e
> IMinimumParser. This will let us work on the stylesheet design, without
> becoming too parser-specific. When we find our desired parser, we first=
 wrap
> it in a IMinimumParser adapter, and if desired we migrate to an interfa=
ce
> fitting that parser better, or to that the parser's native API. The cod=
e
> using the parser is anyway so local that there's not much work migratin=
g as
> long as it is based on an in-memory tree. Of course, this process may b=
e
> simplified if we can settle on the parser right away.
>
> Based on my knowledge about how the current parser is used, we need met=
hods
> for:
>
> - loading the tree from a URL or InputStream: rootElement =3D
> parser.build(InputStream)
> - getting the namespace uri and name of an element:
> element.getNamespaceURI() and element.getName()
> - getting the child elements of an element: element.getChildElementCoun=
t()
> and element.getElement(int)
> (I don't think the current design requires getting an element's parent)
> - getting that attributes of an element, and their name, namespace uri =
and
> value of an attribute:
> element.getAttributeCount() and getAttributeName(int),
> getAttributeNamespaceURI(int) and getAttributeValue(int)
> - getting the text of an element: element.getText()
>
> It wouldn't take much time defining such an experimental interface and =
wrap
> it around XOM. Rewriting XSWT shouldn't be that hard either. Although X=
SWT's
> code is complicated from using a pull parser, the logic is fairly
> straight-forward.
>  =20
I'm still of two minds about this.

One of the things we all like about XSWT is that it _isn't XUL_.  It=20
comes from a "less is more" design philosophy.  Lightweight is better. =20
Avoid abstraction.  Tight coupling is a feature, not a bug. =20
37signals.com.  XSWT itself is small enough that the overhead for=20
abstraction is often not worth the weight.

On the + side for this idea, having such a layer would make this=20
migration easier because we could first introduce the XML parser=20
abstraction layer while keeping KXML, then swap out KXML with something=20
else.  And then migrating again would be even easier, should we ever=20
need (or want) to do it.  And as long as we want to stay relevant to=20
embedded folks, it seems that we will always be using non-mainstream=20
parsers...

If you feel strongly that having the abstraction is worth more than the=20
weight it would add, I think I'll defer to your opinion.  If you're not=20
totally convinced yourself, then let's keep discussing it.


Regards,

Dave Orme

Re: [Xswt-developer] the XML parser

[<ha...@id...>]

> -----Original Message-----
> Date: Wed, 28 Jun 2006 22:49:00 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: Re: [Xswt-developer] Design of XSWT: 1) use of XSWTException
> 	and 2) the	XML parser
>
> > Phrased another way: Do we still have to base our design on a one-pass 
> > parsing process?
> >
> Not in my book.  For modules, I think we need some kind of 
> in-memory tree we can use to represent XSWT in an 
> intermediate form.  Naturally, we'll walk that tree as many 
> times as the module is used.  Or the style is used.  Or 
> something like that. :-)

OK, this is similar to how I view it. In the case we stick to a pull parser,
we may build the tree ourselves, but it's far better to (re)use en existing
parser.

> if we can find a way to not need swappable parsing layers,
> I would prefer to not have a swappable XML parser API.

I think understand what you mean. What we could do us define a minimal API
that may be wrapped around an existing parser, so we have something to work
on until we settle on the small one. E.g. we define IMinimumParser, wrap it
around XOM (which is the one I'm familiar with), and rewrite XSWT to use
IMinimumParser. This will let us work on the stylesheet design, without
becoming too parser-specific. When we find our desired parser, we first wrap
it in a IMinimumParser adapter, and if desired we migrate to an interface
fitting that parser better, or to that the parser's native API. The code
using the parser is anyway so local that there's not much work migrating as
long as it is based on an in-memory tree. Of course, this process may be
simplified if we can settle on the parser right away.

Based on my knowledge about how the current parser is used, we need methods
for:

- loading the tree from a URL or InputStream: rootElement =
parser.build(InputStream)
- getting the namespace uri and name of an element:
element.getNamespaceURI() and element.getName()
- getting the child elements of an element: element.getChildElementCount()
and element.getElement(int)
(I don't think the current design requires getting an element's parent)
- getting that attributes of an element, and their name, namespace uri and
value of an attribute:
element.getAttributeCount() and getAttributeName(int),
getAttributeNamespaceURI(int) and getAttributeValue(int)
- getting the text of an element: element.getText()

It wouldn't take much time defining such an experimental interface and wrap
it around XOM. Rewriting XSWT shouldn't be that hard either. Although XSWT's
code is complicated from using a pull parser, the logic is fairly
straight-forward.

Hallvard

Re: [Xswt-developer] Design of XSWT: 1) use of XSWTException and 2) the XML parser

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

I also would value anybody's input to these questions, particularaly Jan=20
and Yu since you two have helped a lot in the past.

Hallvard Tr=E6tteberg wrote:
> The current design of XSWT uses XSWTException to signal that something =
is
> wrong during a parse. This is usually fatal, i.e. it results in abortin=
g the
> parse and giving the end-user an error message. Based on this, several =
of
> the helper objects (DataParser, LayoutBuilder, ...) throw an XSWTExcept=
ion
> when they cannot return an object, e.g. when an ID cannot be resolved o=
r a
> tag cannot be resolved to a class. This design makes it cumbersome to h=
ave
> several strategies for interpreting a tag/attribute, since each strateg=
y
> must be wrapped in a try/catch block.
> <snip/>
> This would be a lot more elegant if either 1) the check for ID was move=
d
> into LayoutBuilder, in case it must take the tag as input, and not the
> object class, or 2) change the protocol to use null instead of
> XSWTException.
>
> I go for 1), but I thought I'd ask the list.
>  =20
(1) sounds fine to me.
> Another question concerning the parser: We currently use the KXML parse=
r,
> but a switch has been suggested. Does this also imply switching from pu=
ll
> parsing to one building an element tree?
Yu (who works for Nokia and I think probably knows a thing or two about=20
small devices) suggested that we use the tree parser from the eRCP=20
project at Eclipse.
> The difference is big if you want
> to be able to save a reference to a node (e.g. style node) and parse it=
 one
> or more times later. Ideally, the parser should live behind an interfac=
e
> that makes it easy to switch parser, but it's difficult to make a pull
> parser look like a tree builder (the other way around is easy).=20
>
> Phrased another way: Do we still have to base our design on a one-pass
> parsing process?
>  =20
Not in my book.  For modules, I think we need some kind of in-memory=20
tree we can use to represent XSWT in an intermediate form.  Naturally,=20
we'll walk that tree as many times as the module is used.  Or the style=20
is used.  Or something like that. :-)
> BTW, it may be desirable to have two interfaces, IParser and ITreeParse=
r
> (extends IParser), and define that some features require the latter. A =
small
> and fast pull parser for a limited device could then still be used, alt=
hough
> with a more limited XSWT feature set.
>  =20
Yu, do you see any reason to keep a pull parser as an option?

I would prefer to have as little abstraction as possible around the=20
actual parser and choose a small fast parser that has a good likelihood=20
of being around for awhile.  Or to say the same thing differently, if we=20
can find a way to not need swappable parsing layers, I would prefer to=20
not have a swappable XML parser API.  (Hallvard, if you disagree, please=20
feel free to do so publicly and we'll talk until we reach a consensus.)


Best regards,

Dave Orme

[Xswt-developer] Design of XSWT: 1) use of XSWTException and 2) the XML parser

[<ha...@id...>]

Hi,

The current design of XSWT uses XSWTException to signal that something =
is
wrong during a parse. This is usually fatal, i.e. it results in aborting =
the
parse and giving the end-user an error message. Based on this, several =
of
the helper objects (DataParser, LayoutBuilder, ...) throw an =
XSWTException
when they cannot return an object, e.g. when an ID cannot be resolved or =
a
tag cannot be resolved to a class. This design makes it cumbersome to =
have
several strategies for interpreting a tag/attribute, since each strategy
must be wrapped in a try/catch block.

Example: In XSWT a LayoutBuilder is used for constructing an object from =
a
tag/class name/Class. If this fails, I want to check if the tag is an ID =
(as
suggested in a previous message), in case the corresponding object =
should be
used. However, instead of checking if the LayoutBuilder returns =
non-null, I
must wrap the call with a try/catch and use the DataParser (again =
wrapped in
a try/catch):

		XSWTException xe =3D null;
		try {
			result =3D layoutBuilder.construct(klass, parent,
style, widgetName, parser.getColumnNumber(), parser.getLineNumber());
		} catch (XSWTException e1) {
			xe =3D e1;
		}
		if (result =3D=3D null) {
			try {
				result =3D dataParser.parse(tagName,
Widget.class);
			} catch (XSWTException e) {
			}
		}
		if (result =3D=3D null) {
			throw (xe !=3D null ? xe : new XSWTException("No ID
named " + tagName));
		}

This would be a lot more elegant if either 1) the check for ID was moved
into LayoutBuilder, in case it must take the tag as input, and not the
object class, or 2) change the protocol to use null instead of
XSWTException.

I go for 1), but I thought I'd ask the list.

Another question concerning the parser: We currently use the KXML =
parser,
but a switch has been suggested. Does this also imply switching from =
pull
parsing to one building an element tree? The difference is big if you =
want
to be able to save a reference to a node (e.g. style node) and parse it =
one
or more times later. Ideally, the parser should live behind an interface
that makes it easy to switch parser, but it's difficult to make a pull
parser look like a tree builder (the other way around is easy).=20

Phrased another way: Do we still have to base our design on a one-pass
parsing process?

BTW, it may be desirable to have two interfaces, IParser and ITreeParser
(extends IParser), and define that some features require the latter. A =
small
and fast pull parser for a limited device could then still be used, =
although
with a more limited XSWT feature set.

Hallvard

---
Hallvard Tr=E6tteberg (ha...@id..., http://www.idi.ntnu.no/~hal)
Associate Professor, IS group, Dept. of Computer and Information =
Sciences at
the Norwegian Univ. of Science and Technology

Re: [Xswt-developer] ID as tag

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

>> Hmmmm.... This is an interesting idea.  In the abstract it
>> sounds like it could be a good idea.  I'm interested in
>> adding the feature but I don't have a clear sense yet for the
>> tradeoff between advantages and disadvantages with having the feature.
>>
>> Can you provide a sample of the kind of code you want to
>> write that this would enable to put in concrete terms the
>> benefit that this would provide?
>
> There's actually two thing to discuss: 1) The general need for "patchin=
g"
> an
> existing object, whether or not it was created by XSWT and 2) splitting
> the
> definition of an object into several parts.
>
> 1) The general need for "patching" an existing object, by making it the
> current object.
> The method tag mechanism, e.g. getShell uses this, to patch an object t=
hat
> can be navigated to by means of a method call. This is relevant in the
> context of define tags, i.e. an object is provided by the context and
> further configured by XSWT. This is different from the defaults that ar=
e
> part of the define tag, which are used only when there is no contextual
> object present (e.g. in the editor).
>
> 2) Splitting the definition of an object into several parts
> I have an example I'm currently exploring: I have a student who's
> implemented an instant messaging client integrated into Eclipse and the
> JDT
> UI, which I would like to make more customizable by means of XSWT. In t=
he
> new design, we need a settings UI and object. For deployment locally, m=
any
> of the settings have reasonable defaults, like Jabber server id, port e=
tc.
> So these will have specific values for our server, while other sites ma=
y
> use
> other values. To indicate that these values should be edited (at least
> considered), I would separate the "mandatory" part from the "customizab=
le"
> part in the XSWT file.

Reminds me of Ruby mixins...  Or at least will be once we figure out how
to make XSWT modular.

Sounds fine.  :-)


Best regards,

Dave Orme

Re: [Xswt-developer] extensions

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

>> > There are three
>> > contributions: IDataParser, imports to ClassBuilder and
> ScriptingEngines.
>> > I think we should decide case by case if the technique is OK. I don'=
t
>> > have any strong feeling about this, there are two requirements:
>> > ensuring XSWT can run without the XswtPlugin and support these
>> > extensions.
>>
>> Another thought:  We currently require the developer to
>> create an instance of the XSWT object, which itself contains
>> an instance of DataParser and a ClassBuilder.  Is it possible
>> for this configuration to be done on these instance variables
>> and not using extension points?  Then all plugin-specific
>> configuration could be confined to just that plugin's scope.
>>
>> If we can choose this way of configuring XSWT, it seems like
>> it might be a more lightweight way to do it than using
>> extension points?
>>
>> Which way do you think would be simpler and more elegant?
>
> A third solution is to add an XSWTConfiguration class, to hold
> IDataParsers,
> ClassBuilder imports and Scripting engines, and give such an object to
> XSWT.
> This way, all configuration goes through an XSWT instance (not static
> variables of several classes), it's easy to control the specific
> configuration and easy to extend with other features later. An
> XSWTConfiguration can be managed by the XswtPlugin, to fit in with the
> standard extension mechanism.
>
> If this sounds OK, I'll quickly implement it.

Yes, I like this.  Hibernate does something similar where you can say:

session.configure().setSomething(setting);

Naturally, configure() returns the Configuration object.


Best regards,

Dave Orme

Re: [Xswt-developer] ID as tag

[<ha...@id...>]

> -----Original Message-----
> Date: Mon, 26 Jun 2006 12:03:12 -0500 (CDT)
> From: "David Orme" <dj...@co...>
> Subject: Re: [Xswt-developer] ID as tag
> To: xsw...@li...
> 
> Hmmmm.... This is an interesting idea.  In the abstract it 
> sounds like it could be a good idea.  I'm interested in 
> adding the feature but I don't have a clear sense yet for the 
> tradeoff between advantages and disadvantages with having the feature.
> 
> Can you provide a sample of the kind of code you want to 
> write that this would enable to put in concrete terms the 
> benefit that this would provide?

There's actually two thing to discuss: 1) The general need for "patching" an
existing object, whether or not it was created by XSWT and 2) splitting the
definition of an object into several parts.

1) The general need for "patching" an existing object, by making it the
current object.
The method tag mechanism, e.g. getShell uses this, to patch an object that
can be navigated to by means of a method call. This is relevant in the
context of define tags, i.e. an object is provided by the context and
further configured by XSWT. This is different from the defaults that are
part of the define tag, which are used only when there is no contextual
object present (e.g. in the editor).

2) Splitting the definition of an object into several parts
I have an example I'm currently exploring: I have a student who's
implemented an instant messaging client integrated into Eclipse and the JDT
UI, which I would like to make more customizable by means of XSWT. In the
new design, we need a settings UI and object. For deployment locally, many
of the settings have reasonable defaults, like Jabber server id, port etc.
So these will have specific values for our server, while other sites may use
other values. To indicate that these values should be edited (at least
considered), I would separate the "mandatory" part from the "customizable"
part in the XSWT file.

Hallvard

Re: [Xswt-developer] extensions

[<ha...@id...>]

> -----Original Message-----
> Message: 5
> Date: Mon, 26 Jun 2006 12:28:06 -0500 (CDT)
> From: "David Orme" <dj...@co...>
> Subject: Re: [Xswt-developer] extensions
> To: xsw...@li...
> 
> > There are three
> > contributions: IDataParser, imports to ClassBuilder and
ScriptingEngines.
> > I think we should decide case by case if the technique is OK. I don't 
> > have any strong feeling about this, there are two requirements: 
> > ensuring XSWT can run without the XswtPlugin and support these 
> > extensions.
> 
> Another thought:  We currently require the developer to 
> create an instance of the XSWT object, which itself contains 
> an instance of DataParser and a ClassBuilder.  Is it possible 
> for this configuration to be done on these instance variables 
> and not using extension points?  Then all plugin-specific 
> configuration could be confined to just that plugin's scope.
> 
> If we can choose this way of configuring XSWT, it seems like 
> it might be a more lightweight way to do it than using 
> extension points?
> 
> Which way do you think would be simpler and more elegant?

A third solution is to add an XSWTConfiguration class, to hold IDataParsers,
ClassBuilder imports and Scripting engines, and give such an object to XSWT.
This way, all configuration goes through an XSWT instance (not static
variables of several classes), it's easy to control the specific
configuration and easy to extend with other features later. An
XSWTConfiguration can be managed by the XswtPlugin, to fit in with the
standard extension mechanism.

If this sounds OK, I'll quickly implement it.

Hallvard

Re: [Xswt-developer] extensions

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

>> Without seeing your code I can't comment in detail, but is
>> there a way to not use static fields?  Designers tend to view
>> static fields as evil and in the context of Eclipse, this is
>> magnified.
>> ...
>> Maybe this situation doesn't apply to what you did (I can't
>> tell without seeing the code), but I wanted to make sure we
>> discussed it.
>
> When a plugin contributes an extension, it will affect the extended plu=
gin
> "globally", similar to changing a static field. In this case, it adds
> objects to a list, which the receiver uses for some purpose. There are
> three
> contributions: IDataParser, imports to ClassBuilder and ScriptingEngine=
s.
> I
> think we should decide case by case if the technique is OK. I don't hav=
e
> any
> strong feeling about this, there are two requirements: ensuring XSWT ca=
n
> run
> without the XswtPlugin and support these extensions.

Another thought:  We currently require the developer to create an instanc=
e
of the XSWT object, which itself contains an instance of DataParser and a
ClassBuilder.  Is it possible for this configuration to be done on these
instance variables and not using extension points?  Then all
plugin-specific configuration could be confined to just that plugin's
scope.

I imagine this might cause problems for scripting?

If we can choose this way of configuring XSWT, it seems like it might be =
a
more lightweight way to do it than using extension points?

Which way do you think would be simpler and more elegant?

>> 1) The Great Renaming that we discussed.  (Making all plugins
>> and packages start with net.sf.xswt.)
>
> I'll leave this one to you. It's better done without too many people
> involved.

:-)  Totally agree.

>> 2) The XSWT style sheet proposal / implementation.
>
> I'll take a look at your suggested syntax, and see if I get some
> inspiration
> :-) I think my last thought on this was that it would be a lot easier i=
f
> we
> had an element tree, instead of doing pull parsing (my own framework
> supported copying/inserting/transforming nodes from other parts of the
> tree).

Agreed.  KXML is also no longer supported.  Yu You suggests that we switc=
h
to Eclipse's XML parser from the eRCP project.

>> 3) Start coming up to speed on the XSWT editor code base.
>
> With only two weeks left before my vacation, I think I'll have to wait.

:-)  It's easier than you think, especially if we can set up a Skype/VNC
code jamming session so I can help you get started.  But it would probabl=
y
be better to wait until after we ship our next release (which I think I'l=
l
label a beta since there are so many changes).

>> 4) Documentation.
>
> Are you thinking of a separate document or as javadoc?

I'm thinking of a Programmer's Guide.  Basically, expanding the "getting
started guide" I have on my web site into a full tutorial covering all of
the XSWT language features plus scripting and data binding.

This is one of my next tasks once I've got the code base back in a
releasable state; if you'd like to help, that might be fun. :-)

>> > I have hacked together a pnuts extension module, based on XOM (XML
>> > parsing) + TagSoup (converts ugly HTML to XHTML), ... it supports
>> > simple UIs for fetching and displaying data from GET-based web
>> services.
>> >
>> This would make an awesome screencast!  :-)
>
> I'll try to think of a good example, to inspire people.

Hmmm... Thinking randomly: Maybe something that can search Amazon and
return the results in a UI?  I'll post again if I have more ideas...


Regards,

Dave

[Xswt-developer] XSWT compiler

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

Just a quick note:  For the first time in about 3 years, I actually used
the XSWT compiler for production code last Friday.  Amazingly, it worked
nearly perfectly.

Here's the glitch we found:  XSWT used to require a top-level Composite
from which everything had to be a child.  The new syntax doesn't require
this and the compiler doesn't currently know how to assign a consistent
variable name to the top-level parent Composite in the source code.  So w=
e
just added a top-level Composite container in the XSWT code.

Otherwise, everything worked perfectly.  :-)


Best regards,

Dave Orme

Re: [Xswt-developer] ID as tag

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

> I think I've suggested this before, but I don't think we made a decisio=
n:

I think I must have missed it; sorry!

> How about supporting IDs as tags, to make an existing object the "curre=
nt
> object". This will make it possible to set/change properties and add
> children to objects, without modifying the "original" element. I've oft=
en
> had to copy and comment out an element, to make a slight change without
> losing the original. Instead I could've added the "change" by using the=
 ID
> as the tag and adding whatever change I wanted there.

Hmmmm.... This is an interesting idea.  In the abstract it sounds like it
could be a good idea.  I'm interested in adding the feature but I don't
have a clear sense yet for the tradeoff between advantages and
disadvantages with having the feature.

Here are my thoughts:  the syntax we have right now forces you to put
everything related to a particular object in one place.  Most of the time=
,
this is a feature because the resulting code is generally much easier to
follow.

I think you're suggesting that some of the time this isn't a feature,
however.  So let's talk about the tradeoffs and see what consensus we get=
.

Can you provide a sample of the kind of code you want to write that this
would enable to put in concrete terms the benefit that this would provide=
?


Best Regards,

Dave Orme

[Xswt-developer] ID as tag

[<ha...@id...>]

Hi,

I think I've suggested this before, but I don't think we made a =
decision:
How about supporting IDs as tags, to make an existing object the =
"current
object". This will make it possible to set/change properties and add
children to objects, without modifying the "original" element. I've =
often
had to copy and comment out an element, to make a slight change without
losing the original. Instead I could've added the "change" by using the =
ID
as the tag and adding whatever change I wanted there.

Hallvard Tr=E6tteberg (ha...@id..., http://www.idi.ntnu.no/~hal)
Associate Professor, IS group, Dept. of Computer and Information =
Sciences at
the Norwegian Univ. of Science and Technology

Re: [Xswt-developer] extensions

[<ha...@id...>]

> -----Original Message-----
> Subject: Re: [Xswt-developer] Thanks and regression testing
> Cc: xsw...@li...
> Message-ID: <449...@co...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Without seeing your code I can't comment in detail, but is 
> there a way to not use static fields?  Designers tend to view 
> static fields as evil and in the context of Eclipse, this is 
> magnified.
> ...
> Maybe this situation doesn't apply to what you did (I can't 
> tell without seeing the code), but I wanted to make sure we 
> discussed it.

When a plugin contributes an extension, it will affect the extended plugin
"globally", similar to changing a static field. In this case, it adds
objects to a list, which the receiver uses for some purpose. There are three
contributions: IDataParser, imports to ClassBuilder and ScriptingEngines. I
think we should decide case by case if the technique is OK. I don't have any
strong feeling about this, there are two requirements: ensuring XSWT can run
without the XswtPlugin and support these extensions.

> 1) The Great Renaming that we discussed.  (Making all plugins 
> and packages start with net.sf.xswt.)

I'll leave this one to you. It's better done without too many people
involved.

> 2) The XSWT style sheet proposal / implementation.

I'll take a look at your suggested syntax, and see if I get some inspiration
:-) I think my last thought on this was that it would be a lot easier if we
had an element tree, instead of doing pull parsing (my own framework
supported copying/inserting/transforming nodes from other parts of the
tree).
 
> 3) Start coming up to speed on the XSWT editor code base.

With only two weeks left before my vacation, I think I'll have to wait.

> 4) Documentation.

Are you thinking of a separate document or as javadoc?

> > I have hacked together a pnuts extension module, based on XOM (XML 
> > parsing) + TagSoup (converts ugly HTML to XHTML), ... it supports
> > simple UIs for fetching and displaying data from GET-based web services.
> >   
> This would make an awesome screencast!  :-)

I'll try to think of a good example, to inspire people.

Hallvard

Re: [Xswt-developer] Thanks and regression testing

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

Hallvard Tr=E6tteberg wrote:
> David,=20
>
>  =20
>>> In our case, I think we could handle it be reversing the collaboratio=
n=20
>>> between classes
>>>
>>>      =20
>> That might be the best solution.
>>    =20
>
> I've now implemented (and tested, but not committed, yet) it so that
> XswtPlugin modifies static fields in ClassBuilder, DataParser and XSWT,=
 by
> means of public static methods. This means that these classes somehow m=
ust
> trigger processing of plugin extensions, before the first instance star=
ts
> operating. I've modified XSWT to do this using reflection and a naming
> convention for the methods that process the various extension points, a=
s
> shown below. There is no reference to XswtPlugin left, besides the stri=
ng in
> the Class.forName() call. Care must be taken so this method is called b=
efore
> any DataParser, ClassBuilder or XSWT instance is created. Currently the
> method is called in XSWT's constructor, but it could also be called fro=
m
> DataParser's and ClassBuilder's constructors.
>
> 	public static void processXswtPluginExtensions() {
> 		if (xswtPluginExtensionsProcessed) {
> 			return;
> 		}
> 		xswtPluginExtensionsProcessed =3D true;
> 		try {
> 			Class c =3D
> Class.forName("com.swtworkbench.community.xswt.XswtPlugin");
> 			Object xswtPlugin =3D c.getMethod("getDefault", new
> Class[]{}).invoke(null, null);
> 			Method[] methods =3D c.getDeclaredMethods();
> 			for (int i =3D 0; i < methods.length; i++) {
> 				Method method =3D methods[i];
> 				if (method.getName().startsWith("process")
> && method.getName().endsWith("Extensions")) {
> 					method.invoke(xswtPlugin, null);
> 				}
> 			}
> 		} catch (Exception e) {
> 		}
> 	}
>  =20
Without seeing your code I can't comment in detail, but is there a way=20
to not use static fields?  Designers tend to view static fields as evil=20
and in the context of Eclipse, this is magnified.  If there are three=20
plugins A, B, and C, and B and C depend on A.  Assume further that A, B,=20
and C are all from different vendors.  If A is configured by use of=20
static fields, then this means that A's configuration is changeable=20
globally for everyone by anyone.  This means that if B changes A's=20
configuration, C's configuration just changed also without C's knowledge=20
or consent.

Maybe this situation doesn't apply to what you did (I can't tell without=20
seeing the code), but I wanted to make sure we discussed it.
>>> Perhaps we need several kinds of projects: =20
>>>      =20
>> Hmmmm....  I generally agree except that I think that #1=20
>> should still be a plugin project.  Not because it has to be=20
>> but because this makes it easier to manage the build and=20
>> deployment story using the PDE.
>>    =20
> OK.
>  =20
>> I agree.  And I think that this is the release to do this=20
>> kind of renaming.
>>    =20
>
> Your editor work depends on the Callisto release, right? This means tha=
t the
> release will be in August?
Callisto goes live this coming week.  :-)  Unfortunately my editor won't=20
be ready by then, but I'm getting close to having the same functionality=20
as the XSWT preview had, but rewritten using the editor infrastructure. =20
Once that is done I think I'd like to think about putting together some=20
documentation and packaging a new release.
> What features in XSWT, the XSWT view and editors
> must be finished by then. I would like to ensure that scripting works w=
ith
> data binding, but besides that I have few plans before taking a months
> vacation in July. What things would you like me to look at?
>  =20
Any of the following:

1) The Great Renaming that we discussed.  (Making all plugins and=20
packages start with net.sf.xswt.)

2) The XSWT style sheet proposal / implementation.  Or maybe less=20
ambitiously but just as importantly, how this would implement a module=20
system for the XSWT language and how this will integrate with=20
scripting.  :-)  Let's do design by listing use-cases and actual XSWT=20
code we would like to be able to write to implement those use-cases like=20
we did for the data binding implementation.

3) Start coming up to speed on the XSWT editor code base.

4) Documentation.
>> Yeeeeaaaah.  I get it now.  I sure hope that XSWT gets that=20
>> successful that folks start using it for things like that. :-)
>>    =20
> I have hacked together a pnuts extension module, based on XOM (XML pars=
ing)
> + TagSoup (converts ugly HTML to XHTML), and based on that, it was very=
 easy
> to write an XSWT file where you could insert a URL, an XPath expression=
 and
> populate a List with the result. There's no API for posting data, but i=
t
> supports simple UIs for fetching and displaying data from GET-based web
> services.
>  =20
This would make an awesome screencast!  :-)
> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> <xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt">
>    <x:import>
>        <package name=3D"java.lang"/>
>        <package name=3D"org.eclipse.swt.widgets"/>
>        <package name=3D"com.swtworkbench.community.xswt.scripting"/>
>        <package name=3D"org.eclipse.swt.layout"/>
>    </x:import>
>    <composite>
>        <layout x:class=3D"gridLayout" numColumns=3D"3"/>
>        <text x:id=3D"url" text=3D"http://www.idi.ntnu.no/~hal/
> "/>
>        <text x:id=3D"xpath" text=3D"//html:a/@href
> "/>
>        <button text=3D"Go" selectionListener=3D"xpathhandlers.go"/>
>        <list x:style=3D"V_SCROLL" x:id=3D"result">
>        	       <layoutData x:class=3D"gridData" horizontalSpan=3D"3"
> horizontalAlignment=3D"FILL" grabExcessHorizontalSpace=3D"true"/>
>        	</list>
>        <script x:id=3D"xpathhandlers" lang=3D"pnuts">
>        		function go(event) {
>        			url =3D id::url.text.trim();
>        			xpath =3D id::xpath.text.trim();
>        			get(url, xpath);
>        		}
>        		function get(url, xpath) {
> =09
> use("com.swtworkbench.community.xswt.pnuts.modules.xml");
> 				nodes =3D xml::xom(url, xpath);
> 				result =3D project(nodes,
> function(node)node.value);
> 				id::result.items =3D
> result.toArray(String[result.size()]);
>        		}
>        </script>
>    </composite>
> </xswt>
>  =20

Wow.


Best regards,

Dave Orme

Re: [Xswt-developer] event handlers

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

Cool!

Dave Orme

Hallvard Tr=E6tteberg wrote:
>> -----Original Message-----
>> Date: Mon, 19 Jun 2006 22:03:46 -0500
>> From: "David J. Orme" <dj...@co...>
>> Subject: Re: [Xswt-developer] event handlers
>> To: xsw...@li...
>>
>> So it's basically an elegant way to get closures for Java=20
>> code defined in pnuts, right?
>>    =20
>
> Yes, there's two kinds of script-based listeners that may be attached t=
o an
> SWT control:
> 1) When the value (an IDREF) of an xxxListener attribute refers to a sc=
ript
> as a whole, the installed proxy looks up the method name and calls that
> Function, if it exists. This makes it easy to make a script covering al=
l
> methods in an interface.
> 2) When the value (an IDREF) of an xxxListener attribute refers to a
> Function (in a script), the installed proxy calls that Function directl=
y,
> which only makes sense for single-method interfaces or interfaces where=
 the
> arguments are the same for all methods and the arguments contain enough
> information about the event. This is usually the case for GUI event
> handlers, which makes it easy to write a long script with functions for
> handling all the related controls in a form. This is used in the calcul=
ator
> example: There's one script for basic math functions (just to test
> modularisation), there's one script for the calculator "model" and one =
for
> the event handlers.
>
> This technique should work for any scripting language, not just pnuts, =
as
> long as the script functions may be wrapped in a Function. I.e. the Fun=
ction
> interface is the bridge and each scripting language should have a
> corresponding wrapper, like PnutsFunctionFunction (pnuts' function clas=
s is
> PnutsFunction, hence the wrapper is called PnutsFunctionFunction instea=
d of
> just PnutsFunction :-).
>
> Hallvard
>
>
>
> _______________________________________________
> Xswt-developer mailing list
> Xsw...@li...
> https://lists.sourceforge.net/lists/listinfo/xswt-developer
>  =20

Re: [Xswt-developer] event handlers

[<ha...@id...>]

> -----Original Message-----
> Date: Mon, 19 Jun 2006 22:03:46 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: Re: [Xswt-developer] event handlers
> To: xsw...@li...
> 
> So it's basically an elegant way to get closures for Java 
> code defined in pnuts, right?

Yes, there's two kinds of script-based listeners that may be attached to an
SWT control:
1) When the value (an IDREF) of an xxxListener attribute refers to a script
as a whole, the installed proxy looks up the method name and calls that
Function, if it exists. This makes it easy to make a script covering all
methods in an interface.
2) When the value (an IDREF) of an xxxListener attribute refers to a
Function (in a script), the installed proxy calls that Function directly,
which only makes sense for single-method interfaces or interfaces where the
arguments are the same for all methods and the arguments contain enough
information about the event. This is usually the case for GUI event
handlers, which makes it easy to write a long script with functions for
handling all the related controls in a form. This is used in the calculator
example: There's one script for basic math functions (just to test
modularisation), there's one script for the calculator "model" and one for
the event handlers.

This technique should work for any scripting language, not just pnuts, as
long as the script functions may be wrapped in a Function. I.e. the Function
interface is the bridge and each scripting language should have a
corresponding wrapper, like PnutsFunctionFunction (pnuts' function class is
PnutsFunction, hence the wrapper is called PnutsFunctionFunction instead of
just PnutsFunction :-).

Hallvard

Re: [Xswt-developer] event handlers

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

So it's basically an elegant way to get closures for Java code defined=20
in pnuts, right?


Best regards,

Dave Orme

Hallvard Tr=E6tteberg wrote:
> David,
>
>  =20
>>> I've never liked anonymous classes used for creating listeners (new=20
>>> <interface>{ ... }), as they remind me to much of closures without=20
>>> their elegance.
>>>      =20
>> Agreed.
>>    =20
>>> I'd rather automatically create a wrapper using Proxy which calls a=20
>>> function. E.g. define a Function interface, with (scripting) language=
=20
>>> specific implementations (MethodFunction, PnutsFunction, ...), and=20
>>> IDataParsers for them. Then write a generic IDataParser for listener=20
>>> interfaces, that uses parse(source, Function.class) and wraps it usin=
g=20
>>> Proxy/InvokationHandler. Sounds like a nice hack, doesn't it?
>>>  =20
>>>      =20
>> I'm not quite following you here.  Could you provide a quick=20
>> example of the kind of code this would let you write?
>>    =20
>
> The code for this is already checked in. It consists of several parts:
> 1) A Function interface, with IDataParsers for Java methods (and pnuts
> functions in the pnuts extension).
> 2) A generic IDataParser for ANY interface, which reads the source as a
> Function and then returns a Proxy for the desired interface which calls=
 the
> Function for the interface's methods. This is used in the example I sen=
t
> some days ago:
>
>        <button text=3D"0" selectionListener=3D"handlers.digit"/>
>        <script x:id=3D"handlers" lang=3D"pnuts">
>        		function digit(event)
>        			calc::appendDigit(event.widget.text);
> 	</script>
>
> In this example, the pnuts script defines the digit(event) function, wh=
ich
> may be referred to and parsed as a Function by "handlers.digit" ("handl=
ers"
> refers to the script and "digit" to the digit function). The button get=
s a
> selectionListener that is a proxy for the appropriate class, that calls=
 the
> digit function, since the generic IDataParser for interfaces knows how =
to
> wrap a Function by a Proxy, so it in effect may implement any specific
> interface. Since the digit function takes one argument, is may handle t=
he
> single method in the SelectionListener interface. BTW, the generic
> IDataParser for interfaces may also wrap a Bindings object (Script
> implements Bindings) and call the function of the same name as the inte=
rface
> method that is invoked.
>
> I'll try to explain this more completely, once it works as I want it to.
>
> Hallvard
>
>
>
> _______________________________________________
> Xswt-developer mailing list
> Xsw...@li...
> https://lists.sourceforge.net/lists/listinfo/xswt-developer
>  =20

Re: [Xswt-developer] event handlers

[<ha...@id...>]

David,

> > I've never liked anonymous classes used for creating listeners (new 
> > <interface>{ ... }), as they remind me to much of closures without 
> > their 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?
> >   
> I'm not quite following you here.  Could you provide a quick 
> example of the kind of code this would let you write?

The code for this is already checked in. It consists of several parts:
1) A Function interface, with IDataParsers for Java methods (and pnuts
functions in the pnuts extension).
2) A generic IDataParser for ANY interface, which reads the source as a
Function and then returns a Proxy for the desired interface which calls the
Function for the interface's methods. This is used in the example I sent
some days ago:

       <button text="0" selectionListener="handlers.digit"/>
       <script x:id="handlers" lang="pnuts">
       		function digit(event)
       			calc::appendDigit(event.widget.text);
	</script>

In this example, the pnuts script defines the digit(event) function, which
may be referred to and parsed as a Function by "handlers.digit" ("handlers"
refers to the script and "digit" to the digit function). The button gets a
selectionListener that is a proxy for the appropriate class, that calls the
digit function, since the generic IDataParser for interfaces knows how to
wrap a Function by a Proxy, so it in effect may implement any specific
interface. Since the digit function takes one argument, is may handle the
single method in the SelectionListener interface. BTW, the generic
IDataParser for interfaces may also wrap a Bindings object (Script
implements Bindings) and call the function of the same name as the interface
method that is invoked.

I'll try to explain this more completely, once it works as I want it to.

Hallvard

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

Re: [Xswt-developer] scripting

[<ha...@id...>]

> -----Original Message-----
>    1. Re: scripting (David J. Orme)
> 
> I've downloaded and been gradually working through your 
> thesis.  It looks cool, but it's not light reading either. :-)

No, but I guess you can skip some chapter, i.e. focus on Diamodl. A video
demo is available at
http://www.idi.ntnu.no/~hal/publications/diamodl-editor/cadui-demo.html and
a rejected demo paper at
http://www.idi.ntnu.no/~hal/publications/diamodl-editor/cadui-demo-2006-reje
cted.pdf (mostly due to overlap with an accepted paper).

> > The design I'm aiming for, should let the specific scripting language 
> > decide 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.
> >
> This sounds sensible, but I think we should eventually 
> publish some kind of recommendation about how to do this so 
> that we don't wind up with widely diverging implementations.

Below I've included an XSWT file I made earlier today, that implements a
simple calculator with XSWT and pnuts scripting. It works on my version of
XSWT + the pnuts extension, which will be committed fairly soon. It gives an
impression of the current design. I've deliberately split the script into
parts, to test the modularisation mechanism. The package prefix clutters the
code somewhat, but it makes it easier to see how one script uses the other.

> Or have I completely misunderstood (e.g. the IDataParsers 
> > may be part of the runtime)?
> >   
> No, there's a separate set of objects--the ICodeGenerator 
> interface and its implementations that handle this sort of thing.

OK, I'll try to see if I understand it.

> I'm slowly but surely making progress on the XSWT Builder.  

I can't wait to see it.

Hallvard

----8<-------------

<?xml version="1.0" encoding="UTF-8"?>
<xswt xmlns:x="http://sweet_swt.sf.net/xswt">
   <x:import>
       <package name="java.lang"/>
       <package name="org.eclipse.swt.widgets"/>
       <package name="com.swtworkbench.community.xswt.scripting"/>
       <package name="org.eclipse.swt.layout"/>
   </x:import>
   <composite>
       <layout x:class="gridLayout" numColumns="5"/>
       <script x:id="math" lang="pnuts">
        	function plus (n1, n2) n1 + n2
    		function minus(n1, n2) n1 - n2
    		function mult (n1, n2) n1 * n2
    		function div  (n1, n2) n1 / n2
    	</script>
       <text x:id="result" text="                       0">
       		<layoutData x:class="gridData" horizontalSpan="5"
horizontalAlignment="FILL" grabExcessHorizontalSpace="true"/>
       </text>
       <script x:id="calc" lang="pnuts">
       		n1 = 0;
       		n2 = null;
       		mem = 0;
       		op = null;
       		function setOp(op) {
       			setN1();
       			if (op == "-") {
       				calc::op = math::minus;
       			} else if (op == "+") {
       				calc::op = math::plus;
       			} else if (op == "*") {
       				calc::op = math::mult;
       			} else if (op == "/") {
       				calc::op = math::div;
       			} else {
       				calc::op = op;
       			}
       			calc::n2 = "";
       		}
       		function getN(n) {
       			int(n);
       		}
       		function updateDigits() {
       			digits = if (calc::n2 instanceof String) calc::n2
else calc::n1;
				id::result.text = "" + digits;
				// id::result.text = "" + (if (calc::n1
instanceof String) "\"" else "") + calc::n1 + ":" + (if (calc::n2 instanceof
String) "\"" else "") + calc::n2 + ":" + calc::op;
       		}
       		function appendDigit(d) {
       			if (calc::n2 instanceof String) {
       				calc::n2 = calc::n2 + d;
       			} else if (calc::n1 instanceof String) {
       				calc::n1 = calc::n1 + d;
       			} else {
       				calc::n1 = "" + d;
       			}
       			updateDigits();
       		}
       		function setN1(n) {
       			calc::n1 = n;
       			calc::n2 = null;
	       		calc::op = null;
	       		n
       		}
       		function setN1()
       			setN1(getN(calc::n1));
       		function setN2(n) {
       			calc::n2 = n;
       			n
       		}
       		function setN2()
       			setN2(getN(calc::n2));
       		function calculate() {
       			if (calc::op != null) {
       				setN2();
       				setN1(calc::op(calc::n1, calc::n2));
	       		}
		       	updateDigits();
       		}
       		function setMem(n)
       			calc::mem = n
    	</script>
       <button text="MC" selectionListener="handlers.memClear"/>
       <button text="7" selectionListener="handlers.digit"/>
       <button text="8" selectionListener="handlers.digit"/>
       <button text="9" selectionListener="handlers.digit"/>
       <button text="/" selectionListener="handlers.op"/>

       <button text="MR" selectionListener="handlers.memRecall"/>
       <button text="4" selectionListener="handlers.digit"/>
       <button text="5" selectionListener="handlers.digit"/>
       <button text="6" selectionListener="handlers.digit"/>
       <button text="*" selectionListener="handlers.op"/>

       <button text="M+" selectionListener="handlers.memPlus"/>
       <button text="1" selectionListener="handlers.digit"/>
       <button text="2" selectionListener="handlers.digit"/>
       <button text="3" selectionListener="handlers.digit"/>
       <button text="-" selectionListener="handlers.op"/>

       <button text="C" selectionListener="handlers.clear"/>
       <button text="0" selectionListener="handlers.digit"/>
       <button text=","/>
       <button text="=" selectionListener="handlers.calc"/>
       <button text="+" selectionListener="handlers.op"/>
       
       <script x:id="handlers" lang="pnuts">
       		function digit(event)
       			calc::appendDigit(event.widget.text);
       		function op(event)
       			calc::setOp(event.widget.text);
       		function clear(event) {
       			calc::setN1(0);
       			calc::updateDigits();
       		}
       		function memClear(event)
       			calc::setMem(0);
       		function memRecall(event)
       			calc::setN1(calc::mem);
       		function memPlus(event)
       			calc::setMem(calc::mem + calc::setN1());
       		function calc(event)
       			calc::calculate();
       </script>
   </composite>
</xswt>

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

Re: [Xswt-developer] XSWT Question

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

Yu...@no... wrote:
> ok, nice to hear. Strange. The first one should work because there 
> should be a RectangleDataParser registered for Rectangle data type.
Try:

<label text="Hello World" bounds="10 10 100 30" />

(use spaces as the delimiter)


Best regards,

Dave Orme
>  
> Yu
>  
> ------------------------------------------------------------------------
> *From:* ext Pedro Pita [mailto:ped...@gm...]
> *Sent:* 09 June, 2006 21:48
> *To:* You Yu (Nokia-NRC/Tampere)
> *Subject:* Re: XSWT Question
>
>     Hi,
>
>     The 2nd method was the one :)
>
>     Thanks for your answer.
>     Pedro
>
>
>
>     On 6/9/06, *Yu...@no... <mailto:Yu...@no...>*
>     <Yu...@no... <mailto:Yu...@no...>> wrote:
>
>         Hi,
>          
>         havenot tested but you can try these ways:
>         <label text="Hello World" bounds="10,10,100,30" />
>          
>         or
>         <label text="Hello World">
>         <bounds x:class="Rectangle " x:p0="10" x:p1="10" x:p2="100"
>         x:p3="30" />
>         </label>
>          
>         Good luck.
>          
>         Yu
>          
>
>             ------------------------------------------------------------------------
>             *From:* ped...@gm... <mailto:ped...@gm...>
>             [mailto:ped...@gm... <mailto:ped...@gm...>]
>             *On Behalf Of *ext Pedro Pita
>             *Sent:* 08 June, 2006 19:17
>             *To:* You Yu (Nokia-NRC/Tampere)
>             *Subject:* XSWT Question
>
>         Hello,
>
>         I'm a CS student working on my final project and i'm using
>         XSWT in some parts of it.
>         I noticed this post
>         <http://sourceforge.net/mailarchive/message.php?msg_id=9575088>
>         from you in the xswt-developer mailing list, because I have
>         the very same problem, I don't know how to specify bounds on
>         xswt.
>
>         Since you got no answers there, I was wondering if you came up
>         to the solution or can point me to someone who can explain it
>         to me.
>
>         Thanks,
>         Pedro Pita
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xswt-developer mailing list
> Xsw...@li...
> https://lists.sourceforge.net/lists/listinfo/xswt-developer
>   

Re: [Xswt-developer] XSWT Question

[<Yu...@no...>]

ok, nice to hear. Strange. The first one should work because there
should be a RectangleDataParser registered for Rectangle data type.
=20
Yu
=20
________________________________

From: ext Pedro Pita [mailto:ped...@gm...]=20
Sent: 09 June, 2006 21:48
To: You Yu (Nokia-NRC/Tampere)
Subject: Re: XSWT Question



	Hi,
=09
	The 2nd method was the one :)
=09
	Thanks for your answer.
	Pedro
=09
=09
=09
=09
	On 6/9/06, Yu...@no... <Yu...@no...> wrote:=20

		Hi,
		=20
		havenot tested but you can try these ways:
		<label text=3D"Hello World" bounds=3D"10,10,100,30" />
		=20
		or
		<label text=3D"Hello World">
		<bounds x:class=3D"Rectangle " x:p0=3D"10" x:p1=3D"10"
x:p2=3D"100" x:p3=3D"30" />
		</label>
		=20
		Good luck.
		=20
		Yu
		=20


________________________________

			From: ped...@gm...
[mailto:ped...@gm...] On Behalf Of ext Pedro Pita
			Sent: 08 June, 2006 19:17
			To: You Yu (Nokia-NRC/Tampere)
			Subject: XSWT Question
		=09
		=09

	=09
		Hello,
	=09
		I'm a CS student working on my final project and i'm
using XSWT in some parts of it.
		I noticed this post
<http://sourceforge.net/mailarchive/message.php?msg_id=3D9575088>  from
you in the xswt-developer mailing list, because I have the very same
problem, I don't know how to specify bounds on xswt.=20
	=09
		Since you got no answers there, I was wondering if you
came up to the solution or can point me to someone who can explain it to
me.
	=09
		Thanks,
		Pedro Pita
	=09

[Xswt-developer] Added version tag

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

I'm starting some pretty heavy refactoring of the XSWT 
texteditor/preview plugin and the editor plugins.  Although I'll do my 
utmost to avoid breaking the build, just in case I do somewhere along 
the line, I've tagged the repository with a 
"pre-live-editor-refactoring" version so that folks can get to a known 
good build state.

Regards,

Dave Orme