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