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