Very nice! I'm hoping to do the same thing soon. For my app, a telnet application, I want not only scripts, but the ability for a user to create a script that can have its own nice guis, complements of swixml, all without having to touch Java. I would be very interested if you'd be willing to share.
We need an extension/tag library site. I think a lot of innovation is going on that doesn't necessarily have to be included in swixml core. Just a simple site to list and describe extensions would be great. As a temporary solution, I have a source code library web app I've been using personally to catalog interesting code projects and snippets I've found. I took http://www.unmaintained-free-software.org/ and added features specific for a code library including the ability to add color-coded snippets showing how to use the code. Its not too attractive, but would work for our purposes until the java.net site gets going. http://www.twdata.org/codelibrary I don't care if we use this or a wiki or whatever, as long as we use something. Don On Tue, 28 Oct 2003 [EMAIL PROTECTED] wrote: > 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 > > _______________________________________________ > Forum mailing list > [email protected] > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com >
