Re: Re: SwiXML robustitude

Frank Meissner <[email protected]> Thu, 13 Jan 2005 21:01:25 +0100
Newsgroups gmane.comp.embedded.carlsbad-cubes
Message-ID <[email protected]>
Hello Chuck,

Chuck Dillon wrote:
> [email protected] wrote:
> 
>> Hello Chuck,
> 
> 
> Hi Frank, thanks for the feedback.
> 
>>
>> List for Users of Carlsbad Cubes' Technologies and Products 
>> <[email protected]> schrieb am 13.01.05 07:38:18:
>>
>> <snip>
>>
>>> Q3) How mature and stable is it?  Can I expect what's there to work 
>>> today and even more importantly can I expect to be able to carry what 
>>> I implement today forward without significant rework?
>>
>>
>>
>> Hm, the syntax of swixml heavily relies on reflection for
>> attribute names and this would'nt change even on major
>> redesigns... I used swixml in a some applications (in fact,
>> every java program with a GUI I created the last 1.5
>> years) and did not encounter problems regarding maturity
>> or stability...
> 
> 
> Let me clarify.  I'm asking about the maturity of the SwiXML API and XML 
> DTD/Schema.  If I were to use version 1.X to build a system what impact 
> will version 2.X, which I've seen some discussion of in this forum, have 
> on my system?  Can I expect the API to be stable or are their planned 
> reworks for 2.0?  What about the XML?

This is really a question to ask Wolf about ;) I really do not know.

Some needs (this is my very personal opinion) are there to support more 
powerful converters and custom tag facility (to support things like 
jgoodies form layout manager).

> 
> I thought of a Q6) Are there any plans to give the option of avoiding 
> the JDOM dependency and instead use javax.xml's DOM API?

As far as I see this, the api shouldn't require to change with that. 
After all, it is only parsing and "sorting things" in data structures 
available to the users of the api...

> 
>>
>>
>>> How about for Mac support specifically?
>>
>>
>>
>> What do you mean by "specifically"? Swixml GUIs are able to use
>> Program menu. In swixmls CVS is a slightly enhanced version for
>> that I added recently.
> 
> 
> 
> I was asking how mature, stable and robust the Mac support is?
> 
> My first impression, when seeing Mac specific references, was that 
> initially SwiXML couldn's support Macs but required Mac specific code to 
> function at all.  With a little more investigation I now see that the 
> Mac stuff appears to be a Mac specific extension.  I'm assuming that the 
> core functionality of SwiXML works on the Mac without the extensions, 
> right?

Yes, quite right. I'm not that much in there but wolf added some apple 
specific classes (apples ui.jar?) to get access to the program menu. 
These classes are'nt used on systems != Apple.

> 
>>
>>> Q5) How well does it support GUI glue functionality?  ...  Can object 
>>> A reference object B in the XML?
>>
>>
>>
>> This is not a builitin facility in swixml. You may try to solve this 
>> through
>> custom converters, but I'm not sure whether this is possible...
> 
> 
> Unfortunate, it would be a powerful feature.

But not that easy to implement if the requirements are somewhat 
advanced. E.g. I had the problem I wanted to disable a button if the 
number of lines is less than one. This is not that trivial (describable 
in XML) but perhaps it's out of your intended scope...

> 
> How does SwiXML support things like radio button groups without such a 
> utility?

Groups of radio buttons *are* supported. There is no magic (or, at 
least, not much ;)) there: It uses the javax.swing.ButtonGroup class to 
achieve radio button groups. The thing you can't do is e.g. take a 
checkbox and enable/disable/show/hide several other gui elements, like, 
say, tables, trees and the like.

Greetings from Berlin,

Frank