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