Honestly I am not having a problem with the 'modularity' part of Swixml because 
it's not big enough to pose a large problem.

Swixml is soooo small and uses so much reflection (hence doesn't need to be 
heavily documented since Sun does that for you), it's very easy to go in and 
play with it.

For my current job I've integrated it with the Rhino Javascript engine such 
that you define the gui in Swixml, and then write javascript to setup the gui 
elements (combos, tables and whatnot).  If anything runs too slow then I 
rewrite it in Java.  It's actually very fast to develop with because swixml and 
javascript are both dynamic enough that I don't need to recompile the Java much 
and can just reload the Swixml gui's.   

-----Original Message-----
From: kate rhodes [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 7:18 AM
To: List for Users of Carlsbad Cubes' Technologies and Products
Subject: Re: [Forum] A setClient method in SwixEngine


if you re-use the SwingEngine for multiple things be sure to call forget 
before the new run or conflicting ID tags will give you issues.

A lot of the talk recently has been about making it modular so that we 
can create combo-boxes and tables and such with XML.

-Kate

Ted Hesselroth wrote:

> Wolf,
>
> I am using swixml for a medium-size java application, and have found 
> it to be very useful. I like the fact that it is quite focussed and 
> works well. I was pretty impressed upon reading the source code, too.
>
> The application I am writing is highly modularized. Using swixml I 
> have been able to write generic model-view-controller functions and 
> have the view components filled in upon reading an xml file. I have a 
> dozen or so different panels, and they can all use the same class for 
> the view. For each panel I have only to write the swixml file and the 
> action listeners.
>
> For modularities sake I want the action listeners to be in separate 
> classes. Therefore I am using the swix engine construction which 
> allows the "client" to be specified. This requires the creation of a 
> new swix engine object every time a new panel is created. I'm 
> concerned about the speed as the application grows larger. Would it be 
> possible to include a setClient call in SwixEngine so that the client 
> could be changed in an existing swixengine? Seeing how client is used 
> in the code, it seems so, assuming that idmap would be cleared in this 
> step. Another reason for this addition is in the use of registerTag in 
> this situation. I'd like the individual modules to be able to register 
> custom components and have them be available to all subsequent panels, 
> but this information gets lost for a new swix engine occurrence unless 
> I somehow maintain it and reregister everthing. So I think the 
> setClient and a tag that registers custom components would be very 
> powerful.
>
> Another suggestion would be to make comboboxes easier, some 
> alternative to coding a special class for each combo box. A list of 
> strings as nodes or an attribute would be fine. As mentioned above, my 
> goal is to have a single view class and a single action class for each 
> panel.
>
> Thanks for writing a very nice package, and please feel free to 
> explain if I am not fully understanding its use.
>
> Ted Hesselroth
>
>
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com




_______________________________________________
Forum mailing list
[email protected]
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com

Reply via email to