Re: Re: [Visualswing-developers] Proposed Feature List and Description

[<sc...@mi...>]

> As far as the internal format/xml, let me run this by
> you (I'm going to get into design a bit here so
> forgive me for jumping the gun):  The current design
> of VS uses actual Swing components.  I had suggested
> at one time that we use an interface (call it
> VSComponent) which wraps a JComponent, methods for
> generating the .java code, an icon to be used on the
> toolbar and some other things which I don't remember
> right now.  I figured we could use an XML file to tell 
> VS where to find the classes that implement
> VSComponent, and have these loaded at runtime.  If we
> add new components, we can ship them as standalone
> classes and amend the xml config file.

> Is this kind of what you had in mind with the internal
> format?

That is kind of what I was thinking although I'd rather not have the user-generated components editing our configuration files.  I was thinking that the components offered on the toolbar would have definition files - possibly in xml - in a config directory and when the user created a component that he/she wanted to add to the toolbar, he/she would save his/her component in the xml format to a specific directory and then on the next start-up that component would be offered on the toolbar in a "user section".

> I had suggested at one time that we use an interface 
> (call it VSComponent) which wraps a JComponent, methods for
> generating the .java code, an icon to be used on the
> toolbar and some other things which I don't remember
> right now.  

I like the idea of wrapping the components rather than using them directly and they could certainly hold information regarding the icon for the toolbar and similar uses important to the interacting with the properties/event listeners for the component.  I think I'd rather have a seperate classes that have the responsibility of knowing how to generate .java code or any other format.

Any thoughts about that?

Scott Corley